It's a fast-moving world. I turn my back for a moment to log onto my XenDesktop, and before you know it, the Planet turns to KVM for Cloud Virtualization. Suddenly all those Xen, VMware and Hyper-V users must have switched to KVM overnight! Impressive.
I quickly check the XenServer download stats and see that the needle is still rapidly rising... about 3,000 server licenses per week. Something doesn't compute... And then I realize that it all depends what planet you're on and your sense of perspective.
The news that Red Hat has pushed out a beta of RHEL 6 without Xen, and is focussing solely on KVM going forward is an interesting moment in the in the constantly changing theory of RHEL-evance. It's neither unexpected nor earth shattering for those in the cloud or virtualization markets broadly, unless you happened to use Xen in RHEL 5. If you did, you're in for a painful "upgrade" (aka: V2V for all Xen VMs, and different management).
But before you cancel your weekend plans and set to work, I have a couple of recommendations:
- If you approach your virtualized world with a Linux/RHEL based mindset, then I recommend you consider switching to Oracle Enterprise Linux. It is a superior, enterprise class version of RHEL, and typically more up to date than it, and OEL is guaranteed to be compatible with RHEL. It's straightforward to point an existing RHEL update network to the Oracle update servers. Oracle supports OEL on other virtualization platforms such as VMware or XenServer, and in terms of pricing, running OEL in a virtual environment requires that the customer pay for only a single subscription for the physical server. Alternatively, if you're wary of giving Larry more control than he already has over your environment, Novell SUSE Linux offers a superb enterprise Linux platform boasting more than 3,000 certified applications, fully supported on Xen and XenServer, with complete support for SAP and (via Mono) many Microsoft .Net apps.
- If you have been using RHEL Xen and find yourself wishing for an Enterprise-ready Xen based virtual infrastructure platform (ie: not a Linux distro with virtualization, but a Xen based virtual infrastructure product) that is absolutely free, compatible with all other Xen platforms as well as Hyper-V, and that generally knocks the spots off VMware in performance, and ease of management, then take a whirl with XenServer - the only virtual infrastructure platform other than vSphere that Burton Group agrees is suitable for the most demanding enterprise production workloads.
Crucially, OEL and XenServer (and for that matter, Oracle VM, Hyper-V and even ESXi) are freely downloadable products. There is no freely downloadable Red Hat product. Moreover, for RHEV, the "virtualization platform" incarnation of RHEL, even the source is no longer available online. You need to send Red Hat a check for $10, and they will mail you a CD with source. Yep, you can get the source if you ask for it, but then you've got to build it yourself. Uhhh.
It's no less important to separate KVM - a very useful and fast-maturing technology that enables Linux to host virtual machines - from Red Hat, and the twists and turns of its virtualization strategy. Specifically, the open source community's contributions (to KVM, Xen, Linux etc) are superb technically, incredibly valuable to the industry, and in my view deserve far greater presence in the market today than Red Hat's approach is likely to deliver.
Red Hat's endeavors in virtualization started with profound endorsements of Xen, followed, when Novell SUSE Linux was the first vendor to ship Xen 3.0 in 2006 as a component of SLES 10, with an accusation that Novell was "irresponsible" and then by a completely unsubstantiated statement by Red Hat VP Alex Pinchev to ZDNet Australia, that "Xen is not stable yet, it's not ready for the enterprise.". Then, as RHEL 5 belatedly readied itself for delivery in late 2006, Red Hat proudly proclaimed that only it could deliver an enterprise class virtualization product based on Xen, together with a rich management infrastructure.
But even before RHEL 5 was out the door, in early 2007 Red Hat embraced KVM saying that it would take only a year to reach parity with Xen. At the same time, it kow-towed to VMware, announcing full support for RHEL on ESX, and special pricing on VMware and its own implementation of Xen, but not on other vendors' products. Then, perhaps as an admission of its failure with Xen, Red Hat purchased Qumranet, with renewed claims of relevance in virtualization. Here we are, in mid 2010, and the transformation is almost complete. Or not.
I think that Red Hat's adoption of KVM is entirely rational but largely unimportant:
- Combining Xen from xen.org together with a kernel from kernel.org to build each release of their distro was no doubt an expensive process for Red Hat and Novell. Moreover Red Hat relies on the community for much of its engineering efficiency, and having only one source of all kernel-impacting features makes sense. For example, having virtualization in the RHEL kernel means there is only one scheduler - the Linux scheduler, that they have to support. Not one for RHEL and one for Xen. The same is true for other low level platform software. The Linux kernel will doubtless evolve to provide better support for VMs but at the end of the day there is a fundamental clash between the use of a single kernel to optimally run both processes/apps and VMs. Essentially, Linus would have to agree to turn Linux into a great hypervisor, and historically he has maintained a balanced path that has not yielded to special interests.
- Having failed to capitalize on Xen, Red Hat needs a "differentiated" story in virtualization in order to regain credibility. KVM gives it an aura of that at least. But I think that there is significant risk that this strategy will back-fire. The industry has three excellent type 1 hypervisors: Xen, Hyper-V and ESX. Does it really need a fourth, and a fourth that is incompatible with the others?
- While KVM makes sense for any Linux distro, due to its simple architecture and inclusion as a kernel component, what results is a type 2 hypervisor - effectively a Linux distro that can host other virtual machines. The industry has already adopted type 1 virtualization specifically because a minimal hypervisor has a tiny code base and therefore a reduced attack surface, and can be used to build an attested secure system stack as a result. Is this a spurious concern? I don't think so. Many observers have poked fun at VMware's woeful record of shipping about a patch per week for ESX 3.5. When I asked a VMware panelist at a conference why they had to deliver so many patches, he answered that most of the critical security flaws came from their use of RHEL as the Console OS in ESX. In other words, a large Linux distro, such as RHEL 6 with KVM, will have a substantially larger code base and attack surface than any type 1 hypervisor. Moreover it is likely to have to deal with every CERT update due to vulnerabilities in Linux. By contrast, a small embedded Xen hypervisor (together with a tiny embedded Linux kernel to run the management stack and drivers) can easily be delivered within a 16MB footprint.
- A better or different mousetrap, in the form of KVM, does not solve any customer-relevant problem today in virtual infrastructure or cloud. Indeed the delivery of a secure type 1 hypervisor is a solved problem (from Xen and proprietary vendors). I'd bet that you cannot find an enterprise customer looking for a better hypervisor than those already available. The management tool stack that Red Hat offers around KVM is in reality hardly more advanced than when they first shipped Xen, three years ago. Moreover the infrastructural "basics" of resource pooling, multi-tenancy, virtual switching, and virtual storage are quite simply missing from its offering. The new open source virtual switch that the Xen and vswitch community has been developing, will work for Linux and KVM. Indeed this is our goal. But Red Hat's cluster file system, GFS/GFS2, is SAN specific, has never been optimized for large files or for VM virtual disk like operations, and a weak alternative to other clustering mechanisms, such as the resource pool abstraction in XenServer, or the virtualization enhancements that Oracle has made to OCFS2 to improve management of virtual machine disks with reflink support, a way to instantly clone a file with one command, and the abiltiy to make many clones that are "cluster safe" with Copy on Write support. Moreover Red Hat has not committed to support the DMTF SVPC and DMTF OVF standards that the rest of the industry has agreed upon as open standards for management and portability of virtual infrastructure.
- Red Hat and the Linux community generally have failed to acknowledge the fundamental need in virtualization for a stable interface between the hypervisor and guests, with both backward and forward compatibility, for all time. The Xen project is totally committed to this need - indeed Xen today runs every guest ever created for it. But KVM cannot run Xen guests. How many more times will the ABI change before they realize that (a) customers want more than a "distro lifespan" commitment to compatibility and (b) the customer desire for compatibilty means "with every other hypervisor, including those of your competitors"?
- Finally, I have previously argued that the relevance of the OS-centric approach to next-gen infrastructure is questionable. The next-gen OS will not be a thing that runs a server - but a thing that runs apps across virtualized infrastructure. VMware has (or is developing) such a thing with Spring, and arguably Red Hat, with JBoss, has the key ingredients and expertise to tackle such a thing. But it appears that Red Hat is still trying to win server sockets, when the game has moved on.
In short, Red Hat delivers a great Linux distribution, but with its narrow "Linux first" competitive stance as an OS vendor trying to win share from Microsoft and Solaris has meant that it completely missed the boat on virtualization. Its business model, which requires that RHEL is a binary that is available only to paying customers, leaves it vulnerable to truly free, enterprise grade products. Its business model is also in conflict with the most rapidly growing customer base, namely the cloud providers. Red Hat uses RHEL's footprint in the enterprise (and their enterprise customers' consequent need to run RHEL based workloads in the cloud) as a tool to force cloud vendors to adopt RHEL/RHEV for virtualization, refusing to support enterprise customers' RHEL guests in the cloud otherwise. Except of course when the cloud vendor is far bigger than Red Hat.
