The i386 architecture also requires a standard library with the appropriate patches taking advantage of Xen; this is in the libc6-xen package.
In order to avoid the hassle of selecting these components by hand, a few convenience packages (such as xen-linux-system-2.6.32-5-xen-686 and variants) have been made available; they all pull in a known-good combination of the appropriate hypervisor and kernel packages. The hypervisor also brings xen-utils-4.0, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the Grub bootloader menu, so as to start the chosen kernel in a Xen dom0. Note however that this entry is not usually set to be the first one in the list, and will therefore not be selected by default. If that is not the desired behavior, the following commands will change it:
# mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen
# update-grub
Once these prerequisites are installed, the next step is to test the behaviour of the dom0 by itself; this involves a reboot to the hypervisor and the Xen kernel. The system should boot in its standard fashion, with a few extra messages on the console during the early initialization steps.
Now is the time to actually install useful systems on the domU systems, using the tools from xen-tools. This package provides the xen-create-image command, which largely automates the task. The only mandatory parameter is --hostname, giving a name to the domU; other options are important, but they can be stored in the /etc/xen-tools/xen-tools.conf configuration file, and their absence from the command line doesn't trigger an error. It is therefore important to either check the contents of this file before creating images, or to use extra parameters in the xen-create-image invocation. Important parameters of note include the following:
--memory, to specify the amount of RAM dedicated to the newly created system;
--size and --swap, to define the size of the “virtual disks” available to the domU;
--debootstrap, to cause the new system to be installed with debootstrap; in that case, the --dist option will also most often be used (with a distribution name such as squeeze).
GOING FURTHER Installing a non-Debian system in a domU
If the Xen image is not meant to run Debian but another system, another potentially interesting option is --rpmstrap, to invoke rpmstrap in order to initialize a new RPM-based system (such as Fedora, CentOS or Mandriva). Other methods include --copy, to copy an image from an existing system, and --tar, to extract the system image from an archive.
In case of a non-Linux system, care should be taken to define the kernel the domU must use, using the --kernel option.
--dhcp states that the domU's network configuration should be obtained by DHCP while --ip allows defining a static IP address.
Lastly, a storage method must be chosen for the images to be created (those that will be seen as hard disk drives from the domU). The simplest method, corresponding to the --dir option, is to create one file on the dom0 for each device the domU should be provided. For systems using LVM, the alternative is to use the --lvm option, followed by the name of a volume group; xen-create-image will then create a new logical volume inside that group, and this logical volume will be made available to the domU as a hard disk drive.
NOTE Storage in the domU
Entire hard disks can also be exported to the domU, as well as partitions, RAID arrays or pre-existing LVM logical volumes. These operations are not automated by xen-create-image, however, so editing the Xen image's configuration file is in order after its initial creation with xen-create-image.
Once these choices are made, we can create the image for our future Xen domU:
# xen-create-image --hostname=testxen
General Information
--------------------
Hostname : testxen
Distribution : squeeze
Mirror : http://ftp.us.debian.org/debian/
Partitions : swap 128Mb (swap)
/ 4Gb (ext3)
Image type : sparse
Memory size : 128Mb
Kernel path : /boot/vmlinuz-2.6.32-5-xen-686
Initrd path : /boot/initrd.img-2.6.32-5-xen-686
[...]
Logfile produced at:
/var/log/xen-tools/testxen.log
Installation Summary
---------------------
Hostname : testxen
Distribution : squeeze
IP-Address(es) : dynamic
RSA Fingerprint : 25:6b:6b:c7:84:03:9e:8b:82:da:84:c0:08:cd:29:94
Root Password : 52emxRmM
We now have a virtual machine, but it is currently not running (and therefore only using space on the dom0's hard disk). Of course, we can create more images, possibly with different parameters.
Before turning these virtual machines on, we need to define how they'll be accessed. They can of course be considered as isolated machines, only accessed through their system console, but this rarely matches the usage pattern. Most of the time, a domU will be considered as a remote server, and accessed only through a network. However, it would be quite inconvenient to add a network card for each domU; which is why Xen allows creating virtual interfaces, that each domain can see and use in a standard way. Note that these cards, even though they're virtual, will only be useful once connected to a network, even a virtual one. Xen has several network models for that:
The simplest model is the bridge model; all the eth0 network cards (both in the dom0 and the domU systems) behave as if they were directly plugged into an Ethernet switch.
Then comes the routing mode, where the dom0 behaves as a router that stands between the domU systems and the (physical) external network.
Finally, in the NAT mode, the dom0 is again between the domU systems and the rest of the network, but the domU systems are not directly accessible from outside, and traffic goes through some network address translation on the dom0.
These three networking nodes involve a number of interfaces with unusual names, such as vif*, veth*, peth* and xenbr0. The Xen hypervisor arranges them in whichever layout has been defined, under the control of the user-space tools. Since the NAT and routing modes are only adapted to particular cases, we will only address the bridging model.
The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils-4.0 recommends it) to replace the existing eth0 entry:
auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0