Back in July 2006, one of the most contentious issues at the Linux Kernel Summit was what to do about virtualization. At that time, there were three contenders: Xen, VMware, and OpenVZ (the latter being a lighter-weight container-based approach). The biggest fight was between Xen and VMware over competing approaches to running kernel operations through their respective hypervisors: Xen touting their hypercall interface and VMware touting their VMI (Virtual Machine Interface) approach. Neither of these approaches was palatable to kernel developers for a variety of reasons, most of which were technical but also because selecting either would give that contender a great public relations boost over their competitor.

The reason for the fuss? Virtualization schemes like Xen and VMware can be programmed to work correctly on unmodified operating systems. However, they do this by intercepting certain actions the operating system takes (like trying to modify the page tables) and redirecting these operations so as to give the operating system the illusion that it's running exclusively on the hardware, while in reality, it is just one among many running in a so-called "virtual machine." The problem with this interception is that it's expensive (it really uses special CPU hardware to execute a trap into the hypervisor whenever the operating system does something that the hypervisor needs to check). Interception became much cheaper with CPU versions that contain virtualization technology (Vanderpool in Intel and Pacifica in AMD); however, it would be cheaper still if, instead of having to use hardware to watch the operating system, the virtualization layer could just plug into all of the operations that it needs to intercept. The two schemes being pushed by Xen and VMware are essentially different ways of plugging into the operating system.

The germ of a compromise at the Kernel Summit was achieved using an approach that had been taken by the venerable Power PC hypervisor interface (PPC has long had a firmware hypervisor with Linux support on the IBM p series of hardware). This approach, called paravirt ops (ref: http://lwn.net/Articles/194543), would essentially provide a well-defined but pluggable interface that could sit underneath the competing approaches and allow either to work comfortably in the kernel - sort of like a universal socket in the kernel for the Xen and VMware plug-ins.

In the interim, in kernel 2.6.20, a new virtualization interface, called KVM, went in with comparatively little fuss, ramping up the pressure on both Xen and VMware to produce their paravirt ops patches.

Finally, in the latest kernel version (2.6.21 released on April 25, 2007), VMware finally saw their VMI patch based on paravirt ops go into the Linux kernel (patches from Xen are also being applied in this kernel, but Xen still isn't there yet in terms of being fully available inside the Linux kernel).

What will VMware users see when running kernel 2.6.21 and beyond as a guest operating system? Essentially the benefits are twofold: first, and most important, increased speed. In theory, with VMI and hardware virtualization technology, a guest operating system should be able to operate almost as fast as the corresponding operating system would have run natively on the hardware. Second, VMware will be able to exercise greater control over the virtual guest operating system: this means operations like suspend and resume (for VMotion) or administrative operations like reallocating processing or memory resources should be much easier and quicker to perform.

Will users see these benefits immediately? Unfortunately, this might depend on the version of VMware being used. VMware released Workstation version 6 recently, which is capable of fully utilizing the VMI features in Linux Kernel 2.6.21 (although the VMI utilization is listed as "experimental"). However, for the more standard (and non-free) ESX version of VMware, or for the free VMware server product, support for VMI is still only going to be delivered at some point in the future.