OSNews

Dunno.....KVM has already been merged and most of kernel hackers seem to agree that KVM it's much cleaner and better than Xen: http://itmanagement.earthweb.com/article.php/3659196

My long term bet is certainly for KVM.

Competition is always good, having KVM and Xen as two different projects would have been better for the community than adding both projects into the Linux mainline;

What can we expect now from those projects?

1. They will find a good way to live together into the Linux kernel? IMHO that is not a good approach; having two things to do the same thing into the same project just make them bloat.

2. Xen will eat KVM or viceversa? Very negative, because competition is always good.

3. They will get merge technologically? Maybe this is the best option.

There's a fundamental difference in the approaches taken by Xen and KVM. Xen exports a virtual CPU architecture and "pseudo-physical" guest address spaces. It was conceived, designed, and implemented as a clever way to implement virtualization on host hardware architectures that were not designed to be virtualizable. They implement a lot of mappings, protections, and switches in the hypervisor that would ideally be provided by the hardware, and they compensate for this software emulation by presenting an ideal virtual architecture for guests to target.

Xen lit a fire under Intel, AMD, and (to a lesser extent) IBM to provide virtualizable hardware. These extensions are coming in phases. For example, Intel's first phase, called VT-x, implements a guest mode with selectable trapping of privileged instructions, state switch on mode switch, and guest exit conditions. An upcoming phase, called VT-d, will implement a hardware IOMMU, nested page tables, and guest interrupt delivery. The hardware vendors are steadily extending their architectures to correct the shortcomings that drove Xen's design.

KVM has taken a somewhat opposite approach by demanding a certain level of hardware support in order to implement a reasonably simple hypervisor that exports vanilla x86 (now including 64-bit and SMP) virtual machines. The theory is that a little bit of hardware support saves a lot of CPU cycles and software complexity. Work on KVM started at the perfect time to capitalize on the explosion of x86 virtualization support, allowing the developers to support the new capabilities as they arrive while keeping the code lean and mean.

The exception is the management of the shadow page table, which keeps track of the guest-physical to host-physical mapping in the host so that the hardware MMU can present the guest with the combined guest-virtual to host-physical mapping. Shadow page table synchronization was implemented with considerable complexity in order to provide decent performance. This will become a lot simpler with the arrival of hardware support for nested page tables.

So, in a sense, Xen is a virtualization technology that was designed to be state of the art in 2005, while KVM was designed for 2008 and beyond. Xen is taking advantage of these new hardware features just as KVM is doing. But it also carries around a lot of design and implementation baggage due to yesterday's requirements. KVM is beginning to implement paravirtualized drivers to smooth out its remaining performance wrinkles, but it will take some time to catch up to Xen in this area.

There's no question that KVM is becoming increasingly relevant. But it's too early to tell if KVM will grow at Xen's expense. A lot of big players jumped on the Xen bandwagon quite enthusiastically. Novell, Microsoft and (most of) IBM are firmly in the Xen camp. Red Hat is less committal and more likely to support KVM. Kernel developers love the KVM approach, but commercial vendors are hopelessly attracted to solutions that have that "bolted-on" feel. The degree to which KVM can leverage existing management solutions such as Red Hat's virt-manager will be very important.

KVM currently only works with CPUs that include hardware virtualisation (ie true virtualisation).

Xen works with regular CPUs (paravirtualisation) as well as hardware virtualisation.

Xen also currently supports LVM partitions for the virtual machines as opposed to regular files in the host's filesystem.

Xen also supports fast movement of VMs between hosts.

There are also several management consoles and GUIs for Xen, none of which work with KVM.

Eventually, KVM may catch up to Xen. For now, they are very different beasts, with very different feature sets, and neither can really replace the other.