Xen 2.0 Virtual Machine Monitor Released

An anonymous reader writes "The Xen team are pleased to announce the release of Xen 2.0, the open-source Virtual Machine Monitor. Xen enables you to run multiple operating systems images concurrently on the same hardware, securely partitioning the resources of the machine between them. Xen uses a technique called 'para-virtualization' to achieve very low performance overhead -- typically just a few percent relative to native. This new release provides kernel support for Linux 2.4.27/2.6.9 and NetBSD, with FreeBSD and Plan9 to follow in the next few weeks. Xen 2.0 runs on almost the entire set of modern x86 hardware supported by Linux, and is easy to 'drop-in' to an existing Linux installation. The new release has a lot more flexibility in how guest OS virtual I/O devices are configured. For example, you can configure arbitrary firewalling, bridging and routing of guest virtual network interfaces, and use copy-on-write LVM volumes or loopback files for storing guest OS disk images. Another new feature is 'live migration', which allows running OS images to be moved between nodes in a cluster without having to stop them. Visit the Xen homepage for downloads and documentation."

Re:versus UML?

[Anonymous Coward]

UML has MASSIVE context switching overhead.
UML runs insidethe host OS and thus is a security risk.
UML doesn't access hardware via native drivers (PCI hardware that is).
UML is DOG slow compared to xen domains for IO.

I could go on. UML is/was a good solution, but if you wanted a BSD, plan9, or other OS trunnign on the same hardware as linux, forget it.

Under Xen, you can run 1 domain that uses hda, hdb, and the USB stuff directly, a second accesses a second IDE set at hde and hdf and a second PCI video card.

Remembers, xen isn't about just launchign another OS, it's about splitting up the hardware in a secure fashion. :)

Plan9

[Anonymous Coward]

Does anyone actually use Plan9?

Re:This is a VM platform, not a VMWare competitor

[Boeboe]

We already have something much more useful tool for that: cygwin. THE way to compile and run native linux apps on windows without wasting an excessive amount of systeml resources.

Re:Absolutely cool tech!

[Anonymous Coward]

I don't have a page you can visit but in practice I was able to run 2x as many virtual hosts under xen than I could with the same hardware under UMLs at even faster speeds. I just ran out of physical memory on the athlon machines is all. :)

So yeah, the benchmarks really are very close to real world results from my personal experience.

Re:Alas, no Windows...

[julesh]

How about if hardware manufactures started putting this into the bios and calling it a new platform that just so happens to be nearly identical to and backwards compatible with x86. Would Microsoft have to start supporting it then?

If a major hardware manufacturer were to release and sell significant numbers of a PC that windows wouldn't run on, MS would do what they used to do back in the Windows 2/3 days -- release a special OEM version that will work (see e.g. RM Nimbus 186s).

Of course no hardware manufacturer is likely to be able to sell significant numbers of a PC that won't run windows. Catch-22.

Re:This is a VM platform, not a VMWare competitor

[Anthony Liguori]

VMWare is about virtualising a foreign OS. Since VMWare abstracts at the BIOS and hardware level it can run almost all OSes the CPU will support but it takes a large performance hit. Hehe.. The VMWare marketing guys have gotten you pretty good. What your describing is something called full virtualization. It's what IBM does in PowerPC (with something like the OpenPower platform) and with hardware support can be pretty darn fast. The IA-32 architecture is not capable of full virtualization. If you don't believe me, just read any of the dozens of papers written on the topic. Memory poses a problem (albiet one that's overcomable) but the thing that makes it impossible is the behavior of three instructions. Virtualization's really a simple concept. You run an OS at a lower priviledge than it expects and the priviledged instructions will throw exceptions that can be caught and emulated. Certain instructions on IA-32 silently fail when executed outside of ring 0 making it impossible to emulate those instructions. What tools like VMWare do is run through the executable and change those instructions to illegal instructions or do dynamic rewriting of the executable. That's right, they have to dynamically rewrite the executable. Have you ever wondered why VMWare asks you what OS it will be running? Because it has a big set of tables of where instructions need to be rewritten. Have you ever tried to run a checked build of Windows in VMWare or better yet a newer version of Windows that just isn't supported? It fails miserably. The difference between VMWare and Xen is that Xen accepts the difficulties and then decides that if we're already going to change the OS, let's just make a few more changes to improve performance. Adding VMWare-style virtualization support to Xen wouldn't be that difficult if you have the tables and such that VMWare had. Remember too, VMWare requires OS-drivers to be installed.. there's a reason for that.

Re:Virtualisation features?

[laudney]

Google for "Intel Vanderpool".

Re:Steal or Deal?

[Frasier]

Microsoft Research operates fairly independently and it's focus is in research, not product development. They publish papers and their projects are reasonably open but that openness has mostly not carried over to Microsoft itself.

Re:This is a VM platform, not a VMWare competitor

[TimMann]

You're largely (though not entirely) mistaken about how VMware virtual machines work. User code runs in direct execution up to where it tries to make a system call or takes a page fault (etc.) and traps into privileged code. Privileged code is *dynamically* translated at runtime; we don't have big tables that tell us exactly where all the instructions in each supported operating system need to be patched. That would be totally impractical.

We ask what guest OS you're running because we have certain OS-specific optimizations, things that help one OS a lot while hurting others. Most OSes will run fine (though more slowly) on the "other" OS setting. A small number need specific workarounds that are enabled only if you select the right OS setting.

Checked Windows builds work fine AFIAK. If you have one that doesn't work, file a bug report. New OS versions usually work without VMware changes, though not always. Sometimes they'll exercise a system feature that is slow until we optimize it more in the next release, or sometimes their drivers will try to use a device in a new way that our emulation of it doesn't yet support.

We do supply some device drivers for guest OSes, not to work around any shortcomings in our CPU virtualization, but because for performance reasons some of the virtual hardware we implement is not the same as any real hardware that the guest has its own drivers for. The only such devices are the virtual display card (which works as a standard VESA device even if you don't install our driver, albeit slowly), one of the two virtual ethernet cards we support (the other is a standard though elderly AMD card), and one of the two pointing devices (the other is a standard PS/2 mouse). Hmm, I think we also supply some SCSI drivers, but only because some guest OSes don't have good drivers for either of the two standard SCSI cards we emulate (one from BusLogic and one from LSI Logic).

As you can guess from the above, I work for VMware -- in engineering if that makes me more believable to you, although I haven't encountered our marketing folks lying. Standard disclaimer: I'm speaking only for myself here, not officially for VMware.