Slashdot Mirror
Red Hat, Novell To Package Xen
robyannetta writes "Watch out VMware and Microsoft. Here comes
Xen, an open-source virtualization for the Linux environment being pushed by Red Hat and Novell. Xen has also joined forces with leading Linux distributors, chip vendors and platform vendors to create a consortium that will more broadly enable open-source virtualization development and deployment." We've covered Xen before, but it's cool to see the momentum behind it growing, as more choice is a Good Thing.
Oh my, it all makes sense now.
Sigs cause cancer.
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
'Watch out VMware and Microsoft'? If im correct, Vmware and VPC doesnt require the host operating system to be actually ported to the virtual system, whereas Xen does. This might be fine for specific usage, but its next to useless for what I use vmware for - trying out new and interesting operating systems, configurations or such. The markets may overlap near the top end, but I see no reason why VMware/VPC need watch out, as the main market for these VMs is running Windows, and while there has been a developers port of WinXP to Xen, I severely doubt you will see that in the wild.
I was an early user of 1.0, and have followed developments of Xen since. It's very nicely done, open source, and builds on existing kernels and distributions (it's not really a standalone application, but integrates with the Linux kernel and adds some userland tools).
Xen lets you configure one physical system with multiple virtual systems. Hardware access (disk, net, video) is transparent via software.
This is kind of the conceptual opposite tools like Condor and Globus: rather than bundling lots of physical systems together as one (aka, grid computing), it is meant to take one system and subdivide. This makes for easier development (including testing for grid services, Web services, different distros, etc.), and of course is good for virtualization (like in Web hosting services).
Congrats, team!
I've yet to try Xen, but as of now, I just need basic windows compatibility to launch closed softwares (most of them being databases of law articles on CD-ROM to copy / paste extracts in linux Openoffice for research purpose), and Qemu does just that.
I only wish it could play GTA3-VC !
But what do you have to change ? First of all, the system has to be made aware that it's not the "top top". Its physical memory is no longer contiguous (you ask Xen for memory pages, and it gives them to you in arbitrary places), it also has to be aware of absolute time that's no longer tick++. Second, you need drivers for the abstract network card and disk. Those are generally easy to write, because you just delegate the real work to Xen. VMWare is already doing something similar with its vmxnet driver for Windoze.
I'd really expect these kind of changes to the OS to be incorporated in the main linux tree, as they mature.
What do you gain from all this ? Well, SPEED. I mean, SPEED. Take a look at their research papers (wrong suggestion for the "I won't RTFA" crowd, but still ...). Their slowdowns/throughput losses (they run Postgres and Apache on a couple of virtual nodes, as opposed to a single, consolidated machine), are negligible (less than 10%). On some configurations they even got performance improvements! At the same time, VMWare and UML do considerably worse.
In general, it's very easy to "virtualize" stuff that's running mostly in user space. As soon as you have considerable OS+I/O overhead, your performance drops significantly. The para-virtualization approach (employed by Xen), pretty much gets you the best of both worlds.
The Raven
VMware works with a host operating system to provide a complete x86 virtual environment for a guest operating system.
Xen is an operating system in its own right. It's a "virtual machine monitor" or "hypervisor". It can spawn multiple guest operating virtual machines.
x86 is not a very good architecture for virtualization. To have a virtualizeable architecture, anything a user-level program can do should behave the same way it would in supervisor mode, or it should trap so the virtual machine monitor can emulate it. x86 has instructions that don't quite follow this guideline -- for instance, you can see what protection ring you are currently in. In supervisor mode, you would get something like ring 0. In user mode, you get ring 3. So an operating system trying to see what ring it was in would get ring 3, but you are trying to fool it into thinking it is in ring 0.
Anyway, Xen modifies the guest architecture. It disallows these "sensitive" instructions and creates some virtual devices that are easier to emulate (like a simple software-programmed TLB). This allows the performance to be very very good, faster than VMware, but it requires you to fiddle with your operating system a bit. Which, of course, is easy to do with Linux.
-- Erich
Slashdot reader since 1997
There are 4 ways (I think) to provide what is loosely referred to as "virtualization":
1. Hardware emulation. QEMU, VMWare, Bochs all fall in that category. QEMU is open source and is actually pretty cool - a great way to test kernels during development or testing that new ISO you're trying to put together. This method is the slowest of all since all hardware is simulated in software.
2. User Mode Linux. In this scenario the kernel is run as a user process. This method has the second most overhead. Security-wise, it is only as secure as the host system, so if there is a known userland exploit, it is vulnerable.
3. Xen. To the best of my understanding, Xen is a kernel which runs other kernels. So this architecturally similar to UML, but (if you believe them) is much better optimized. And if Xen is as exploit-free as is claimed, it should also be pretty pretty secure, though I believe only time will tell.
3. Separation. This is Linux VServer, which is a fantastic project that doesn't have the publicity engine and funding of a big university behind it. This isn't really virtualization as much as it is separation. This approach is also shared by SwSoft's Virtuozzo, FreeBSD jails and Solaris containers. Since there is only one kernel in this scenario, this method is not OS-independent, i.e. VServer only runs Linux, Jails are only for FreeBSD, etc. Performance-wise, this approach should far outrun any other method as it carries practically no overhead and takes advantage of all the existing UN*X optimization. It is also very secure, possibly most secure of all (short of hardware emulation like QEMU) since it directly addresses all known virtualization exploits such as chroot escapes. But, perhaps I'm biased...
IMHO, this cound change the entire distribution paradigm - for example - if you wanted an email server - you just download the virtual image off the network of a linux system that already has it preinstalled and mostly set up, of if you want a web server/ldap server/dns server - same thing. It is a very nice way to have the best of a full featured linux system while at the same time the xen application os has the minimal stuff nesissary to run what you want.
Back in the 70's, CP/CMS on the 360 architecture was open-source. CP originally was a pure emulator: privileged machine instructions caused interrupts and were then emulated by CP. So we used to debug entire CP/CMS operating systems on top of CP, which was pretty cool. IBM eventually released a commercial version of CP/CMS called VM370.
Meanwhile a bunch of independent companies, mostly time-sharing outfits, figured out that emulating privileged instructions was, well, dumb and slow. Instead, if you modified CMS to use traps instead of executing emulated privileged instructions, it could run many times faster.
Which is why commercial timesharing outfits like National CSS, etc., were routinely able to support 250+ users on 370/168's, roughly three times the user load that IBM could support with VM370. That, and the fact that National CSS bought up every single drum drive they could find as paging devices. Ridiculously fast for the time -- nearly zero seek time, and delightfully high RPM's -- but when the bearings froze, those suckers would often burst right out of the glass case and blow holes in concrete walls.
Anyway Xen is not a new idea. It's a very old (and good) idea.
With ESX VMware is making money on consolidating many underutilized servers onto one box (with redundant failover box if needed) without the fear that a bad app misbehaving & killing the OS on one virtual machine will lock up other virtual machines' OS. It also provides customizable virtual network(s) between the VMs. A true open source equivalent would be very cool (one that can run ANY i386 OS in VM) You can migrate virtual machines from one physical box to another, sync, and cut over without interruption if they're both on same subnet. Kewl, hope a true open source equivalent exists someday.
Disclaimer: I work for VMware, but they don't pay me to post on slashdot.
There are a lot of replies of the form, "Wait a minute, Xen requires that you hack up your guests! What a crock! Typical slashdot hype!" It's true that Xen is more limited than VMware's products, in that you do need to modify guests. However, this doesn't mean that Xen is a joke. (Plex86, for instance, really is a joke, because Kevin Lawton seems to pursue it only in fulfillment of an elaborate VMware-centered revenge fantasy.)
The Xen folks, on the other hand, are smart and mostly serious people. Xen, along with appropriately modified guests, solves some of the problems that our products solve, and for those areas where it fits the bill, it does so in a way that should have lasting performance advantages over full x86 virtualization. What Xen is not, in my opinion, is a virtual machine monitor, for any reasonable definition of VMM. Xen is a microkernel. They don't call it that, because it's hard to get papers about microkernels published these days, but if you think about it, the process of porting an OS to run as a guest under Xen isn't cocnceptually distinct from porting it to run as a personality under Mach or Chorus or whatever. The L4 people didn't even bother renaming their microkernel before repurposing it as a paravirtualization platform.
I think the microkernel analogy helps clarify ones thinking about the promises and limitations of so-called "paravirtualization." Hypervisors are microkernels. In the mid-90's, there was a hope that the whole world would be able to settle on the Mach microkernel. It never happened. Anybody hoping to become the only 'para-hypervisor' will face the same political and commercial challenges.
So to recap: Xen is not a replacement for VMware's products. Xen will probably not take over the world to the degree that its creators would like. Xen is not, however, a joke. The Xen researchers are mostly conscientious, smart people who, fairly enough, would like to see their work have some commercial impact. I really wish they'd stop beating their chests over benchmarks that show them beating a three year old version of our desktop product, though.