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.
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
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 udevor 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.rulesDon'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.
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
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. :)