Red Hat and Citrix ratchet up open source virtualization relevancy

The open source hypervisor landscape got a lot more interesting today after the latest announcements from Red Hat and Citrix. Both were shots across the bow of VMware’s juggernaut, but Red Hat’s volley may have overshot and struck Xen.org in the stern.

Citrix, the flag bearer for Xen.org, recently announced that two significant hypervisor features would be made available in the free version of its Xen distribution, XenServer – live migration and multi-node management. Neither of these capabilities are provided in the free version of VMware ESX and live migration won’t be available in Microsoft Hyper-V until Windows Server 2008 R2. Citrix is also busily placing calls to the major Linux distributors hoping to sign them up to commitments to replace the free Xen.org hypervisor with the free XenServer.

This last move is part of a larger overall strategy to move the Xen community forward and redefine compatibility and interoperability. At present, Xen community members can distribute compatible Xen derivatives that leverage a common hypervisor engine, the guts of what makes a hypervisor capable of hosting virtual machines. But most of the higher level functions, like storage and security integration and management and automation infrastructure are not part of this standard engine. Thus, incompatibilities reign among the Xen distributions. Try migrating an Amazon Machine Image over to Sun xVM and then to Oracle VM to see what I mean. Or try discovering and managing VMs running atop Citrix XenServer with your Virtual Iron tools.   A higher level of compatibility is needed across Xen distributions for this hypervisor to gain market momentum and legitimately challenge VMware and Hyper-V. Citrix is hoping to cement the free XenServer as this higher level implementation. Or, in other words, as the “de facto standard distribution.”

Which brings me to our friends in North Carolina. Red Hat angered the Xen community last year when it announced that KVM would be its go-forward hypervisor. While the company said it would continue to distribute Xen, it clearly was orienting its engineering resources to empower the newcomer. And today we received first word about those efforts.

While the market wasn’t awaiting news of a new hypervisor with bated breath, there is reason to turn an ear in Red Hat’s direction. It’s not because the hypervisor will debut with functionality arguably matching VMware ESX and XenServer, or because it is claiming greater scalability than these peers, but mainly because of the foundation upon which KVM is based.

You see, Xen has the notion of two elements: a very thin hypervisor that looks at the scheduling of CPU and memory, and Domain 0, which is responsible for management, networking and resource utilization.

Complexity (and the incompatibilities mentioned above) comes from the implementation of the two layers, how you innovate, and where you place new features. As a result, when new features are needed in the Xen hypervisor layer, they have to be created anew, even if that capability existed in the base OS running in Domain 0.

KVM comes from the point of view that all hypervisor-specific capabilities should be in this layer. All the things you need that already exist in an OS or should naturally be in an OS, should be in Domain 0.

Domain 0 for KVM is the official Linux kernel and thus it inherits all the hooks, capabilities and partner ecosystem built around the kernel. Security? Inherited. Scalability? Inherited. Compatibility with 1000s of third party applications? You get the idea. So this presumably will help KVM out-innovate its competition — Red Hat certainly hopes this will vault them into the position of leading open source alternative. Sound familiar?

However, as is usually the case, the devil will be found in the details. Red Hat will first release an embedded hypervisor which will have a stripped down Domain 0 of RHEL 5. It’s currently not known how much of that rich Linux partner ecosystem will find the hooks they need in that 64MB domain. Will what KVM inherits be what the embedded footprint takes away? We’ll find out in May.