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:
EDIT 2018/01/13 - the original scripts I used are no longer available so I have removed them as links. I don’t use templates any more.
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.