In virtualized enterprises that can't afford for Linux stacks to go offline, Xen live migration mitigates downtime...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
by enabling virtual machines (VMs) to move among hosts without service disruption and provides a level of redundancy during failures.
While Xen live migration works on any open source Xen stack, Novell's SUSE Linux Enterprise Server (SLES) may be the best option for enterprise environments; other distributions have moved from Xen to Kernel- based Virtual Machine (KVM) virtualization (although Novell supports KVM as well). In this article, you'll learn how to set up Xen live migration in an SLES environment and get an overview of the live migration software and hardware requirements.
Xen live migration hardware requirements
Xen live migration needs at least two VM hosts, which should have the same hardware and CPU specs to support every feature that your VMs require. You can have minor hardware differences; but to avoid surprises, it's best to use the same hardware for every host. You don't want to perform a migration only to find out that a VM needs a particular feature that isn't available on the new host.
The second Xen live migration hardware requirement is shared storage. Both hosts in a live migration write to the same VM image file when a VM is moved, so you need cluster-aware storage to avoid locking problems while accessing portions of the configuration.
Xen live migration software configuration
For Xen live migration, shared storage must be configured in two ways:
- VM disk images must reside on the shared storage. The easiest method is to create an OCFS2 file system and mount it where the VM disk image files are stored (e.g., /var/lib/xen/images on SLES).
- Make the shared storage available for the configuration files. If you use OCFS2 for disk image storage, you might as well create an OCFS2 file system and mount it on the directory where the VM configuration files are stored (e.g., /etc/xen/vm on SLES).
The OCFS2 volumes guarantee that the hosts have access to the VMs. After putting the OCFS2 volumes in place, just install the VMs normally, and the shared storage will automatically become available to all cluster nodes.
Finally, you must tell the xend process on all hosts involved that it should work as a migration host by editing the /etc/xen/xend-config.sxp file. Set the following parameters:
- (xend-relocation-server yes);
- (xend-relocation-port 8002); and
- (xend-relocation-hosts-allow ' ').
After changing the configuration file and re-starting the xend process on every VM, these VMs can live-migrate. First, use the xm list command to find the name of a VM. Then, enter xm migrate --live to live-migrate the machine to another host.
If a VM is named mailserver, for instance, and you want to migrate it to vmhost2, enter xm migrate --live mailserver vmhost2. Within a minute, it will run on the vmhost2.
Dig Deeper on Downtime and data loss in virtualized environments