KVM steals virtualization spotlight (ZDNet)

KVM kicks-ass. Seriously.

You know what is the difference between Xen and KVM?

KVM is usefull for normal people. It's sane, it's aviable by default, and it doesn't destabilize the system.

If you want to setup a seperate server for your Linux box, then KVM is the easy and sane approach. If you want to setup a VM for legacy applications (say some propriatory app that only supports Redhat 9, or your migrating from Windows desktop) then KVM is MUCH more suitable.

And what is this business about 'maturity' between KVM and Xen? Sure Xen has more features, but KVM has Qemu and the Linux kernel backing it up.

Fair trade I figure, more then fair.

Xen is intrusive and difficult to use and manage in comparision. It took many years for Xen to reach the point were KVM took months. If XenSource people figure they can sell propriatory software (aka XenEnterprise) to deal with that aspect of it and that people will choose that over KVM then they are sadly mistaken.

Seriously:
Make open source software, but leave it difficult to manage. Then create propriatory software distribution to make it easier. That approach is not going to win freinds and followers.

And what is this hypervisor versus application layer stuff. Is that FUD or something?

I thought that KVM effectively turned the Linux kernel into a hypervisor, rather then a sort of 'kernel-mode' accelerator for making emulation faster. I don't understand this aspect all that much.

So on one side you have Qemu + KVM, Qemu + Kqemu (recently GPL'd) versus Xen on the other.

Why fight?

It's obvious that they realy aren't competing and probably shouldn't.

Xen is, and should, aim for the big enterprise situations were you have dozens and dozens of machines in blade servers and such. High density hardware with lots of ram and centralized SAN storage to be able to leverage the load balancing aspects and system management advantages of having 'floating system images'. Virtual machines migrating around from machine to machine as needed floating around on a thin layer of hypervisor.

KVM is more suitable to desktop oriented applications.
Take this for example:
https://help.ubuntu.com/community/WindowsXPUnderQemuHowTo

A howto on getting your Windows applications to appear to integrate into your Linux desktop. The leverages Qemu heavily along with Rdesktop.

Now with KVM/Qemu a administrator could setup a bunch of people with Linux desktops. If they have some sort of legacy application that requires windows (for instance Fedex shipping manager application) then the admin could ftp over a windows XP pro image and have it setup transparently for that end user in probably 15-20 minutes.

Something simple and quick and effective. How much of a PITA would that be for Xen?

Or say you want to setup a secure FTP server or DNS server and don't trust Vserver enough for the paticularly hostile environment your going to expose the VM to. (a local kernel exploit in OpenVZ or Vserver-based VM would allow the attacker access to the entire machine). That would be much easier to deal with with KVM.

Or some server application you have setup on Debian Sarge, but the hardware is failing. You buy new hardware but decide to go with Ubuntu or Etch isntead, but you don't want to spend any time porting applications over to the new php version or something like that. KVM to the rescue, just pop in the old harddrives and fire them up. No sweat. Or use DD to make a file image. No sweat either.

I could go on and on were the ease of use and nature of KVM makes it more suitable then Xen.

So they are complementary, not competing in my eyes.

In fact I think that KVM is such a powerfull asset for the Linux desktop especially that all desktop-oriented distributions should ship with the full suite of KVM/KQEMU/QEMU and related applications, especially GUI applications and simple scripts to deal with common VM-related network configurations...

To be clear on this slightly misleading quote from the last page of the ZDNet article - the only thing that has split for Xen vs KVM is the kernel tree - not the Fedora distro itself - there are simply separate source RPMs for Xen kernel vs baremetal kernel (with kvm.ko). This kernel tree split is only neccessary because progress/updates of the bare metal kernels can't be held up by the time required to port Xen kernel patches to new LKML trees.

There is *no* need to have a hard split between Xen or KVM in any other part of the distro aside from kernel tree. When we first started seriously working to include Xen in Fedora / RHEL, we anticipated that other open source virtualization technologies may well arrive on the scene. To minimise the disruption this would cause to both system administrators & developers [of management tools], the libvirt (http://libvirt.org) project was started. This provides a generic management API for virtualization systems, with the per-hypervisor specific details hidden away in the internal backend drivers. So apps built on top of libvirt with the Xen driver, can be made to run on KVM or QEMU with very little (if any) porting effort.

Thus Fedora 7 will be able to provide users/admins/developers will a single toolset - virsh command line management tool, virt-install command line provisioning, and virt-manager graphical management / console - which can be used with Xen, QEMU or KVM. There is no need to frame the discussion as a black & white either/or choice of KVM or Xen - users of the distro choose either option as best fits their needs. The fast emergence of KVM as a viable contender, is a very nice example of open source innovation at its finest :-) There's nothing to fear from having a choice of open source virtualization systems. IMHO, rather than benefitting VMWare (as the article suggests) it will actually just increase pressure on them by cranking up the pace of development, thanks to the healthy competition between Xen & KVM.

Full disclosure: I'm a developer on libvirt & virt-manager, and on the Fedora virtualization team.