Hardcore Virtualisation - Learn To Love XEN

A few weeks ago I happened to install CentOS-5.3 on a HP blade server, and while scrolling through the software selection dialog, I ticked everything that had to do with Virtualisation and Clustering. Consequently, the new system came up with a shiny Xen kernel and displayed a new icon in the system tools menu, the "Virtual Machine Manager".

Everything else was still pretty normal, but the XEN kernel was constantly reminding me to use it for what it's for, starting a virtual machine. As you may know Xen is not the easiest way to get such a virtual system in place even thought there is a graphical frontend for Xen as well. But there is one advantage of Xen that makes up for all the trouble you are having to get the thing going and that is speed.

Unlike other virtualisation software like VirtualBox that are designed to run unmodified operating systems within an application environment that emulates everything, Xen aims at running on bare hardware as directly as possible. Xen promises to achieve near native performance by putting a kernel software called hypervisor between the hardware and the guest operating system. The hypervisor occupies the privileged part of the CPU driving the guests away into the non-privileged areas of the CPU, but offering to execute privileged code on behalf of the guests whenever they need to use privileged code. It is this design, that speeds up performance but on the other hand makes it necessary that the guests find their way to the hypervisor by using a special Xen-enabled kernel themselves. So operating systems that cannot be modified to have a Xen kernel (like Microsoft Windows) cannot run in the speedy paravirtualized mode.
 

Beware Of Using Defaults

In my experience, what makes Xen very tricky to use at first, is that the default values after a fresh installation can easily break your network connection, leaving you with plenty new network interfaces but without a working local network, let alone the internet. On boot there are two services that are being started for the Xen system, the libvirtd and the xend daemons. These services read a single, very short  configuration file "/etc/xen/xend-config.sxp" which consists of only nine lines:


And line no. 4 is the culprit that renames a working ethernet interface, recreates it and introduces two bridge interfaces leaving a mess in which nothing does work any more. I strongly suspect that this is not what defaults are for. Fortunately a small modification gets Xen on track again. Simply don't use the script "network-bridge" and replace it by /bin/true, problem solved. It seems to me that the Xen defaults are striving to isolate the new virtual machines from the ethernet as much as possible, while someone starting to use Xen might want the virtual machine to use the already working internet adapter with a new fixed IP address in the LAN.

Use Your Own Bridge

If you are after a new virtual machine on the same LAN you can create a config file for a bridge (br0) that replaces your ethernet interface and connect your ethernet interface to that bridge. All firewall settings for your host can remain the same as your new bridge takes over the old fixed IP address and nothing seems to have changed for the LAN. Once your virtual machine is ready to run, just use the new bridge br0 as network interface in the config file and you can assign an unused IP for the guest on the LAN with the default gateway for internet access, and everything works well.

/etc/xen/xend-config.sxp

/etc/sysconfig/network-scripts/ifcfg-br0

/etc/sysconfig/network-scripts/ifcfg-eth0

Try it, and you are beginning to love Xen!