Xen is a hypervisor virtual machine that runs multiple open-source operating systems.
In the last half century, microcomputers have become increasingly powerful. Server systems have grown so powerful, that many enterprise servers typically are underutilized. Modern computers are sufficiently powerful to use virtualization to present the illusion of running many virtual systems on a single machine. Each virtual system runs a separate operating system instance simultaneously. So, you can run multiple instances of Linux at the same time on the same machine, or you can run combinations of operating systems, such as Linux, FreeBSD, Windows and so on. This has led to a resurgence of interest in Virtual Machine (VM) technology, which has been around for decades on bigger iron.
The Systems Research Group at the University of Cambridge Computer Laboratory originally developed Xen (open-source virtualization software) as part of the XenoServers Project, funded by the UK-EPSRC.
XenoServers aims to provide a “public infrastructure for global distributed computing”. Xen plays a key part in that project, allowing users to partition a single machine efficiently to enable multiple independent clients to run their operating systems and applications in an environment. See www.cl.cam.ac.uk/xeno for more information on the XenoServers Project.
Xen is an x86 virtual machine monitor that allows multiple commodity operating systems, such as Linux and MS Windows, to share conventional hardware in a safe and resource-managed fashion. It is designed with minimal performance overhead. As a result, the virtualized instances of operating systems have close to native performance. The Xen folks achieve this by providing a virtual machine abstraction to which operating systems, such as Linux and MS Windows, can be ported with minimal effort. Xen has, according to a number of benchmarks, considerably out-performed competing commercial and freely available solutions.
One of the major uses of Xen so far has been for consolidation of servers. An organization can shift server software hosted on multiple physically separate servers and locate them onto a single server, by using virtual machines for each individual server. For example, it is now possible for a company to host Sendmail on a FreeBSD installation while hosting the Apache Web server on Red Hat Enterprise Edition, both on the same physical server.
This enables enterprises to reduce their total cost of ownership by using a few servers to do tasks that used to require many servers. Server consolidation also makes it easier to manage systems.
Xen can enable the development of distributed Web services. This gives users the perception that services are hosted on separate systems, but they, in fact, are hosted on the same physical system. This leads to huge savings in IT budgets in deploying service-oriented applications and provides a platform for hosting other network-centric applications.
Xen has been a boon in operating system research. Through Xen, it is now possible to implement new kernel-level algorithms and test them in a virtual environment without affecting the host OS. In Linux kernel development, employing user-mode Linux is popular; however, Xen has out-performed user-mode Linux in a number of benchmarks.
Xen's virtualization capabilities have enabled organizations to keep their servers available 24/7. Organizations can launch a temporary virtual server to keep services available while patching and upgrading an OS on the virtual server they normally use to provide those services.
Xen also enables organizations to run legacy applications on new hardware, protecting their past investments.
Now that we have a taste of the potential applications and advantages Xen offers, let's briefly look how it compares to other approaches and explore some salient features of its internal workings.
Hosting different operating systems in single server is nothing new. Many desktop PCs nowadays are dual-boot systems, where at least two different operating systems are installed in a single machine, each running a set of software specific to each.
When users require both operating systems to run at the same time, there are several options. They can get two computer systems and dedicate each system to each service. They can use an emulator such as Wine or Win4Lin to run services from MS Windows on Linux, or use CoLinux to run unmodified Linux services on MS Windows.
However, these approaches have certain drawbacks. Getting two servers to host two services is inherently expensive and would lead to underutilization of resources. Wine, Win4Lin or other emulators often have performance, scalability and compatibility problems.
So, the best solution in many cases is to run virtual machine software on a single machine and host both operating systems at once on the same machine.
Proprietary virtualization systems exist, such as VMware Workstation [see page 56 for Mick Bauer's review of VMware Workstation 5.5]. Software, such as VMware, implements what is called full virtualization. VMware virtualizes every aspect of the computer. VMware, therefore, introduces a good deal of overhead. The concurrent operating systems often run more slowly than usual. As hardware becomes cheaper and more powerful and software becomes more optimized, this lag in performance may not be noticeable in the future, but currently it poses a problem.
VMware does have enterprise-level commercial products, such as ESX Server, which have better performance than the VMware Workstation product, and such a product may be able to run virtualized operating systems close to their native performance. However, benchmarks of this product are not available, and VMware Workstation consistently has under-performed Xen in various benchmark tests.
VMware's approach does have one large advantage over Xen's approach. VMware is capable of virtualizing proprietary operating systems. As I discuss later in this article, you have to port an operating system's kernel to Xen for it to work with Xen. You cannot run an operating system on Xen otherwise.
Xen is a virtual machine hypervisor. That is, it doesn't run on any OS, it makes an OS run on it! Xen runs at the highest priority level the x86 architecture allows (called Ring 0). It makes the OS get the second-highest priority in x86 architecture (called Ring 1).
Xen provides certain libraries to which the OS kernel has to be ported in order to work with Xen. Porting an OS to run on Xen is similar to porting the OS to a new hardware platform; however, the process is simplified because the paravirtual machine architecture is very similar to the underlying native hardware. Although the kernel has to be ported, Xen does not require any modification to user applications, which can run unaltered on a Xen system.
So far, only open-source operating systems have been ported to Xen. Unless Microsoft releases a Xen-enabled Windows version, we might not get the benefit of a completely virtualized MS Windows. So far, Linux ports are available, and FreeBSD, NetBSD and Solaris 10 ports are underway.
The developers of Xen had to overcome some major challenges to partition successfully a modern machine's resources amongst multiple guest operating systems. First, virtual machines had to be isolated from one another—that is, problems in one machine must not affect the working of other virtual machines. Second, it was necessary to support a variety of different operating systems to accommodate the heterogeneity of popular applications, such as enterprises commonly using a mix of Linux and MS Windows installations to support their working. Third, the performance overhead introduced by virtualization should be small. Xen's approach addresses each one of these challenges successfully. See “Xen and the Art of Virtualization” at www.cl.cam.ac.uk/Research/SRG/netos/papers/2003-xensosp.pdf, which discusses Xen's approach in detail.
We'll go through some salient features of Xen's approach.
As stated earlier, Xen is a hypervisor that uses paravirtualization, when an operating system is ported to Xen. Xen has access to some internal OS kernel information in order to manage the system. This porting also gives the guest OS kernel access to real as well as virtual information, which has specific advantages for time-critical tasks. Paravirtualization permits very high-performance virtualization, even on architectures like x86 that don't inherently support virtualization.
Paravirtualization enables Xen to multiplex physical resources at the granularity of an entire operating system and is able to provide performance isolation between each VM. This also allows a range of guest operating systems to coexist, without having any effect on each other. Xen's paravirtualization approach allows users to run applications in a resource-controlled fashion. Furthermore, it provides an extremely high level of flexibility, because users can create dynamically the precise execution environment their software requires. Unfortunate configuration interactions between various services and applications are avoided.
As mentioned previously, Xen is primarily developed for the x86 architecture; however, it does not support all x86-based processors—only those that are P6 or newer, including Pentium Pro to Pentium 4 and Intel Celeron and Intel Pentium Xeon processors. Apart from Intel, AMD processors from Athlon to AthlonXP and FX processors are supported, as well as the AMD Duron.
Interested readers may want to try out Xen for themselves, without installing the entire system. The Xen Project provides a live CD demonstration of Xen, which comes with both Debian and CentOS. The live CD version can be a powerful tool for demonstrating the features of Xen. It is possible to boot in to any of the provided distributions and start new instances of either distribution, as many times as the system memory allows.
It is also possible, in the live CD version, to monitor the resource usage of all virtual machines in real time and start applications in each virtual machine.
For power users who want to get down to installing Xen, the following is a brief guide. Installing Xen is a three-way process. You install Xen and its user-level tools, then configure your bootloader and, finally, define the VM configuration files for each guest OS.
Installing from binary tarballs or an RPM package is the easiest way to install Xen. For binary tarballs, simply do this:
bash# tar zxvf xen-3.0-install.tgz bash# cd xen-3.0-install bash# sh ./install.sh
For an RPM package, do this:
bash# rpm -iv xen-3.0-i686.rpm
(or whatever the name of the RPM is).
Installing Xen from source is more complicated, as it involves patching and recompiling the Linux kernel. Installing from source is not covered in this article, and is described thoroughly in the Xen User Manual (www.cl.cam.ac.uk/Research/SRG/netos/xen/documentation.html).
After Xen has been installed, we need to configure the bootloader. For GRUB users, edit the menu.lst file, and add this entry:
title Xen kernel /boot/xen-3.0.gz dom0_mem=32768 module -->/boot/vmlinuz-2.6-xen0 root=/dev/hda7 ro console=tty0
vmlinuz-2.6-xen0 is the kernel image that would have been installed by the tarball binaries or RPM; if you install from source, replace the name of the image here.
Also be sure to replace the name of the root filesystem to suit your system (in this example, it is root=/dev/hda7).
For LILO users, do the following:
image="/boot/xen-3.0.gz label="Xen" root="/dev/hda7" read-only append="dom0_mem=32768"
After Xen has been installed and configured, you are now ready to boot in to Xen and start your first virtual machine.
After rebooting and starting your Xen installation, which resembles a normal Linux startup, log in to Domain0. That is the most-privileged domain in a Xen system.
From here, users can create virtual machines that will run guest operating systems, and start and stop virtual machines.
To create a new virtual machine, you need to define a configuration file for it. Xen comes with two default configuration files in the /etc/xen directory named xmexample1/ amd xmexample2/. The configuration files contain many parameters, but fortunately, many of them are optional. You need only a few configured parameters to get your virtual machine running. Some important parameters include:
Kernel: which kernel to boot.
Root: the root filesystem.
Disk: on which disk partition the system is installed.
Memory: define how much memory the virtual machine should use.
A sample configuration file may look like this:
kernel = '/boot/vmlinuz-2.6.12.6-xen' disk = [ 'phy:hda1,hda1,w' ] root = '/dev/hda1 ro' memory = 128
After declaring a configuration file for the virtual machine, you can boot up the machine by typing the following:
bash# xm create -c /root/myOSconf vmid=1
where myOsconf is the name of the configuration file.
After this, a new window will pop up, and you will see a normal Linux startup until you reach the login screen, and from there you can enjoy your new guest OS.
Xen is mature, open-source virtualization software that creates many new opportunities for organizations in reducing their total cost of ownership and providing more dependable and high-availability applications. Commodity x86-based systems provide all of this, with a minimum cost of porting an operating system to Xen.
The developers of Xen have tested Xen against other popular virtualization solutions, such as VMware Workstation and user-mode Linux. In all tests conducted, Xen out-performed the other approaches—in standard benchmark tests, such as Spec Int200, Spec Web99, dbench and many more. The results were published in a research paper, available at www.cl.cam.ac.uk/Research/SRG/netos/papers/2003-xensosp.pdf.
