OSNews

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.

KVM could render Xen obsolete, it is possible to https://ols2006.108.redhat.com/2007/Reprints/harper-Reprint.pdf">... .

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.

Now that KVM is being or has been ported to many architectures, will we be witnesses to the slow but steady decline of Xen? XenSource themselves seem to have resigned to serving as a platform primarily for virtualising various Windows releases and are effectively competing against VMware ESX Server now.

I see that Hollis Blanchard, who has been involved in porting Xen to POWER, is doing a port of KVM to embedded POWER. I am wondering why this should be limited to embedded now that the ISA has been unified with POWER6, since both AIX and Linux could serve as a virtualisation platform with the proper hardware support. KVM has also been ported to S390 and IA64 according to the Qumranet web page.

I am asking in particular because I have ported Slackware to MIPS and would like to use a virtualisation solution such as Xen or VMware. Since MIPS would only support something like KVM with the MT ASE the best thing to do would probably be to port Xen to MIPS. I don't have much faith in the KQEMU kernel module since it doesn't even work on x86.

I have asked on the Xen-devel list but their developers are too busy developing for x86 to even react to my inquiry about any current effort to port it to MIPS. I believe MIPS is a serious enterprise platform and is having a come back with 16-core processors from multiple vendors available now and in various development stages.

Edited 2007-07-22 14:07 UTC

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.