Migration is the transferal of a running virtual domain from one physical host to another. Red Hat Virtualization supports two varieties of migration — offline and live. Offline migration moves a virtual machine from one host to another by pausing it, transferring its memory, and then resuming it on the host destination. Live migration does the same thing, but does not directly affect the domain. When performing a live migration, the domain continues its usual activities, and from the user perspective is unnoticeable. To initiate a live migration, both hosts must be running Red Hat Virtualization and the xend daemon. The destinations host must have sufficient resources (such as memory capacity) to accommodate the domain bandwidth after the migration. Both the source and destination machines must have the same architecture and virtualization extensions (such as i386-VT, x86-64-VT, x86-64-SVM, etc.) and must be on the same L2 subnet.
When a domain migrates its MAC and IP addresses move with it. Only virtual machines with the same layer-2 network and subnets will successfully migrate. If the destination node is on a different subnet, the administrator must manually configure a suitable EtherIP or IP tunnel in the remote node of domain0. The xend daemon stops the domain and copies the job over to the new node and restarts it. The Red Hat Virtualization RPM does not enable migration from any other host except the localhost (see the /etc/xend-config.sxp file for information). To allow the migration target to accept incoming migration requests from remote hosts, you must modify the target’s xen-relocation-hosts-allow parameter. Be sure to carefully restrict which hosts are allowed to migrate, since there is no authentication.
Since these domains have such large file allocations, this process can be time consuming. If you migrate a domain with open network connections, they will be preserved on the host destination, and SSH connections should still function. The default Red Hat Virtualization iptables rules will not permit incoming migration connections. To allow this, you must create explicit iptables rules.
You can use the xm migrate command to perform an offline migration :
xm migrate domain-id [destination domain]
You can use the xm migrate command to perform a live migration:
xm migrate domain-id -l [destination domain]
You may need to reconnect to the domain’s console on the new machine. You can use the xm console command to reconnect
You can copy (or clone) an existing configuration file to create an all new guest. You must modify the name parameter of the guests’ configuration file. The new, unique name then appears in the hypervisor and is viewable by the management utilities. You must generate an all new UUID as well (using the
uuidgen(1) command). Then for the
vif entries you must define a unique MAC address for each guest (if you are copying a guest configuration from an existing guest, you can create a script to handle it). For the xen bridge information, if you move an existing guest configuration file to a new host, you must update the
xenbr entry to match your local networking configuration. For the Device entries, you must modify the entries in the
'disk=' section to point to the correct guest image.
You must also modify these system configuration settings on your guest. You must modify the HOSTNAME entry of the
/etc/sysconfig/network file to match the new guest’s hostname.
You must modify the HWADDR address of the
/etc/sysconfig/network-scripts/ifcfg-eth0 file to match the output from
ifconfig eth0 file and if you use static IP addresses, you must modify the IPADDR entry.
Red Hat Virtualization can generate a MAC address for each virtual machine at the time of creation. Since is a nearly unlimited amount of numbers on the same subnet, it is unlikely you could get the same MAC address. To work around this, you can also write a script to generate a MAC address. This example script contains the parameters to generate a MAC address:
#! /usr/bin/python # macgen.py script generates a MAC address for Xen guests # import random mac = [ 0x00, 0x16, 0x3e, random.randint(0x00, 0x7f), random.randint(0x00, 0xff), random.randint(0x00, 0xff) ] print ':'.join(map(lambda x: "%02x" % x, mac)) Generates e.g.: 00:16:3e:66:f5:77 to stdout
Red Hat Virtualization can migrate virtual machines between other servers running Red Hat Enterprise Linux 5.0 with Virtualization. Further, migration is performed in an offline method (using the
xm migrate command). Live migration can be done from the same command. However there are some additional modifications that you must do to the
xend-config configuration file. This example identifies the entries that you must modify to ensure a successful migration:
The default for this parameter is ‘no’, which keeps the relocation/migration server deactivated (unless on a trusted network) and the domain virtual memory is exchanged in raw form without encryption.
This parameter sets the port that
xenduses for migration. This value is correct, just make sure to remove the comment that comes before it.
This parameter is the address that listens for relocation socket connections, after you enable the
xend-relocation-server. When listening, it restricts the migration to a particular interface.
This parameter controls the host that communicates with the relocation port. If the value is empty, then all incoming connections are allowed. You must change this to a space-separated sequences of regular expressions (such as
xend-relocation-hosts-allow- '^localhost\\.localdomain$'). A host with a fully qualified domain name or IP address that matches these expressions are accepted.
After you configure these parameters, you must reboot the host for the Red Hat Virtualization to accept your new parameters.