Xen has been fully integrated into Linux kernel 3.0
blog.xen.org
blog.xen.org
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.
The other blog post linked from the OP's link mentions this: http://blogs.oracle.com/wim/entry/linux_mainline_contains_al...
Here's one of the LKML threads where the Xen guys sent a pull request straight to Linus, got rejected, and there was a bit of a shitstorm: http://thread.gmane.org/gmane.comp.emulators.xen.devel/64085
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 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.
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.
It refers to a relatively obscure set of formal proofs and doesn't have anything to do with what most people explain it as.
For instance, everyone would agree Linux is a conventional OS but Linux provides a kernel module (KVM) that allows for virtualization driven by userspace.
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).
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.
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.
Having watched the back-and-forth between the Xen and Linux community over this inclusion business a bit, I feel the delay has actually been worth it in hindsight. Linux's pvops abstraction is clean and impartial. With this Linux has support for at least 3 virtualization technologies out of the box: KVM, Xen, and lguest. Also, a lot of the jagged edges in the Xen dom0 patches have been smoothed in this process.
This is also great news for private and public Xen-based deployments as well as companies such as Oracle, Suse and others that built their own virtualization platforms on top of Xen. Trying to get supported, well-tested drivers for new hardware working with Xen has often been a major pain point and required significant engineering resources. This was a major reason why Ubuntu switched to KVM officially (Red Hat led the charge here but that was mostly because they bought Qumranet - the company that built KVM). With this Xen is significantly more maintainable and I expect to see at least some of the distros to re-include xen as a virtualization option fairly soon!
Even in RHEL 6 we have support for RHEL as a Xen guest.
However as aliguori says above, "Xen in Linux" is a misnomer: Xen is a separate and completely different kernel (the "Xen hypervisor") and it seems unlikely we'll be shipping that any time soon. No one gets rich by providing paid support for two completely different and incompatible kernels.
Rackspace uses XenServer which is not quite the same thing.
Rackspace is migrating all slicehost customers to their XenServer based services and doing away with their XenSource product.
Recently (well, I guess not that recently) the 'xl' command line from xenserver was given back to xen.org. it's a lot nicer than 'xm' I think.