There are many ways to deploy a Xen guest system, there are 3 types of install that are more common, and documented. I use all three of them since i find each approach more appropriate depending on the circumstances.

---

This is by far the most clean way to install an updated system, since it will basically preform a network bootstrap installation from the most updated versions of the desired Debian version.

The magic is done using the --debbootstrap option in the xen-createimage command.

Remember that you can if the definitions made in /etc/xen-tools/xen-tools.conf don't suit the particular install in are going to preform, you can always override using command line options. A possible example would be

xen-create-image --dir /home/specialvms \
--arch sid \
--size 20Gb \
--memory 2Gb \
--ip 10.1.1.123 \
--gateway 10.1.1.254 \
--netmask 255.255.255.0 \
--hostname myspecialserver \
--passwd \
--debbootstrap \
--swap 1Gb

Of course there are many other options. One should take a moment to read the xen-create-image man page.

---

An alternative to bootstrap a new system, is to use a tarball with a frozen template system. The only con i find in this approach is that you won't be using updated packages. There are a few pros on the other hand, such as

• Faster installation. No link speed dependency.
• Possibility to use already customized templates. Do all the common tweaks you usually do in your new systems only once.
• Amazing way to virtualize already running non-virtual systems. Spare yourself the pain to have to reconfigure a brand new system to meet particular needs.
• Deploy your VMs over the network, from a centralized repository, over rsh or ssh.

All the above can be accomplished by using the --tar option instead of the debbootstrap option. You will only need to provide a tarball containing a full system backp from the template/other system.

Using the earlier example, one would have

xen-create-image --dir /home/specialvms \
--arch sid \
--size 20Gb \
--memory 2Gb \
--ip 10.1.1.123 \
--gateway 10.1.1.254 \
--netmask 255.255.255.0 \
--hostname myspecialserver \
--passwd \
--tar /home/templatevms/etch-clean-install.tar.bz2 \
--swap 1Gb

The installation of a template system which was already made from a VM is smooth and there are no secrets about it, but if you are going to use a template/backup made from a non-virtual system, you will need to fiddle with udev a bit. What happens is that running udev, which is present in nowadays every system, in the VM will make your network device change its name each time the machine boots. That means that you'd have to reconfigure /etc/network/interfaces each new VM boot. The solution is rather simple. You can either remove udev from the VM system,

apt-get --purge remove udev

or you can disable udevs network persistant rules.

rm -f /etc/udev/persistent-net-generator.rules \
/etc/udev/rules.d/z25_persistent-net.rules \
/etc/udev/rules.d/z45_persistent-net-generator.rules

Don't worry about the last approach. You won't be removing any imporant files, only the symbolic links that activate those rules and the already cached rules for the old network cards.

---

Although this method may seem better than the one using a system tarball, I still prefer the other one since it's always easier to manipulate a tarball across networked systems than it is to move around a directory with tons of files and directories and to maintain their right permissions and ownerships. Also if you choose to gzip/bzip your tarball you can save some storage space.

Even so, and since i've used it a couple of times, you may find this one to better suit your needs.

The option to be used this time is –copy and you will only have to provide the path to a directory containing the tree of the source system.

One can use this approach to deploy directly from a system image mounted on a loopback device for instance.

mkdir /mnt/sid
mount /home/sid.img /mnt -o loop

xen-create-image --dir /home/specialvms \
--arch sid \
--size 20Gb \
--memory 2Gb \
--ip 10.1.1.123 \
--gateway 10.1.1.254 \
--netmask 255.255.255.0 \
--hostname myspecialserver \
--passwd \
--copy /mnt/sid \
--swap 1Gb

---

Since i use VLANs to secure access to the VMs, and xen-create-image still doesn't provide a –vif option, i will need to do some final adjustments.

Assuming the new VM will be placed on VLAN 3 i alter the new VM configuration file /etc/xen/brandnewserver.cfg so can tell it the name of the bridge to use. I search for the vif definition and alter it to

vif  = [ 'bridge=xenbr3' ]

Now it's just a matter of booting the new server. Do it with

xm create -c /etc/xen/brandnewserver.cfg

I issue the -c switch so that the machine boots and a console is attached to the current window. Not only it's always a good idea to see a systems first boot, if the installation was made from a non-virtualized template/backup there's a chance that the network interface name was altered and it doesn't match the name specified in the VM's /etc/network/interfaces, and therefor there's no network connectivity. Either remove udev or the udev persistent network rules links and cache. In the eventuality you forgot the -c switch and you got yourself locked out of the server, just attach a VM console to the current session with

xm console brandnewserver

To detach from the VM attached console, just press Crtl+Right Alt+9

That's all folks!

---

If you found the information on these pages usefull, please, consider clicking on one of the sponsored links on the left or use the Paypal button if you're feeling really generous. :)