Chapter 6: domU Management: Tools and Frontends
Most of the material in this book focuses on fairly low-level administrative tasks. We’ve got a couple of reasons for this focus: first, because we feel that it’s better to understand what the GUI tools are doing before trusting them with your data,1 and second, because the add-on tools are not fully developed.
However, the true benefit of Xen is that it allows you to do things with a virtual machine that you can’t do—or can’t do easily—with a simple collection of physical machines. The main advantage of the more advanced management tools is that they exploit Xen virtualization to improve flexibility.
Besides, it gets kind of tedious to do everything from base principles all the time. In this chapter, we’ll take an excursion from our usual fixation on doing things in the most laborious way possible and look at some of the labor-saving innovations available for Xen.
Broadly, we can categorize the various frontend packages by their intended audience; some tools are for the dom0 administrator and some are for the domU administrator (that is, the customer in Xen’s computing-service model). The first group tends to focus on provisioning and destroying VMs, and the second group allows users who most likely don’t have access to the dom0 to control their own VM at a higher level so they can, for example, give the domain a hard reboot or recover when the domU won’t boot at all.
Despite this neat and theoretically useful division of labor, we’re going to ignore the second category almost completely. There are two reasons for this: First, most end users won’t want to do anything especially complex to their Xen instance. In our opinion, most of the Xen control panels are solutions in search of a problem. Second, almost none of the tools that we’ve tried in this category seem to have stabilized as of this writing.2 Instead, we’ll focus on the first category: software to simplify your life as a service provider, ranging from the simple to the elaborate. We’ll end by briefly discussing the Xen-shell, which is a useful minimal customer-facing tool.
- 1 Tools for the VM Provider
- 2 Administering the Virtualized Data Center
- 3 Administration for the VM Customer
- 4 Footnotes
Tools for the VM Provider
When looking for a management tool, as with any piece of software, the first question to ask yourself is, What features do I need? Xen management tools run the gamut from simple provisioning scripts, like Xen-tools, to elaborate data-center-oriented packages, like OpenQRM.
The biggest factor influencing your choice of frontend, assuming that multiple ones provide the necessary functionality, is probably the dom0 operating system. Some frontends, such as Xen-tools, are designed and built with Debian in mind. Some work best with Red Hat. Slackware users, you’re still on your own. Although you can install, say, virt-manager on Debian, it would be a difficult process, contrary to the dictates of nature.3 In this chapter, we’re going to focus on each tool in its native environment, beginning with Xen-tools for Debian.
Xen-tools, at heart, consists of a cross-platform set of Perl scripts for automated installs, so it’s fairly distro agnostic. Even though the authors develop on Debian, distribute .deb packages, and have an Apt repository, Xen-tools is relatively easy to install on other systems, so we encourage you to try it regardless of which distro you’re running. Download a tarball at http://xen-tools.org/.
In the interest of keeping everything flowing smoothly, we installed Xen-tools on a Debian machine using Debian’s Apt system. Because, like everything Xen-related, Xen-tools is under heavy development, we opted to get the package from the author’s own repository to avoid getting an old version.
To do this, add his repo to your /etc/apt/sources.list. For Etch, we appended:
# # Steve Kemp's repository: Etch # deb http://apt.steve.org.uk/etch etch main non-free contrib deb-src http://apt.steve.org.uk/etch etch main non-free contrib
NOTES: Sometimes even the version in Apt is not as current as the one on the website. If all else fails, download the tar package, unpack it, and run make install to install it.
Then run, as usual:
# apt-get update # apt-get install xen-tools
Apt will then work its customary magic, installing the Xen-tools scripts and creating a configuration directory, /etc/xen-tools.
For usage information, if you have perldoc, you can access any of the programs’ embedded manual pages by running them with the --manual option. For example:
# xen-create-image --manual
will print out a long and intimidating man page. Don’t be discouraged; it’s just exposing the bewildering array of options Xen itself makes available. You can simplify things by specifying most of these options ahead of time in the Xen-tools config file rather than by command-line options.
So let’s make a config file. Trust us, it’s much more pleasant to spend a bit of time setting some defaults rather than specifying global options every time you use the command.4 Put your preferred options in /etc/xen-tools/xen-tools.conf. We would use something like this:
lvm = verona size = 2Gb image = full memory = 128Mb swap = 128Mb fs = ext3 dist = sarge initrd = /boot/initrd.img-2.6.16-2-xen-686 kernel = /boot/vmlinuz-2.6.16-2-xen-686 install-method = debootstrap
Fill in appropriate values, as always, and feel free to add from the liberally commented sample config anything that strikes your fancy. Some of these options, like initrd and kernel, specify literal directives that’ll wind up in the final domU config file. Of the remaining options, most are self-explanatory; size specifies the filesystem size, swap is the amount of swap the domain will have, and so forth.
Because we’ve specified an LVM group, domains will be created with LVM volumes as backing store. You can also use filesystem images by specifying dir = /path/ rather than an LVM group. If you do that, make sure that the directory exists, otherwise the image creation step will fail silently and xen-create-image will populate the directory where the filesystem would have been mounted. This is almost certainly not what you want.
Also note the dist= line; this specifies which set of postinstall hook scripts xen-create-image will run to configure the new domain. If there isn’t a directory under /usr/lib/xen-tools corresponding to the dist value, xen-create-image will exit with an instructive error message. If you don’t want to configure the domain at creation time, you can create an empty directory— say, /usr/lib/xen-tools/plan9—and pass the name of the distribution (plan9 in this case) as the dist value.
When you have the config file populated, actually creating domains is so easy as to be almost anticlimactic. Just specify a hostname, preferably fully qualified so that the postinstall scripts can configure the image correctly, on the command line, and the tool will do the rest. For example:
# xen-create-image mercutio.prgmr.com
NOTES: Although setting a fully qualified domain name allows the postinstall scripts to handle
domain configuration, it can cause trouble with the xendomains script on certain
Red Hat derivatives, which assumes a domU name no longer than 18 characters.
With the config file previously shown, this creates two logical volumes, /dev/verona/mercutio.prgmr.com-disk and /dev/verona/mercutio.prgmr.com-swap. It then mounts the disk volume and uses debootstrap to install sarge (Debian 3.1).
Xen-tools and RPM-based DomU Images
The first versions of Xen-tools were developed with debootstrap installs of Debian in mind. However, the package has come a long way, and it’s been generalized to support virtually every system out there. RPM-based distros are covered via a debootstrap-like tool. Other systems—even non-Linux systems— can be installed by copying a pristine filesystem image or extracting tarballs.
Although older versions of Xen-tools used RPMstrap, which we’ve used with some success in the past, the author of RPMstrap has ceased to develop it. Accordingly, the Xen-tools author has been working on a replacement called rinse. It’s the recommended way of installing CentOS and Fedora with Xen-tools, and it’s a fairly neat package by itself.
rinse’s home page is at http://xen-tools.org/software/rinse/. Download it either from the download page at that site or by adding his apt repository and downloading via your package manager.
A full discussion of rinse’s configuration options is probably out of place here. We enjoin you to read the fine manual. However, it works out of the box with an install method for xen-create-image, with a simple command line like the following:
# xen-create-image --hostname tybalt.prgmr.com --install-method=rinse dist=centos-5
After the image is installed, but before it’s started for the first time, xen-create-image does some postinstall work. First it runs some scripts in the mounted domU filesystem to perform setup tasks, like setting the hostname and disabling unneeded gettys. Finally it creates a config file so that you can start the domain.
At this stage you can also have the machine configure itself with a role— specify the --role <script> command-line option to run the corresponding script located in /etc/xen-tools/role.d at the end of the install, taking the mount point of the domU root filesystem as an argument. The roles that you’ll want will depend on your needs. For example, you may want roles that differentiate between web, mail, and dns servers. The Xen-tools distribution comes with some samples that you can build upon.
libvirt, virsh, and virt-manager
Administering the Virtualized Data Center
Administration for the VM Customer
1A position unlikely to occasion much disagreement among sysadmins.
2We blame Python’s scorched-earth policy toward compatibility.
3Of course there are packages, but they’re less closely integrated.