We’ve been strong proponents of using CentOS kickstart to manage our production server environments. We like to use highly customized kickstart CDs that have just the packages we want, plus a hefty postinstall script that sets up all sorts of things for our environment. We also like to use sandboxed environments for our developers. Wouldn’t it be nice to build a xen virtual machine from the kickstart? I’ll tell you how we did it.
This article assumes you’re already familiar with xen, the concept of domains, and the various utilities (xm, virt-install, virt-clone, etc.). If not, pay a visit to xen.org’s support page.
There are two key challenges in getting a custom kickstart CD converted over to a xen domain:
- getting a xen kernel installed
- dealing with the lack of optical media during the installation
During the installation of a xen domain, anaconda automatically installs the kernel-xen package instead of the kernel package. But if you don’t have that package on your install media, it will install the standard kernel, and when you try to boot up your domain, it will fail to start.
Your custom CD probably contains only the packages that you install as part of your kickstart (unless you’ve built a custom DVD, in which case, you may have the entire repository on your disk; if so, some of what I’m going to outline may not apply).
To get around this problem, you’ll want to point virt-install at a full repository. So gather all the files from the standard install media (the DVD or the multiple CDs) in a single directory and export that directory via NFS. For this example, I’m going to copy all the files from the CentOS CDs to /var/xen/install. Once we’ve done that, we issue this command:
exportfs -o no_root_squash *:/var/xen/install
(make sure your nfs service is running before you issue this command). The no_root_squash is important if you’re doing any postinstall work that involves files without world-read permissions (which might happen if you’re dealing with sensitive configuration files). If you don’t specify no_root_squash, then when the install process mounts /var/xen/install over NFS, it won’t be able to read those configuration files, and parts of your postinstall will fail.
Speaking of NFS, why not just install from the optical media? We’re going to be doing a little manipulation of the files, so it’s easier to do this if you make a copy on the local disk. Why not install over HTTP? You could, but if your postinstall script needs to copy files from the CD, it’s a lot easier to modify the postinstall to pull from NFS than it would be to modify it to use HTTP.
You’re going to need to modify your kickstart configuration script to get it to install over NFS. Make a copy of it and put it into /var/xen/install/ks/kickstart.cfg. Now make the following changes:
- change the install type from cdrom to nfs –server=DOM0ADDRESS –dir=/var/xen/install (where DOM0ADDRESS is theIP address of your Domain-0 host)
- change all instances of sda or hda to xvda
If your postinstall is fairly complex, it probably involves accessing files from the kickstart CD. Normally, the postinstall could remount the CD and copy files from CD to local disk. However, we’re going to be installing via NFS, so the postinstall script must be modified accordingly.
- Copy all the files used by your postinstall to the corresponding locations under /var/xen/install
- change the postinstall script so that it remounts the NFS export rather than the CD. Here’s my example:
%post --nochroot<br />#!/bin/sh<br /><br />set -x -v<br />exec 1>/mnt/sysimage/root/kickstart-stage1.log 2>&1<br /><br />echo "==> re-mounting NFS..."<br />mkdir -p /mnt/postconfig<br />mount DOM0ADDRESS:/var/xen/install /mnt/postconfig<br /><br />echo "==> copying files..."<br />cp -r /mnt/postconfig/postinstall_files /mnt/sysimage/tmp
(DOM0ADDRESS is the IP address of the Domain-0 host).
After this first stage of the postinstall runs, the second postinstall script will have access to the files in /tmp/postinstall_files.
Note that depending on what sort of things you’re doing in your postinstall script, you may find that it is incompatible with xen. In our postinstall, for instance, we set up a serial console. This didn’t seem to play nice with xen. You may need to tweak your postinstall to avoid such issues.
Creating the domain
Now it’s time to create the domain.
virt-install -n DOMUNAME -r 512 \<br /> -f /path/to/DOMUDISKIMAGEFILE -s 4 --nographics \<br /> -l nfs:DOM0ADDRESS:/var/xen/install \<br /> -x "ip=DOMUADDRESS<br /> netmask=DOMUNETMASK<br /> ks=nfs:DOM0ADDRESS:/var/xen/install/ks/kickstart.cfg"
The various tokens are as follows:
- DOMUNAME – the name of the new domain
- /path/to/DOMUDISKIMAGEFILE – the full path to the new diskimage file
- DOM0ADDRESS – the IP address of the Domain-0 host
- DOMUADDRESS – the IP address of the new domain
- DOMUNETMASK – the netmask for the new domain’s network
Note that you must specify the DOMU network parameters (ip, netmask) unless the new domain will be on a network with DHCP (even though your kickstart may specify an IP address for the new domain, in order for anaconda to connect to the install location, it needs a network connection). If the new domain is not on the same network as the Domain-0 host, you need to add a gateway parameter, too.
You should see your kickstart proceed in text mode. You may have to answer a question about initializing the drive, but other than that, it should be fully unattended.