It’s great to see VMware finally embrace Paravirtualization. As a result of a tremendous community effort to develop a common interface between Xen and VMware, that benefited from the collaboration of VMware, IBM, Red Hat, Novell, XenSource, Intel and many kernel.org contributors, the first common API between the two hypervisors will appear in Linux kernel 2.6.20.  It’s a pity VMware’s PR didn’t acknowledge the community contribution though…

Here’s what’s going on:  The issue at hand is Paravirtualization - a technique of modifying an operating system so it will run optimally on a hypervisor.    The best known example of a paravirtualizing hypervisor is the Xen hypervisor, but the concept originates from IBM mainframe OSes from the late 70’s and has been widely used on vertically integrated (hardware plus software) systems for some time.  Paravirtualization was first introduced to the x86 architecture by the Xen project instead of the binary patching technique used by VMware, because (as VMware recently acknowledged) it offers significantly improved performance for virtualized guests. 

But Paravirtualization has a bit of a downside - it requires modifications to the guest operating system to enable it to co-operate with the hypervisor.  VMware gets around this today using binary patching, which modifies the guest “on the fly” by rewriting the code. Intel VT and AMD-V help a lot- but not with I/O.  The performance benefits of paravirtualization have led all x86 OS vendors to adopt paravirtualization for their next major OS release (though Microsoft calls it “enlightenment”).  Xen-style paravirtualization also allows OS vendors to ship the hypervisor with the OS - something VMware understandably isn’t that keen on.  In the case of Linux and Solaris this is achieved through the inclusion of the Xen hypervisor, and in the case of Microsoft the forthcoming enlightened Longhorn Server OS will be augmented at some point with the Windows Hypervisor, which is architecturally very similar to Xen. 

Today many distros are delivering Xen as an embedded hypervisor.  The Xen hypercall API paravirtualization hooks are added by the vendor to their kernel once they select a particular version from kernel.org.  This is tedious/painful, and the obvious right way to do this is to have the hooks included and maintained by kernel.org.    The Xen project was happily working away (albeit rather slowly) to get the Xen hypercall API upstreamed to kernel.org, when VMware introduced VMI at OLS in 2005.    VMI is a lower level interface than the Xen hypercall API.  It’s much more suitable to a binary re-writing hypervisor like VMware’s.   But it deserved serious consideration because it offered a useful new feature - the same kernel could run native and virtualized.   But VMI is closed source - an ABI not an API, which is a serious problem for many in the open source community.  Everyone agreed that having a single interface for multiple hypervisors would be preferable to having many.   So, at the Ottawa Linux Symposium in 2006 the Xen project began to work with VMware to develop a common set of kernel hooks that could accommodate the VMI ABI and the open source Xen hypercall API.  Since then, there has been a very positive effort on all  sides, with  IBM, HP, Red Hat, Novell, and many other core kernel.org developers playing a key role in getting the work done.   

So, what’s in 2.6.20 is a common API called paravirt_ops, developed collaboratively by a group of contributors, and the first implementation of the VMware VMI interface into paravirt_ops comes in 2.6.21.  The Xen interface into paravirt_ops should follow shortly, likely in the 2.6.22 time frame.  The Xen API is more extensive than VMI, and the work is taking a bit longer to get done.   Once this set of changes is complete, future Linux kernels will have the paravirtualization hooks built in, which will dramatically simplify the kernel development processes of the distros. 

The bottom line: Future Linux kernels will have a common hypervisor interface called paravirt_ops that will allow Linux to run on either Xen or VMware with high performance.   Through XenSource’s relationship with Microsoft, it’s reasonable to expect that these Linux kernels will have the ability to run as first-class “enlightened” guests on the future Windows Hypervisor.  Of course, all of this is only relevant to the market when the next major enterprise Linux distributions take new kernels to market that include paravirt_ops, but overall it is good to see harmony emerging in this particular piece of the virtualization landscape.