The Book of Xen Part 7

Omitting the standard functions and such, the script looks something like this: #!/bin/sh dir=$(dirname"$0") ."$dir/xen-script-common.sh"

."$dir/xen-network-common.sh"

findCommand"$@"

evalVariables"$@"

op_start(){ if[""${bridge}"="null"];then return fi

create_bridge${bridge} iflink_exists"${bridge}";then ipaddressadddev$bridge$bridgeip iplinkset${bridge}uparpon iprouteaddto$brnetdev$bridge fi

if[${antispoof}='yes'];then antispoofing fi }

op_stop(){ iproutedelto$brnetdev$bridge iplinkset${bridge}downarpoff ipaddressdeldev$bridge$bridgeip brctldelbr${bridge} }

case"$command"in start) op_start ;; stop) op_stop ;; *) echo"Unknowncommand:$command">&2 echo'Validcommandsare:start,stop'>&2 exit1 esac We've cut out the show_status show_status function to save s.p.a.ce; the full version of this script is available at function to save s.p.a.ce; the full version of this script is available at http://en.opensuse.org/Xen3_and_a_Virtual_Network. We've also removed the default values for parameters like $bridgeip $bridgeip because that's site specific, and we removed the declarations for because that's site specific, and we removed the declarations for create_bridge create_bridge and and add_to_bridge add_to_bridge because those are provided by because those are provided by xen-network-common xen-network-common.

Call this script with a pair of lines like the following in /etc/xen/xend-config.sxp /etc/xen/xend-config.sxp: (network-script'network-virtualbridgeip="10.0.0.1/24"brnet="10.0.0.1/24"') (vif-scriptvif-bridge)

Further Thoughts Variants of this same technique can be used to provide logging and accounting on a per-domain basis, or they can set up domain-specific firewall rules just by editing the network scripts. Ultimately, Xen's networking infrastructure is so flexible that you're able to do anything with a domU that you can with the dom0 (or, for that matter, with a non-Xen system), and there are enough script hooks to do it in an automated fas.h.i.+on.

Chapter6.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,[34] and second, because the add-on tools are not fully developed. 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 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. 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.[35] 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-sh.e.l.l, which is a useful minimal customer-facing tool. 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-sh.e.l.l, which is a useful minimal customer-facing tool.

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, a.s.suming 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 virt-manager on Debian, it would be a difficult process, contrary to the dictates of nature. on Debian, it would be a difficult process, contrary to the dictates of nature.[36] In this chapter, we're going to focus on each tool in its native environment, beginning with Xen-tools for Debian. In this chapter, we're going to focus on each tool in its native environment, beginning with Xen-tools for Debian.

Xen-tools 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 .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 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/.

Installing Xen-tools 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 /etc/apt/sources.list. For Etch, we appended: # #SteveKemp'srepository:Etch # debhttp://apt.steve.org.uk/etchetchmainnon-freecontrib deb-srchttp://apt.steve.org.uk/etchetchmainnon-freecontribNoteSometimes 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-getupdate #apt-getinstallxen-tools Apt will then work its customary magic, installing the Xen-tools scripts and creating a configuration directory, /etc/xen-tools /etc/xen-tools.

For usage information, if you have perldoc perldoc, you can access any of the programs' embedded manual pages by running them with the --manual --manual option. For example: 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.

Configuring Xen-tools 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.[37] Put your preferred options in Put your preferred options in /etc/xen-tools/xen-tools.conf /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 initrd and and kernel kernel, specify literal directives that'll wind up in the final domU config file. Of the remaining options, most are self-explanatory; size size specifies the filesystem size, specifies the filesystem size, swap swap is the amount of swap the domain will have, and so forth. 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/ 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 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 xen-create-image will populate the directory where the filesystem would have been mounted. This is almost certainly not what you want. will populate the directory where the filesystem would have been mounted. This is almost certainly not what you want.

Also note the dist= dist= line; this specifies which set of postinstall line; this specifies which set of postinstall hook hook scripts scripts xen-create-image xen-create-image will run to configure the new domain. If there isn't a directory under will run to configure the new domain. If there isn't a directory under /usr/lib/xen-tools /usr/lib/xen-tools corresponding to the corresponding to the dist dist value, value, xen-create-image 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, 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 /usr/lib/xen-tools/plan9-and pa.s.s the name of the distribution (plan9 in this case) as the dist value. 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-imagemercutio.prgmr.comNoteAlthough 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 a.s.sumes 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 and /dev/verona/mercutio.prgmr.com-swap /dev/verona/mercutio.prgmr.com-swap. It then mounts the disk volume and uses debootstrap debootstrap to install sarge (Debian 3.1). to install sarge (Debian 3.1).

Easy.

Xen-tools and RPM-based DomU Images The first versions of Xen-tools were developed with debootstrap 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 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 debootstrap-like tool. Other systems-even non-Linux systems-can be installed by copying a pristine filesystem image or extracting tarb.a.l.l.s.

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 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 apt repository and downloading via your package manager. repository and downloading via your package manager.

A full discussion of rinse 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 xen-create-image, with a simple command line like the following: #xen-create-image--hostnametybalt.prgmr.com--install-method=rinse dist=centos-5 No problem.

Xen-tools Postinstall After the image is installed, but before it's started for the first time, xen-create-image 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. 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