Can anybody tell me what's the matter with Xen? I believe that a few years ago there was a lot of talking about Xen. Then all of that seemed to die out, and it seemed that the kernel developers instead developed KVM because it's simpler than Xen, and so the Xen developers had to re-release patches for every kernel release. What's the current status of Xen? How widely is it used? How widely is KVM used? Why is it being integrated into Linux now even though KVM already exists?
Xen is a microkernel, loosely based on the Nemesis OS from the University of Cambridge. Instead of running traditional POSIX software, this microkernel runs software in ring 1 using a very special system call API. DomU and Dom0 support for Linux means that Linux has been ported to run on top of this special system call API.
But this doesn't mean Xen is now in Linux. Xen is still a separate OS with it's own memory manager, scheduler, device drivers, etc.
OTOH, KVM is a device driver for Linux that let's you run virtual machines under Linux. You're still using the Linux scheduler, memory manager, device drivers, etc. KVM is fundamentally a part of Linux.
For another point of reference (with less confusing terminology), L4 is pretty much the same thing as Xen and L4Linux is equivalent to Linux dom0/domU support.
It is not as efficient as a system-level one like Xen or KVM.
i.e. Vbox is an application that runs at the same level as say... apache or nginx as opposed to KVM and Xen which work at a lower level by integrating closely with the Linux kernel.
That means that the resources allocated to Vbox are decided upon by the OS, with all the overhead that comes along.
Xen and KVM can run a guest OS with less overhead than Vbox and can decide that a guest OS has 25% of CPU cycles while another has only 10%, which vbox cannot do.
VirtualBox works fine for development environments, but you want something like Xen or KVM for running your servers if not going bare metal.
VirtualBox is basically the same as KVM with the exceptions of 1) their kernel modules are not upstream 2) they put a lot of effort into doing dynamic translation for non-VT/SVM hardware 3) their performance is really poor 4) they don't integrate very well with Linux mainly because of (1).
As far as being a hypervisor however, Vbox is strictly a type 2, i.e. it needs a host OS to run and resources are allocated to it.
In contrast, Xen and KVM are type 1 hypervisors, meaning they themselves allocate resources for guest OSes from bare metal.
There are debates about the semantics of whether KVM is type 1 or type 2 due to its implementation on top of the Linux kernel, but it is definitely in a different league than Vbox.
The problem is that the phrase used in Popek's paper is "Conventional OS". This was the 1970s. What's now considered a "Conventional OS" was not conventional back then.
For instance, everyone would agree Linux is a conventional OS but Linux provides a kernel module (KVM) that allows for virtualization driven by userspace.
A few years ago the Xen developers sent a massive patch to the Linux kernel developers and it got rejected outright because it got far too intimate with way more of the kernel internals than it should have.
Things seem to have changed now, though -- it looks like the Xen developers have cleaned up their code and the Linux devs were willing to merge it into mainline.
Xen is still widely used. IIRC Xen provides the virtualization layer for AWS, and it is used by some pretty large hosting providers (Linode comes to mind). It also is packaged into a number of commercial commercial offerings. Oracle's VM solution is really just Xen running on Red Hat with some optimizations for their platform stack, same with Citrix. Clearly those two implementations alone is going to be a decently-sized install base.
I don't know how much KVM is used in the wild, but it has been crowned the "official" hypervisor for RHEL and Ubuntu, so I would guess that it it's been steadily gaining steam w/ the OSS crowd.
Indeed -- and stuck with it for quite some time. They were trialling Xen for some time, but I don't think they ever deployed it on a terribly large scale. Certainly, my VM went straight from UML to KVM.
I believe the management tools for Xen (or lack thereof) were the reason for using KVM instead. None of my machines (I have 7 or 8) have ever used Xen.
Xen is used all over, AWS and a multitude of linux vps hosting are some of the major ones. I don't know how much kvm is used in comparison but I believe that Xen's paravirtualization offers some advantages over using kvm (someone with more knowledge could probably chime in for that).
As mentioned by others, xen is used a lot in the wild (I believe it is the underlying virtualization architecture on EC2, for example).
One big advantage of KVM is that you can use your existing kernel, and there is little chance of conflict with other features in the kernel (which can include somehow esoteric drivers, more fundametal patches like low-latency stuff, new schedulers, etc...). At my current employment, we had issues with xen and raid drivers for example which did not work with the xen kernel (but that may be our own incompetence).
When KVM was first out, it required support from the CPU, whereas xen did not. KVM still requires this CPU support, but it is very hard to buy a x86 CPU without the feature nowadays, whereas it was not so common 3-4 years ago. Anything you would use in a server certainly has the support.
KVM is simpler to set up on a common distribution (Ubuntu, RHEL, Fedora), which means it is easier to reproduce the same environment as used in production.
Xen solved a problem before 2007: no CPUs at that time had hardware virtualization extensions, and Xen allowed you to virtualize Linux-on-Linux without needing them.
However, the Xen developers never worked very hard on getting the code into the mainstream kernel, so literally for two or three years if you wanted Xen you had to run some ancient patched Linux kernel (2.6.18 IIRC).
From around 2007, CPUs started to be shipped that contained hardware virt. KVM was written about that time, and because it just defers virtualization to the hardware, the KVM code is small and simple, more akin to a device driver than anything else. Putting this in Linux was a no-brainer really.
Now, 2011, third generation hardware virt is everywhere, and it's really fast, much faster in fact than the original Xen "paravirtualization" trickery.
The Xen developers realized late in the game that they needed to get their changes upstream into Linux. The changes were late and very invasive, but now after ~3 years of trying, all the pieces are finally in upstream Linux, and that's the news you're reading about today.
