Monday, April 23, 2007

first look at CentOS 5 Xen

I have just installed a machine running CentOS 5 as a Xen server. I installed a full GUI environment on the dom0 so that GUI tools can be used for managing the virtual servers.

The first problem I had was selecting the "Installation source", it's described in the error message as an "Invalid PV media address" when you get it wrong which caused me a little confusion when installing it at 10PM. Then I had a few problems getting the syntax of a nfs://1.2.3.4:/directory URL correct. But these were trivial annoyances. It was a little annoying that my attempts to use a "file://" URL were rejected, I had hoped that it would just run exportfs to make the NFS export from the local machine (much faster than using an NFS server over the network which is what the current setup will lead people to do).

The first true deficiency I found with the tools is that it provides no way of creating filesystems on block devices. The process of allocating a block device or file from the Xen configuration tool is merely assigning a virtual block device to the Xen image - and only one such virtual block device is permitted. Then the CentOS 5 installation instance that runs under Xen will have to partition the disk (it doesn't support installing directly to an unpartitioned disk) which will make things painful when it comes time to resize the filesystems.

When running Debian Xen servers I do everything manually. A typical Debian Xen instance that I run will have a virtual block device /dev/hda for the root FS, /dev/hdb for swap, and /dev/hdc for /home. Then if I want to resize them I merely stop the Xen instance, run "e2fsck -f" on the filesystem followed by "resize2fs" and the LVM command "lvresize" (in the appropriate order depending on whether I am extending or reducing the filesystem).

Xen also supports creating a virtual partitioned disk. This means I could have /dev/lvm/xenroot, and /dev/lvm/xenswap, and /dev/lvm/xenhome appear in the domU as /dev/hda1, /dev/hda2, and /dev/hda3. This means that I could have a single virtual disk that allows the partitions to be independently resized when the domU in question is not running. I have not tried using this feature as it doesn't suit my usage patterns. But it's interesting and unfortunate that the GUI tools which are part of CentOS don't support it.

When I finally got to run the install process it had a virtual graphics environment (which is good) but unfortunately it suffered badly from the two-mouse-cursor problem with different accellerations used for both cursors so the difference in position of the two cursors varied in different parts of the screen. This was rather surprising as the dom0 had a default GNOME install.

5 comments:

Anonymous said...

I tried to install a guest ( dom1 ) on my CentOS 5 Xen installation but i couldnt get it use any http or ftp address for the sources i gave it. ;-(

Anonymous said...

That was a nice article
But how did you create the block device

Anonymous said...

True, same experience with me, I was able to install only CentOS 5 guest OS by accessing the CD as a HTTP source trough running apache httpd server on dom0 and symbolic link in /var/www/html/ to the mounted DVD/CD source and via the IP address of the dom0 (it is not working with http://localhost/centos or http://127.0.0.1/centos but only with the assigned IP address to the eth0 interface). Then the "cursors problem" is the same as described, which makes it very difficult to work in the guest graphical console... And yes, the Xen graphical console functionality is rather disappointing, very limited comparing to the xm tool, no right mouse clicks and so on...

Anonymous said...

I ran into all sorts of headaches myself. I am actually coming from the Gentoo side of things where I do the entire Xen installation from source. The portage builds aren't what I need at the moment.

However, I have to familiarize myself with CentOS since my workplace is going to standardize on CentOS for most Linux applications and RHEL where it's absolutely required by the application vendor (Oracle Enterprise Manager and Zimbra in our case).

Assuming that you're using the SVM/HVM features of a new processor (Intel's Vanderpool or AMD's Pacifica), it's very helpful to know that when you run that way, you're really running a modified version of QEMU. And if you're familiar with QEMU, you'd know that it's possible to get "seamless" mouse support using the USB tablet device. Check out the info I posted here:

http://qemu-forum.ipi.fi/viewtopic.php?t=2720&highlight=

If you have a Windows guest, it shouldn't take more than configuring the USB and tablet support for the VM. The Xen version of QEMU will present a virtual tablet device which allows for better mouse tracking. And Windows XP/Server 2003 and up have the tablet driver built in, so the "guest" should be fine.

With a Linux guest, you will need to modify your Linux guest's X instance to contain the tablet device driver. It's not standard with Xorg or XFree86. The link I provided above should give you enough info.

Note that this won't help during installation, it will only help with the final deployment of the VM. AND... it only applies if you're using the SDL display and not VNC. Hope this helps someone. Meanwhile I'm back to trying to figure out how to build my own Linux guest WITHOUT HVM since I'm on an older box.

Anonymous said...

You don't need RHEL for Zimbra :p CentOS works just fine!