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."

Comments

Xen 2.0 Koan

[gowen]

What is the sound of one hand crashing?

Alas, no Windows...

[October_30th]

A port of Windows XP was developed for an earlier version of Xen, but is not available for release due to licensce restrictions

Sigh... how hard would it be to get a license and distribute it as a binary-only module to people like me who'd be willing to pay for it? I'm sure it'd still be less expensive than the existing alternatives.

Otherwise this looks very nice. In fact, I didn't know that there was such a mature free virtual machine available.

Obligotory.

[Anonymous Coward]

Oh man, can you imagine the overhead on a virtual beowulf cluster using this?

Since we all love screenshots...

[Zemplar]

Direct link: http://www.cl.cam.ac.uk/Research/SRG/netos/xen/scr eenshots/index.html

Re:And the point of this application is..

[grub]

Let's assume you're an ISP and have a few big machines on the racks. Your customers don't want or need that much horsepower but want their webserver (which you maintain) to run under Linux, or NetBSD, or FreeBSD, or whatever.. You can do it.

Let's assume you're a developer and want to test your code under various OSs, now you can do it on the same box in realtime (read: no reboots)

The list goes on and on, it's a great technology.

Great for free "UX's" but not for Win32

[slashnik]

from http://www.cl.cam.ac.uk/Research/SRG/netos/xen/faq .html

1.3 Which OSes run on Xen?
To achieve such high performance, Xen requires that OSes are ported to run on it. So far we have stable ports of Linux 2.4, Linux 2.6, and NetBSD. Ports of FreeBSD and Plan 9 are nearing completion.

Re:64 bit?

[julesh]

From the manual:

A port specifically for x86/64 is in progress, although Xen already runs on such systems in 32-bit legacy mode

Not as cool.

[Anonymous Coward]

From the FAQ, it states that you can only run OS's ported to it. While this might be great for cluster testing, or software design, this is defintely no VMware replacement. I am slightly disappointed in this, but I can see where it has its place.

Re:And the point of this application is..

[Anonymous Coward]

Actually, a couple ISPs and datacenters are already working on using Xen for this exact purpose.

http://xen.terrabox.com will be back online in the next 72 hours. You can find a wiki about xen there. One page is available for listing of any companies that offer Xen based virtual servers. So far the customers that i have setup under Xen have been quite impresed with the speed and stability as compared to the traditional virtualized and meta-virtualied linux vhost setups. :)

This is a VM platform, not a VMWare competitor

[ites]

Big difference. 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.

Xen is a VM platform, i.e. it lets you set up multiple virtual machines that run with very little extra overhead. A lot like User Mode Linux, except easier to configure and install.

Here's a typical use case: you want to make a network "security box" that includes firewall, proxy, web server, email, wiki, irc. Now, conventionally you put all these services in the same Linux system (or whatever OS you use). Using Xen you run all of the services in their own virtual machine, so that if the firewall gets compromised, for instance, an attacker cannot get access to other parts of your system.

It's a very useful tool.

Oh, another use case I just thought of too: how about a 'hidden' Linux OS on your Windows box that does all your email, browsing, and other Internet work that you want to keep secure. Click the icon, up pops Mozilla, except it's running in a different virtual OS.

Yup, definitely very useful.

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.

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. :)

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.