Live Migration

The following prerequisites apply:

• Both the source machine and the target host must be on the same subnet.

• The host and the target must each have the same CPU type (AMD or Intel).

• Both systems must be running the same release of the xVM software.

• There must be sufficient CPU and memory resources on the target to host the domain.

• The target dom0 should have the same network interface as the source dom0 network interface used by the domU. For example, if the domU to be migrated has a VNIC that is bridged over the e1000g0 interface on the source dom0, then the target dom0 must also have the e1000g0 interface.

Enabling Live Migration on a Target Host

By default, xend listens only on the loopback address for requests from the localhost. The target host must be configured to accept the migration of a guest domain. The following example configures the xend SMF service on the target machine to accept guest migration from a system named host1. The caret (^) and dollar sign ($) are pattern-matching characters to ensure that the entire host name matches. The host1 name must match the name the target thinks the machine is called, which could be a host name, but could also be a fully qualified domain name (FQDN).

# svccfg -s svc:system/xvm/xend
svc:/system/xvm/xend> setprop config/xend-relocation-address = ""
svc:/system/xvm/xend> setprop config/xend-relocation-hosts-allow = "^host1\.?.*$ ^localhost$"
svc:/system/xvm/xend> end
# svcadm refresh svc:system/xvm/xend:default && \
svcadm restart svc:system/xvm/xend:default

You can test the connection by using:

host1# telnet target-host 8002

If connection fails, check the /var/log/xen/xend.log file on the target system.

Configuring the Guest Domain to Be Migrated

In addition to configuring the target system to accept migrations, you must also configure the domain that will be migrated so that the domain's storage is accessible from both the source and the target systems. The domain's accessible disks must reside on some form of shared storage, such as NFS files or iSCSI volumes. This document uses the NFS method available in the OpenSolaris 2009.06 release.

Prepare the NFS Storage on the NFS Server

On the NFS server, share the directory:

# sharectl set -p nfsmapid_domain=sun.com nfs
# svcadm restart svc:/network/nfs/mapid:default
# share -F nfs -o "sec=sys,root=host1:host2,rw" /vdisks

On both the host1 source system and the host2target system, also execute the sharectl to set the NFS mapid name to sun.com, and the svcadm command restart the xend service.

Create a PV Guest on the Source Machine (host1)

# virt-install -p --nographics -n domain -r 1024 -l /isos/os0906/os0906.iso -f /net/hostname_of_nfs_server/vdisks/testpv

The virt-install command then creates the virtual disk on the NFS server and starts the guest installation process.

iscsi Volume Method, Available in a Later Build

This method should be available in a build after the OpenSolaris 2009.06 release.

An iscsi-backed guest would be created with this base command:

# virt-install -n <name> -r <ram> -p --nographics -l /path/to/iso \
-m <mac address> \
--disk path=/static/<iscsi target ip address>/<lun>/<iqnnumber>,driver=phy,subdriver=iscsi 

An example would be:

# virt-install -n ubuntu -r 1024 -p --nographics -l /net/xvm-4200m2-03/isos/ubuntu-7.04-32.iso \ 
--disk path=/static/172.20.26.10/0/iqn.1986-03.com.sun:02:52ac879e-788e-e0ea-bf5c-f86b2b63258a,driver=phy,subdriver=iscsi

In addition to setting up the xend relocation host allow field as described above in the section "Enabling Live Migration on a Target Host,” also issue the following command to enable static discovery on both dom0s:

# iscsiadm modify discovery -s enable 

Migrating the Guest Domain

Use the following command to migrate the guest.

host1# virsh migrate domain --live xen:// xenmigr://target-host

While the use of the virsh command is preferred, you can try the following command if the virsh command appears to fail.

host1# xm migrate -l domain target-host

You can observe the migration while it occurs by monitoring the domain status on both machines using virsh list.

Note that the domain definition remains on the system on which it was created. You can start the domain on that system's dom0 with the virsh start domain command.