Difference between revisions of "Migrating Xen domainU Guests Between Host Systems"

Revision as of 16:18, 11 June 2008

One of the most compelling features of Xen virtualization is the ability to migrate a domainU guest from one host system to another. Of particular significance, however, is Xen's ability to perform live migrations whereby a running guest domainU system is moved from one system to another such that there is only an imperceptible interruption in service. In this chapter we will discuss the requirements for performing live Xen domainU migrations before walking through an example live migration.

Requirements for Xen domainU Migration

Before a Xen guest system can be migrated from one host to another a number of requirements must be met:

• Both the source and destination hosts must have access to the root filesystem (and swap is specified) via the same path name. For example if the root filesystem is contained in a disk image with a path of /xen/xenguest.img then that image file must also be accessible at the same location on the target host. This is most commonly achieved by placing the image files on a file server such that it can be mounted via NFS.

• Both systems must be running compatible processors.

• The target host must have sufficient memory to accommodate the migrated guest domain.

• The source and destination machines must reside on the same subnet.

• The two systems need to be running compatible versions of Xen.

• Firewalls (and SELinux if enabled) must be configured to permit communication between the source and destination hosts.

• Both systems must be configured to allow migration of virtual machines (see below).

As long as the above requirements are met then you are ready to perform a Xen guest migration.

Enabling Xen Guest Migration

By default guest domain migration is disabled in the Xen configuration. A number of changes are necessary, therefore, prior to performing migrations. The required settings are located in the /etc/xen/xend-config.sxp configuration file and need to be implemented on both the source and target host systems. The first modification involves setting the xend_relocation_server value to yes:

(xend-relocation-server yes)

Secondly, the xend-relocation-hosts-allow value must be changed to define the hosts from which relocation requests will be accepted. This can be a list of hostnames or IP addresses including wildcards. An empty value may also be specified to accept connections from any host:

(xend-relocation-hosts-allow '')

Finally, the xend-relocation-address and xend-relocation-port settings on the source and destination systems must match. Leaving these values commented out with '#' characters so that the default value is used is also a viable option as shown below:

#(xend-port            8000)
#(xend-relocation-port 8002)

A Xen Migration Tutorial

In the remainder of this chapter we will work through an example migration of a Xen domainU guest from one host to another.

Preparing the Xen Migration Environment

The first requirement for performing live migrations involves the creation of a Xen domainU guest to migrate. For the purposes of this tutorial, we will need a disk image based domainU guest environment installed in the /xen directory of a server. The steps required to create such a guest are outlined in detail in the chapter entitled Building a Xen Virtual Guest Filesystem on a Disk Image (Cloning Host System). Throughout this tutorial we will also work on the assumption that the source host has an IP address of 192.168.2.20 and the target host has an IP address of 192.168.2.21.

Once the domainU guest has been created the server needs to be configured to allow the /xen sub-directory on the source host to be mounted via NFS on the target host. On Linux systems this typically involves adding an entry to the /etc/exports file. As an example, the following entry enables the target host (IP addess 192.168.2.21) to mount the /xen file directory located on the source host (192.168.2.20) via NFS:

/xen    192.168.2.21(rw,no_root_squash,async)

Of particular importance in the above configuration is the no_root_squash which allows the target host to write to the /xen directory via NFS as super-user, a key requirement for performing the live migration. Once the /etc/exports file has been modified the change needs to be exported using the exportfs command:

exportfs -a