I got a little confused by what at first appeared to be conflicting information in the XenSource demonstration that I saw earlier this week and the Xen module in my Red Hat Enterprise Linux (RHEL) training. It seems that I hadn’t fully grasped the distinction between Xen as commercialised by Red Hat and Xen as commercialised by XenSource and in this post I shall attempt to clarify the situation.
Somewhat confusingly, the version 4 XenSource products include version 3.1 of the Xen hypervisor. I’d assumed that this was pretty much identical to the Xen 3.0.3 kernel that I can install from the RHEL DVD but it seems not. Roger Baskerville, XenSource’s Channel Director for EMEA explained to me that it’s important to differentiate between the OSS Xen and the Xen Source commercial products and that whilst both Red Hat and XenSource use a snapshot of OSS Xen 3.x.x, the XenSource snapshot is more recent than the one in RHEL due to the time that it takes to incorporate various open source components into a operating system. Furthermore, XenExpress, XenServer and XenEnterprise are designed for bare-metal deployment with little more than the hypervisor and a minimal domain-0 (a privileged virtual machine used to control the hypervisor) whereas RHEL’s domain-0 is a full operating system.
The XenSource microkernel is based on CentOS (itself a derivative of Red Hat Enterprise Linux) with only those services that are needed for virtualisation along with a proprietary management interface and Windows drivers. Ultimately, both the XenSource and RHEL models include a Xen hypervisor interacting directly with the processor, virtual machines (domain-U) and domain-0 for disc and network traffic. Both use native device drivers from the guest operating system, except in the case of full virtualised VMs (i.e. Windows VMs) in which case the XenSource products use signed proprietary paravirtualised Windows drivers for disk access and network traffic (XenSource Tools).
So when it comes to installation, we have two very different methods – whereas XenSource is a bare-metal installation, installing Xen on RHEL involves a number of RPMs to create the domain 0 environment. This is how it’s done:
Method 1 (the simple way) is to select all of the virtualisation tools during operating system installation. Alternatively, method 2 involves installing individual RPMs. At first I just installed the packages containing xen in their name from the /Server directory on the RHEL installation DVD (kernel-xen-2.6.18-8.el5.i686.rpm, kernel-xen-devel-2.6.18-8.el5.i686.rpm and xen-libs.3.0.3025.el5.i386.rpm) but even after rebooting into the Xen kernel I found that there were no management tools available (e.g. xm). Fortunately, I found a forum post that explained my mistake – I had installed the kernel and userspace libraries but not any of the tools/commands and another post that explains how to install Xen on RHEL:
cd /Server
rpm -Uvh kernel-xen-2.6.18-8.el5.i686.rpm
rpm -Uvh kernel-xen-devel-2.6.18-8.el5.i686.rpm
rpm -Uvh xen-libs-3.0.3-25.el5.i386.rpm
rpm -Uvh bridge-utils-1.1-2.i386.rpm
rpm -Uvh SDL-1.2.10-8.el5.i386.rpm
cd /VT
rpm -Uvh --nodeps libvirt-0.1.8-15.el5.i386.rpm
(--nodeps resolves a cyclic dependency between xen, libvert, libvirt-python and python-virtinst.)
rpm -Uvh libvirt-python-0.1.8-15.el5.i386.rpm
rpm -Uvh python-virtinst-0.99.0-2.el5.noarch.rpm
rpm -Uvh xen-3.0.3-25.el5.i386.rpm
At this point, it should be possible to start the Xen daemon (as long as a reboot onto the Xen kernel has been performed – either from manual selection or by changing the defaults in /boot/grub/menu.lst) using xend start. If the reboot took place after kernel installation but prior to installing all of the tools (as mine did) then chkconfig --list should confirm that xend is set to start automatically and in future it will not be necessary to start the Xen daemon manually. xm list should show that Domain-0 is up and running.
Finally, the Xen Virtual Machine Manager can be installed:
cd /Server
rpm -Uvh gnome-python2-gnomekeyring
cd /VT
rpm -Uvh virt-manager
Having installed Xen on RHEL, I was unable to install any Windows guests because the CPU on my machine doesn’t have Intel-VT or AMD-V extensions. It’s also worth noting that my attempts to install Xen on my notebook PC a few months ago were thwarted as, every time I booted into the Xen kernel, I was greeted with the following error:
KERNEL PANIC: Cannot execute a PAE-enabled kernel on a PAE-less CPU!
It turns out that 400MHz front side bus Pentium M processors do not support physical address extensions (PAE) – including the Pentium M 745 (“Dothan”) CPU that my notebook PC uses – and PAE is one of the pre-requisites for Xen.
Finally, it’s worth noting that my RHEL installation of Xen is running on a 32-bit 1.5GHz Pentium 4 (“Willamette”) CPU whereas the XenSource products require that the CPU supports a 64-bit instruction set. The flags shown with cat /proc/cpuinfo can be a bit cryptic but Todd Allen’s CPUID makes things a little clearer (if not quite as clear as CPU-Z is for Windows users).