Posted by: Shayna Garlick
(Editor’s Note: scrosby is Simon Crosby, CTO of XenSource)
As the enterprise Linux Distros go to market with integrated Xen virtualization, the jockeying for position based on the promise of integrated virtualization is going to heat up.
You may recall that last year, when Novell shipped SLES 10 with Xen 3.0.2 in Q306, they were criticized by Red Hat, who claimed that Xen was nowhere near Enterprise ready. In fact, SLES 10 delivers what it promises: a basic implementation of Xen in Linux, that allows SLES 10 to virtualize itself. Most of the flak that Novell received had nothing to do with Xen – for example, their use of the Linux loopback driver (which is known to be flaky) for guest block I/O caused some users a lot of pain, and their storage architecture is awkward – having all disks owned by the host makes it difficult to manage guest storage effectively.
The launch of Red Hat’s RHEL 5 with Xen is a very big deal. Why? Red Hat dominates the Linux market and RHEL 5 will deliver the Xen hypervisor to millions of servers world-wide, with a seven year support commitment. The implementation choices Red Hat has made for Xen will have a tremendous impact not only on the RHEL footprint itself, but also on the RHEL derivatives, such as Asianux, Red Flag, CentOS and (it must be said) Oracle “Unthinkable” Linux.
Fortunately, it appears from the beta that I’ve been running, that Red Hat has taken time to understand some of the key subtleties of virtualization. For example, RHEL 5 uses the blktap driver for guest block I/O that XenSource added last summer – a zero-copy, high performance alternative to loopback that I expect will improve performance and avoid the stability issues seen with Linux loopback. Also promising is the Xen-ready RHEL 4.5, which allows RHEL 5 to virtualize some of the Red Hat installed base, and Red Hat’s plans to integrate the cluster technology and file system GFS to deliver infrastructure components for high availability based on Xen.
It’s disappointing that Red Hat has elected not to packaage the Xen project’s implementation of the DMTF CIM standard for virtualization management. Every other virtualization vendor will support the DMTF API, so the virtualization management ecosystem vendors will have to re-jig their products to work with RHEL’s libvirt. Overall, the package still feels very much like Linux that virtualizes more Linux, and Red Hat has been wise not to over promote what this release will allow users to achieve.
RHEL 5 ships Xen 3.0.3, which I find amusing, because at about the same time as VMware and Red Hat announced a deal, in which (amongst other things) Red Hat will certify RHEL on ESX, VMware published a performance benchmark of Xen 3.0.3 vs ESX, in which they claimed that Xen was nowhere near enterprise ready. Admittedly the VMware “study” used Windows as the guest, but for Linux, Xen 3.0.3 easily outperforms ESX. (We also debunked the VMware study, showing XenEnterprise typically equals or beats ESX for Windows and Linux).
You won’t find many users virtualizing Windows using RHEL 5, but Novell is clearly planning a Windows future for SLES 10 SP1. Living up to its chameleon logo, the SUSE team is surely hoping to get some of the new SLES 10 licensees delivered by Microsoft to use SLES 10 to virtualize Linux and Windows. SLES 10 SP1 will package Xen 3.0.4, which has good support for Windows, and Novell recently announced an arrangement with Intel for help to develop Windows drivers for Xen. Hopefully SUSE will improve their storage management architecture for SP1, and overcome the need to emulate the 16 bit graphical SLES installer on Intel VT, which makes installation annoyingly slow.
Ultimately, the jury is still out on whether the Windows IT Pro wants to use Linux to virtualize Windows, even if the Linux comes for free from Microsoft. My guess is that the answer is “no” – and that the platform virtualization model of ESX and XenEnterprise will continue to dominate at least until the arrival of Microsoft’s Windows Hypervisor. <sales plug> XenEnterprise, through its upcoming VHD support and enhanced Windows feature set, allows Windows admins to achieve high performance consolidation today, and migrate to the Windows Hypervisor whenever it arrives. </sales plug> I’m similarly doubtful that having Windows support will cause RHEL customers to switch to SLES in large numbers, no matter how aggressive the Novell pricing. But the topic of Licensing is worth another blog entry on another day…
Bottom line: the Xen hypervisor is an engine, and not a car. A powerful engine that needs a great gearbox, shocks, tires and the body to go with it. ESX Server is a Bentley, XenEnterprise a Lexus. To paraphrase Diane Greene, OS vendors are not virtualization experts. So we shouldn’t be surprised that the first OSV implementations of Xen felt more like a Ford Fiesta, and moreover the Xen feature set has been improving rapidly. Don’t count the distros out just yet – they are very focussed on building value around enterprise ready Xen virtualization, and RHEL 5 marks a great achievement by Red Hat and the Xen community.