Difference between revisions of "Chapter 6: domU Management: Tools and Frontends"

From PrgmrWiki
Line 8: Line 8:
 
tools are not fully developed.
 
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.<sup>[[#Footnotes|2]]</sup> 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.
  
 
==Tools for the VM Provider==
 
==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, <tt>virt-manager</tt> on Debian, it
 +
would be a difficult process, contrary to the dictates of nature.<sup>[[#Footnotes|3]]</sup> 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===
 +
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/.''
 +
 +
====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''. For Etch, we
 +
appended:
 +
 +
<pre>
 +
#
 +
# 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
 +
</pre>
 +
 +
<blockquote><b>NOTES: </b>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.</blockquote>
 +
 +
Then run, as usual:
 +
 +
<pre># apt-get update
 +
# apt-get install xen-tools
 +
</pre>
 +
 +
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 <tt>--manual</tt>
 +
option. For example:
 +
 +
<pre># xen-create-image --manual</pre>
 +
 +
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.<sup>[[#Footnotes|4]]</sup> Put your preferred options in
 +
''/etc/xen-tools/xen-tools.conf''. We would use something like this:
 +
 +
<pre>
 +
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
 +
</pre>
 +
 +
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 <tt>initrd</tt> and kernel, specify literal directives that’ll wind up in the
 +
final domU config file. Of the remaining options, most are self-explanatory;
 +
<tt>size</tt> specifies the filesystem size, <tt>swap</tt> 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
 +
<tt>dir = /path/</tt> rather than an LVM group. If you do that, make sure that the
 +
directory exists, otherwise the image creation step will fail silently and <tt>xen-create-image</tt> will populate the directory where the filesystem would have been
 +
mounted. This is almost certainly not what you want.
 +
 +
Also note the <tt>dist=</tt> line; this specifies which set of postinstall ''hook'' scripts
 +
<tt>xen-create-image</tt> will run to configure the new domain. If there isn’t a
 +
directory under ''/usr/lib/xen-tools'' corresponding to the <tt>dist</tt> value, <tt>xen-create-image</tt> 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:
 +
 +
<pre># xen-create-image mercutio.prgmr.com</pre>
 +
 +
<blockquote><b>NOTES: </b>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.</blockquote>
 +
 +
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 <tt>debootstrap</tt> to install sarge (Debian 3.1).
 +
 +
Easy.
 +
 +
====Xen-tools and RPM-based DomU Images====
 +
The first versions of Xen-tools were developed with <tt>debootstrap</tt> 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 <tt>debootstrap</tt>-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 <tt>apt</tt> 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 <tt>xen-create-image</tt>, with a simple command line
 +
like the following:
 +
 +
<pre>
 +
# xen-create-image --hostname tybalt.prgmr.com --install-method=rinse
 +
dist=centos-5
 +
</pre>
 +
 +
No problem.
 +
 +
====Xen-tools Postinstall====
 +
After the image is installed, but before it’s started for the first time, <tt>xen-create-image</tt>
 +
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 <tt>--role <script></tt> 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===
 
===libvirt, virsh, and virt-manager===
 
==Administering the Virtualized Data Center==
 
==Administering the Virtualized Data Center==
 
==Administration for the VM Customer==
 
==Administration for the VM Customer==
 
===Xen-shell===
 
===Xen-shell===
<sup>[[#Footnotes|2]]</sup>
+
 
<sup>[[#Footnotes|3]]</sup>
 
<sup>[[#Footnotes|4]]</sup>
 
 
<sup>[[#Footnotes|5]]</sup>
 
<sup>[[#Footnotes|5]]</sup>
 
==Footnotes==
 
==Footnotes==
<sup>[[#top|1]]</sup>
+
<sup>[[#top|1]]</sup>A position unlikely to occasion much disagreement among sysadmins.<br />
<sup>[[#Footnotes|2]]</sup>
+
<sup>[[#top|2]]</sup>We blame Python’s scorched-earth policy toward compatibility.<br />
<sup>[[#Footnotes|3]]</sup>
+
<sup>[[#Tools for the VM Provider|3]]</sup>Of course there are packages, but they’re less closely integrated.<br />
<sup>[[#Footnotes|4]]</sup>
+
<sup>[[#Configuring Xen-tools|4]]</sup>Cdrecord, anyone?<br />
<sup>[[#Footnotes|5]]</sup>
+
<sup>[[#Footnotes|5]]</sup><br />

Revision as of 02:14, 1 July 2010

Fishtank.jpg

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.

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

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

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. 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.

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.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).

Easy.

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

No problem.

Xen-tools Postinstall

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

Xen-shell

5

Footnotes

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.
4Cdrecord, anyone?
5