At the Red Hat Summit in September, Red Hat released Red Hat Enterprise Linux (RHEL) v5.4, the fourth update to RHEL 5. This release marks a notable change in the open source OS leader's virtualization
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
Xen hypervisor in RHEL
Commodity x86 virtualization is just over 10 years old, with VMware's first forays into the market in early 1999. After two years of development, XenSource introduced the first open source x86 hypervisor in 2004. By 2006, major Linux vendors were clamoring for an open source virtualization hypervisor, and Xen seemed to be the likely candidate. In June 2006, Novell released SUSE Linux Enterprise Server 10 with the Xen hypervisor as an optional kernel, and Red Hat followed in March 2007 with the inclusion of an optional Xen hypervisor kernel in RHEL 5.
The Xen hypervisor requires a services partition to operate. This partition, called domain zero (DOM0) in Xen vernacular, is a Linux kernel linked to the Xen hypervisor sources. As a result, RHEL 5 includes two kernels: the standard RHEL 5 Linux kernel without Xen as well as the Xen hypervisor linked with the RHEL 5 Linux kernel. Users install the appropriate kernel on the server based on whether or not they plan to virtualize. This means that if a Red Hat user decides to virtualize a server that currently runs an application without virtualization, there must be a complete re-installation with the Xen-based kernel -- but this is no different than converting a physical server into a VMware ESX virtual host server.
However, Xen has never sat well with Red Hat. The company likes a level of control over its open source distribution that it never had with Xen, especially after Citrix acquired XenSource (the maintainers of the Xen project) in 2007. Furthermore, in order to build a usable hypervisor, Xen requires modifications to the standard Linux kernel. As a result, the Linux kernel community has yet to -- and probably will never -- allow Xen sources to become part of mainline Linux kernel development.
Red Hat recognized this as a potential issue and had the foresight to develop a management library, called "LIBVIRT," to abstract open source hypervisor management. This is Red Hat's key to switching out hypervisors without changing the management infrastructure. LIBVIRT was released with RHEL 5 and is still the interface to which all Red Hat virtualization management applications are written.
KVM virtualization in RHEL
In 2008, Red Hat acquired Qumranet, another open source virtualization company. Qumranet developed Kernel Virtual Machine (KVM), a Linux-based virtualization hypervisor, which extends the Linux kernel to create virtual machines. It doesn't require modifications to the Linux kernel and has been accepted into mainline Linux kernel sources. The Qumranet acquisition gave Red Hat two things it wanted: control over the hypervisor sources and a hypervisor that is part of the mainline Linux kernel.
KVM operates differently than Xen, however. Xen includes its own kernel for thread scheduling and dispatching virtual machines. KVM uses the Linux kernel for these operations. Xen is classified as a type 1 hypervisor because it has its own kernel, and KVM is classified as a type 2 hypervisor because it uses the kernel of another host operating system.
There are pros and cons of each architecture. Before jumping to the conclusion that KVM is like Microsoft Virtual Server 2005 or VMware Workstation, understand that KVM has the benefit of the Linux kernel, which can be slimmed down to just the minimum requirements, rendering such comparisons to Windows host virtualization products invalid.
RHEL 5.4 marks a turning point for Red Hat, because KVM is now the preferred hypervisor for open source virtualization. Red Hat will offer Xen until the end of RHEL 5's lifecycle in 2014. Red Hat has put its weight behind KVM, as is evidenced with the recent Microsoft-Red Hat product cross-certifications. Red Hat certified Windows guests running on the RHEL 5.4 KVM hypervisor, but has no intention of certifying Windows guests on the Xen hypervisor.
Xen-to-KVM migration: Not so easy
There are two aspects of hypervisor migration that must be considered: the management infrastructure and the guest operating systems that run on the hypervisor. Management infrastructure issues have been handled by LIBVIRT. The virtual infrastructure management abstraction library allows management of either Xen or KVM using LIBVIRT-enabled tools.
The guest OSes are another story. They must be modified or rebuilt in order to move from Xen to KVM. The virtual machines in which they run must also be defined anew in the KVM world. Furthermore, the paravirtualized device drivers -- special drivers for LAN and DISK that allow guest OSes to interact directly with the hypervisor for improved performance -- must be replaced.
Paravirtualized KVM drivers are included in RHEL 4.8 and later guest OSes, but in every case, the guest operating system must be re-installed to migrate from Xen to KVM paravirtualized device drivers. Red Hat has a tool called Xenner, which allows a Xen guest to run in a KVM hypervisor, but because it interjects additional overhead, it's not recommended for long-term or production use.
Red Hat recognizes that this migration can take a long time, which is why Xen is still available and supported in RHEL 5.4 and subsequent updates until the end of RHEL 5's lifecycle. But don't expect to see Xen supported in RHEL 6. I hope Red Hat will supply a tool that performs a guest Xen-to-KVM migration. Such a tool would change the paravirtualized device drivers and make the other guest boot modifications that are needed for a previous Xen guest to run properly on the KVM hypervisor.
ABOUT THE AUTHOR: Richard Jones is vice president and service director for Data Center Strategies at Midvale, Utah-based Burton Group. He can be reached at email@example.com.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at firstname.lastname@example.org.
This was first published in October 2009