There is a new controversy about when it's appropriate to use the term "Xen" to describe open source virtualization implementations. You can read about it in this article,
To write this series, I used the Red Hat Enterprise Linux 5 release candidate. It may have minor differences with the final release of Red Hat Enterprise Linux 5.
VMware versus Xen
Even though VMware and Xen both provide an enterprise-focused server virtualization product, Xen's approach to implementing virtualization has made for some challenges. VMware bases its product on hardware emulation, in which VMware provides a software layer that "looks" like an x86-based machine to a guest operating system. VMware cleverly patches the running guest operating system so that it interacts with the hypervisor, which in turn mediates between the guest operating system and the underlying hardware. This is a powerful technique that allows unmodified operating systems to run as guest machines; however, it takes a toll on performance due to the hardware emulation the hypervisor provides.
Xen's product, by contrast, operates more like a traffic cop, multiplexing access to the underlying hardware resources. Xen dubs this approach "paravirtualization," and one of the primary benefits is that the hypervisor is a very skinny piece of code which imposes little overhead. Tests run against paravirtualized guest operating systems indicate a trivial amount of virtualization performance hit on the order of less than 5%.
A drawback to Xen's approach is that the thin hypervisor requires modification of the guest operating systems so that they run as paravirtualized guests. Specifically, this requires patching the kernels of the guest operating systems to allow interaction with the control structures of the Xen hypervisor. Another drawback to Xen's thin architecture is that underlying services must be provided by a privileged guest operating system. (In Xen parlance, a privileged operating system is called aDom0, and a regular guest operating system is called a DomU.) The privileged guest requires a patched kernel as well, since it must access the same Xen control structures to pass data back and forth with DomUs. In addition, the privileged guest requires multiplex access to underlying resources—such as the processor, memory, network and storage—on behalf of DomUs.
Visually, the Xen architecture looks like this: (View or download the PowerPoint here.)
Getting the proper kernel configurations sorted out in preparation for Dom0 installation and system configuration is pretty complex. The Xen-users mailing list is filled with plaintive queries about problems with Xen installs.
Xen installation in Red Hat Enterprise Linux 5
In order to turn a standard Linux distro into a Dom0, it's necessary to substitute Xen-patched kernel binaries for certain standard kernel binaries. In addition, the system's GRUB boot loader instructions must be modified to add a Xen-based entry that lists the updated kernel binaries in its configuration.
While it can be quite complicated getting this properly configured by hand, Red Hat has negated any need for an end user to tinker with the kernel binaries. The installation wizard that is used for installation on a server can install Xen-enabled binaries automatically.
The way the wizard discerns which binaries to install is based upon two conditions: The installation key the administrator enters during the install process, and whether the person doing the install checks a box labeled "Xen" in a dialog box that comes up during the process. The same dialog box includes "development" and "client" as options, and one or more may be checked. I recommend checking all three to ensure that a full set of utilities is available post-installation.
Once completed, the regular installation process continues to the finish.
Getting a Xen virtualization-ready platform in Red Hat Enterprise Linux 5 is relatively straightforward. At the end of the installation process, when the system boots up, the Xen hypervisor is up and running.
About the author: Bernard Golden is CEO of Navica Inc., a systems integration firm specializing in open source software based San Ramon, Calif. He founded Navica in 2001, after two decades of experience in starting and building successful IT-related organizations. He has previously served as a Venture Partner for an international venture fund and has senior executive positions in a number of private and public software companies, including Informix, Uniplex Software, and Deploy Solutions.
This was first published in March 2007