Room for More than One Default Hypervisor in the Linux Kernel?

A year ago, the news that Xen virtualization support in the Linux kernel was just around the corner grabbed headlines.

For the IT community -- and for Grid technologists such as Katarzyna Keahey at the Globus Alliance, who is working with Xen hypervisors in her "Virtual Workspace" Grid projects -- this was big news. After all, "If you use open source software, your choice of available versions and scalable support may in practice be limited," as she said in an interview last October.

Indeed, for any organization to get the benefits of Xen virtualization, they need to "roll their own" Linux -- meaning take a standard Fedora Core or Novell SUSE or other distro and recompile with the Xen patch. Patched kernels, however, are typically not supported by the major Linux distros, or, more critically, third party ISVs such as Oracle, SAP or IBM. Naturally this tends to make end users a little uneasy. So Linux kernel support of Xen created interesting speculation about the end user confidence it might inspire in open source virtualization.

But today, the Xen hyperpatch has still not yet been merged with the Linux kernel. And in the meantime, some believe there may now be an opportunity for more than one hypervisor in the Linux kernel.

"Architecturally, there are increasing discussions in the industry about the equivalent of an API on a hypervisor level, within the Linux kernel," said Andrew Morton, maintainer of the Linux 2.6 kernel, whose full-time work on the Linux kernel is sponsored by the Open Source Development Labs. "Theoretically, different hypervisors could play in there, without it being restricted to one default hypervisor. Different, competing hypervisors would be able to provide the virtualization functionality, and ultimately the virtualization itself would become so transparent and good that users would not need to re-certify the same version of the kernel when running on top of a hypervisor."

A year ago, the headlines suggested that Xen had won the Linux virtualization battle. But has the delay in the Xen patch for Linux kernel support left the door open for VMware?

With a common API to hypervisors in the Linux kernel, the hypervisors themselves would become a commodity - shifting the power struggle higher up the stack to the management functions on top of the hypervisors. That's a game that VMware would rather play. Perhaps they'd even open source their underlying hypervisor?

Only time will tell. But you can be sure that the next year should continue to be an interesting one to watch in the battle for Linux virtualization market share between Xen and VMware. And keep an eye on Virtual Iron. They may provide yet another option under that possible Linux kernel API.

As the LinuxWorld expo kicks off, I'll be focusing on Linux / Grid directions throughout the week.