Fears come home

Just two weeks ago, I revisited my virtualization options, with a view to making the system more reliable - primarily by using mirrored disks.

In the end I stuck with a kludged up process for Citrix XenServer, but with a worry about how this would impact patching and upgrades.

This week my XenCenter instance told me that 6.0.2 was out and I should upgrade.

Now there are two ways to upgrade a XenServer; one is via the XenCenter console where it pushes the updates, the other is to boot off the CD and upgrade.

Things started to look worrying when the XenCenter method (which I've never tried before) reported losing connection to the XenServer, and looking in the logs it reports that there is insufficient disk space to perform the upgrade. Huh. Things took a turn for the worse when the CD method refused to believe the old install even existed, and would only do a new install (which might have been due to the system not finding or activating the md devices, and due to the installer only looking at physical disks).

So my worries were definitely on firm ground; how do I upgrade?

Now this upgrade was merely a series of minor patches and changes that didn't impact me. But, going forward, I would end up being stuck with an out-of-date platform if I wasn't careful.

So XenServer was, pretty much, out of the game. I was going to be forced to use something else.

I looked back at my work, 2 weeks ago, and decided to give CentOS+KVM another shot. The main reason I'd dropped this was that serial console installs would not work.

This time I bit the bullet, and decided to build out a "templating" solution. I built one CentOS 5.7 install and one CentOS 6.2 install. I used RAW image files. So now I can use "losetup" and "kpartx" and then mount the images and "sanitise" the result (disable SELinux, remove firewalls, add my default user/passwd, remove log entries). The result is an OS template image which can be copied around as needed. I then worked out a simple XML file which can be used to generate new virsh definitions.

The result is a BUILD script and an TEMPLATE.xml file which can be used:

# ./BUILD RH62.x86_64.template.img newstest d6:05:8b:cd:37:c0
Copying /var/lib/libvirt/images/TEMPLATES/RH62.x86_64.template.img to /var/lib/libvirt/images/newstest.img
Defining VM
Domain newstest defined from /tmp/tmp.NaiOX4rJNe

# virsh start newstest
Domain newstest started

% virsh console newstest
Connected to domain newstest
Escape character is ^]

CentOS release 6.2 (Final)
Kernel 2.6.32-220.4.2.el6.x86_64 on an x86_64

newstest login: 
In this case I specified a MAC address so that this new machine matched the DHCP config I'd already setup; otherwise I let virsh pick a MAC address at random and the new host gets a random IP address from the pool.

Using this method I don't need to worry too much about serial installs; I don't even need to do an install for new VMs I've previously templated.

Now I built these machines out using a 4Gb disk which results in approx 3.2Gb root. The OS takes up 700Mb, maybe. That doesn't sound like a lot, but the idea is that data volumes can be added extra to this. Thus the ADD_DISK script, which can be used to add vdb...vdk as datadisks. For these I'll likely not partition them, and use as raw devices, so it'd be easy to resize as necessary.

newstest.ttyS0% df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/vda2              3107344    740068   2209428  26% /
tmpfs                   251356         0    251356   0% /dev/shm
/dev/vda1               495844     49071    421173  11% /boot
/dev/vdb              20158332    176196  18958136   1% /datadisk

So far I've spoken about Linux. I also did a standard install of Windows to verify it works. Just as expected. I'm not sure if this is slower or faster than XenServer; it's hard to tell when the display technology is different!

We'll have to see how this works out, long term.


Last modified: Sunday, 04-Mar-2012 17:14:52 EST