Virtual Appliances:Xen DomU Guide
From rPath Wiki
|
The Xen® virtual machine monitor (VMM) for x86-compatible computers provides an environment capable of executing multiple guest operating system domains (known as DomUs) at near-native performance on a single physical computer. The hypervisor domain (known as the Dom0) on which the DomUs run can be on rPath Linux, another Xen-compatible Linux system, or on an install from the Xen tarballs released by XenSource.
The following sections describe how to install and run DomU images (such as those created in rBuilder) to your choice of Dom0 environment.
Obtain the DomU Image File
The first step to installing a DomU is to obtain a DomU image. rPath has enabled Xen DomU versions of appliances built on rBuilder Online. Also, rPath provides a sample DomU image for testing a Dom0 environment:
After obtaining the DomU image file, create a directory on the Dom0 for storing DomU images (typically /srv/xen). Copy all DomU image files to this new directory. The compressed tar files (with extension .tgz) created by rBuilder can be unpacked when used to reveal the image file (with extension .img).
Create a Configuration File for the DomU
Use the text editor of your choice to create a configuration file in /etc/xen/ on the Dom0 to represent the new DomU image. The following command shows using vim text editor to create a file for an image named new-xen-image:
#> vim /etc/xen/new-xen-image
Root-level access is required to create and edit these files as noted by the "#" command prompt. Replace new-xen-image with a descriptive name for the DomU. This descriptive name is used consistently inside the configuration file. The following is an example of the new-xen-image configuration file contents:
name = 'new-xen-image' memory = '256' disk = [ 'tap:aio:/srv/xen/new-xen-image,xvda1,w' ] vif = [ '' ] bootloader = '/usr/bin/pygrub' on_reboot = 'restart' on_crash = 'restart'
Use the configuration directives from this example as follows:
- name -- Replace the instances of new-xen-image with the same descriptive name you used for the configuration filename.
- memory -- Set the value (in megabytes) of this configuration directive equal to the amount of system memory (RAM) required by the DomU. Check the DomU's (appliance's) documentation to determine these memory requirements.
- disk -- Specify a list of block devices that to export to the DomU. For a raw filesystem image (such as created by rBuilder), specify the image name to replace new-xen-image. In the example, Xen's blktp driver is specified (tap:aio:) in the example to handle the file-based virtual block device (VBD). The additional items xvda1 and w indicate a Xen virtual disk containing a filesystem image as the block device type, and that the device should be writable. For a raw hard disk image (such as created by rBuilder), use xvda instead of xvda1. The Xen DomU images produced by rBuilder Online use the Xen virtual disk block device type by default.
| If you export as read-write using the device name of a disk which is currently mounted on the Dom0 computer, it could have adverse results. See the block device sharing warning in the Xen Users' Manual. |
- vif -- Specify the DomU network interface configuration. One value which may be specified with this directive is the network interface MAC address. If you do not specify an MAC address, it will be set randomly when the DomU boots. One way to use this feature is to define a static MAC address in the DomU that should receive a static IP assignment from DHCP. You should specify a MAC address from the range of addresses in the XenSource Organizationally Unique Identifier (OUI) range 00-16-3E established by IEEE. The following shell command will print out an acceptable and mostly-random MAC address:
#> python -c 'import random; r=random.randint; print "00:16:3E:%02X:%02X:%02X" % (r(0, 0x7f), r(0, 0xff), r(0, 0xff))'
Modify the vif directive in your DomU configuration by adding mac address specification as shown in this example:vif = [ 'mac=00:16:3E:2D:A0:BC' ]
- bootloader -- Specify a bootloader to be used for booting the DomU. For DomUs created with rBuilder Online (rBO), the bootloader used is pygrub; if you are using a DomU created with rBO, this directive should be left unchanged from the example shown. Consult the DomU's (appliance's) documentation to determine if this is different.
- on_reboot -- Specify the action taken by the DomU during reboot. In the example, the DomU will restart if it is asked to reboot. Other valid states for this directive are:
- destroy -- The DomU will be completely cleaned up, with no respawning. This state resembles a typical shutdown.
- preserve -- The DomU will not be cleaned up. This is useful for crash state instances, and ensures debugging information is available.
- rename-restart -- The old DomU will not be cleaned up, but will be renamed so that a new DomU can be started in the place of the old domain. The old DomU is renamed with a numbered suffix (-1, -2, and so on) and is assigned a random UUID. See the xmdomain.cfg(5) manual page for more information.
- on_crash -- Specify the action taken by the DomU if it enters the crash state. In the example, the DomU will restart if it crashes. The valid states for this directive are the same as for the on_reboot directive. See the xmdomain.cfg(5) manual page or Xen Users' Manual for more information on domain configuration directives.
Specify DomU Storage
Choose and specify a DomU storage method from one of the various supported Xen storage mechanisms, known as virtual block devices (VBDs). VBDs can be based on physical disk partitions, raw image files, QCOW images, and logical volume management (LVM) volumes.
Some of the advantages to using a file-based VBD for your DomU storage are:
- Convenience
- Ability to create sparse images, which allocate physical disk space on the Dom0 host only as the file is used
In contrast, LVM-based VBD offers some advantages over file-based VBD:
- Dynamic growing or shrinking of the volume as necessary
- Snapshots
- Avoids certain partitioning issues
The following sections explain how to allocate storage for the DomU using various VBDs.
Raw Filesystem or Disk Images
The example DomU configuration file uses the Xen blktap driver to access a raw filesystem image to provide a VBD for the DomU. Use the tap:aio: specifier for such filesystem or disk images. The following is an example of specifying a disk image with the blktap driver:
disk = [ 'tap:aio:/srv/xen/image_file.img,xvda,w' ]
Note that xvda is specified for disk images while xvda1 should be used for filesystem images.
QCOW Images
QCOW is a disk image format that represents a fixed sized block device in a file. QCOW is one of the supported image formats used by the open-source processor emulator, QEMU. In addition to the general advantages of file-based VBDs, using a QCOW image for the DomU VBD offers the following features:
- Snapshots
- Compression
- Encryption
Use the tap:qcow: specifier for a QCOW image. The following is an example of specifying a QCOW disk image with the blktap driver:
disk = [ 'tap:qcow:/srv/xen/netserver_disk_qcow.img,xvda,w' ]
The following tools and techniques are applicable to working with QCOW images:
- img2qcow -- This utility converts a raw disk or filesystem DomU image (such as those from rBO) into a QCOW image.
- qcow2raw -- This utility converts a QCOW image into a raw filesystem or disk image.
- qcow-create -- This utility creates QCOW images.
If you need to mount a file-based VBD outside of the DomU environment, you can do so with a command like the following example for a filesystem image:
[root@yourhost ~]# xm block-attach 0 tap:aio:/srv/xen/netserver.img /dev/xvda1 w 0 ; mount /dev/xvda1 /mnt/xendisk
See the Xen Users' Manual for more information on file-based VBDs.
LVM-Based VBDs
Logical volume management (LVM) can be used to create LVM-based VBDs. If you did not configure LVM for the Dom0 environment at install time, see Essential Logical Volume Management for Xen DomU Deployment for information about implementing LVM.
Configure a DomU with LVM VBD using the following steps:
- If necessary, unpack the compressed tar archive to reveal the Xen DomU image. These steps work with an image file with the extension .img.
- Determine the size (in megabytes) of the logical volume needed. One way to do this is to use the following command where image_file.img is the name of your image file:
$> ls -kl image_file.img | awk '{printf "%sK\n", $5}' - Configure a logical volume equal to the size (in megabytes) of the DomU image you are deploying on a volume group (such as vg0). The following command assumes the image is 1500 MB and will be named new-xen-image in volume group vg0:
#> lvcreate -L1500 -n new-xen-image vg0
The command should be followed by a message such as Logical volume "new-xen-image" created. - Write the DomU image file to the logical volume. This can be accomplished with dd such as in the following command for the image_file.img example above:
#> dd if=image_file.img of=/dev/vg0/new-xen-image bs=1M - Adjust the disk directive in the DomU configuration file to specify the new LVM VBD created with these steps. The disk line in the configuration file for the new-xen-image example would be as follows:
disk = [ 'phy:vg0/new-xen-image,xvda1,w' ]
| If you require more free space for a DomU after deployment, see the "resize LVM" portion of Essential Logical Volume Management for Xen DomU Deployment. |
Start the DomU
After the DomU is configured, use the xm utility to create and manage a running instance of the DomU. Use the following command to start an instance of the DomU, replacing new-xen-image with your DomU's image name:
#> xm create -c new-xen-image
The -c option in this command provides immediate console access to the new image. Initially, this displays a boot loader menu followed by a typical boot sequence for the image's operating system. Then, it provides a console login for command-line access when necessary (not typically used in virtual appliances). To exit console access and return to the Dom0's command prompt, use Ctrl-] (control+close-bracket).
Use the commands and keys outlined in the next section to manage and access DomUs as they are running on the Dom0.
Use the Xen Console and xm Commands
Configuration for how much system resources to allocate for each DomU will determine the limit of DomUs you can run on available hardware resources. When managing multiple DomUs on a Dom0, use the following commands and keystrokes as a reference:
- xm list -- View running Xen instances
- xm console <domID> -- Start console access to a Xen instance; domID is the number listed in the ID column of the xm list output
- Ctrl-] (control+close-bracket key strokes) -- Exit the console access and return to the Xen DomU command line
Additional Resources
The Xen Troubleshooting Guide provides information for troubleshooting both Xen Dom0 and DomU issues, and the following resources offer additional Xen information.
Manual Pages
- xm(1) -- The xm tool manual page
- xentop(1) -- The xentop tool manual page
- xmdomain.cfg(5) -- The configuration file format manual page
Xen DomUs
Xen Links
- XenSource
- XenSource Wiki
- XenSource Knowledge Base
- XenSource FAQ
- XEN Wiki
- XEN FAQ
- XEN Wikipedia Entry
- XEN 3.0 User Manual
- Xen Networking documentation
