Red Hat cranks virtualization power play
Move aside, Microsoft, Citrix, VMware...
Red Hat is a player in operating systems and middleware, and it wants to be a player in server virtualization - at least more of a player than it has been since it parked the Xen hypervisor inside its Enterprise Linux 5 distro back in March 2007.
The company has been dropping hints about its plans for server and desktop virtualization since acquiring Qumranet, the creator of the KVM virtualization hypervisor, for $107m in cash last September. After last week announcing an interoperability agreement with Microsoft, which will see Red Hat support Windows instances atop its Xen and KVM hypervisors and Microsoft support RHEL atop its Hyper-V hypervisor, and ahead of VMware's VMworld Europe trade event in Cannes, which starts tomorrow, Red Hat decided it had better explain what it was going to do with KVM.
And so Red Hat today mapped out its server and desktop virtualization plans, which are going to take the next 18 months to get fleshed out with some details and delivered as commercialized products.
"Red Hat is in a power position to set the agenda for virtualization," said Brian Stevens, chief technology officer at the Linux outfit, which is also - by virtue of its JBoss acquisition - one of the key providers of middleware.
Stevens didn't say much on the call except that the broad product offerings would be called Red Hat Enterprise Virtualization and that the company was partnering with chip maker Intel and server maker IBM to bring this KVM-based technology to market. IBM's help seems to be related exclusively to the delivering of virtualization for Linux as it relates to its x64, Power, and mainframe servers.
Red Hat invested more than a year to get the open source Xen hypervisor embedded inside RHEL 5, a project that was announced in November 2005 for delivery in late 2006, but which was pushed out by about six months to March 2007 because Xen was such a moving target back then.
Last year, Red Hat opted to go with KVM because unlike Xen, KVM is part of the mainstream Linux kernel, which means developers are not constantly trying to reconcile the Linux kernel and the Xen hypervisor. (That's why Qumranet is worth $107m in cash, and why Citrix Systems and the open source Xen community it sponsors should try to get Xen mainstream as well.)
And that is why Red Hat is going to be basing its future virtualization strategy on KVM. Consider Xen part of the learning experience and something that Red Hat is happy to support in RHEL 5 as long as customers want to use it.
But starting with RHEL 5.4, KVM will be the default hypervisor inside RHEL not Xen, according to Navin Thadani, senior director of the virtualization business at Red Hat. (This shift is already under way with the Fedora development release of Linux. Fedora 10, which came out in November last year, has both Xen and KVM hypervisors, but Fedora 11, due at the end of May, will default to KVM. The default position on installation is not just a matter of preference, but a signal that KVM will be ready for primetime.
And to that end, the first KVM-based product to come out of Red Hat will be called the Red Hat Enterprise Virtualization hypervisor. Thadani said it would be able to span up to 96 cores and 1 TB of main memory in a single system image - which is the top-end for current "Dunnington" Xeon 7400-based servers from IBM, Unisys, and NEC.
He said he would also allow a single guest virtual machine partition on a host to span up to 16 cores and up to 64 GB of main memory.This is significant, since VMware's ESX Server hypervisor can only span across four cores in a single guest, and XenServer, the commercial hypervisor from Citrix based on the Xen hypervisor, can only span eight cores per guest.
Red Hat says is can get its KVM-based hypervisor - which will be sold as a standalone product - down to a 64 MB memory footprint, including the RHEL kernel and the KVM hypervisor. It will include the VirtIO drivers and Libvirt and CIM management interfaces that are becoming industry standards for x64 virtualization. The RHEV hypervisor will also have memory page sharing, which allows more VMs to be crammed onto a server, and will include SELinux security features too.
RHEV will support Linux and Windows guests, and thus far, Red Hat is not saying anything more about details. But Windows Server 2003 and 2008 seem to be required, as will RHEL 5 and probably SUSE Linux Enterprise Server 10 from Novell.
Red Hat is also cooking up something it is calling RHEV Manager for Servers, which is a virtualization management tool that uses a search engine rather than a hierarchical, drill-down window interface that will allow system administrators to cope with thousands or tens of thousands of virtual machines. This management tool will allow admins to manage VM images, cluster them for high availability, live migrate them around the network, set power consumption limits for VMs, monitor their running, and provide audit trails as they are being created, deployed, and altered in a production environment.
A third KVM-related product is called RHEV Manager for Desktops, which is a commercialized version of the virtual desktop infrastructure (VDI) product that Qumranet had delivered as SolidICE back in early 2008. The VDI approach puts virtual desktop slices back on VMs in the servers in the data center (in this case, running KVM as the hypervisor) and the servers stream desktop applications down to thin clients or PCs on end user desktops.
Qumranet had created software that allowed efficient two-way streaming of audio and video between clients and servers in the VDI configuration and that allowed a thin client to give the look and feel of a local PC. This is what end users want, and the lack of this look and feel is why VDI has not taken off in the market despite years of sales pitches.
Red Hat is trying to position the standalone RHEV as a product intended for customers who don't have a lot of Linux experience but who might want to virtualize Linux and Windows servers, while the KVM embedded inside RHEL 5.4 will be pitched to big Linux shops that want to manage large numbers of virtualized servers. What is not obvious to me is why you need Xen or KVM bundled inside RHEL if you have a free-standing KVM hypervisor and tools to deploy it on desktops or servers and manage either Windows or Linux instances. This sounds more like a legacy packing and pricing issue than a technical one.
Thadani says that RHEV is based on KVM and the Linux kernel as implemented by Red Hat inside RHEL and will therefore be an open source product, but that some of the management tools that it got through the Qumranet acquisition are not currently open source. But, he added, over time these will be made open source as Red Hat "develops its own cross-platform solution."
Red Hat also wanted to make sure that RHEL customers did not get the wrong impression and think that customers using Xen will be left in the lurch. "We are fully committed to support Xen through the lifecycle of RHEL 5," explained Thadani. This includes adding new features, putting out bug fixes, providing long-term maintenance, and so forth. "However, our strategic direction is KVM, and we will be making tools available to companies to transition them from Xen to KVM."
Pricing and packaging specifics of the forthcoming products were not announced, but the first KVM-related products will debut in about three months. That should be the KVM hypervisor embedded in RHEL 5.4, if it takes about six months to rev the operating system. ®