Appendix B. Lab 2
Live Migration
Goal: To configure and perform a live migration between two hosts.
Prerequisite: Two workstations installed with Red Hat Enterprise Linux 5.0 Beta 2 with Virtualization Platform, and a Fedora Core 6 Xen guest on one of the two workstations.
For this lab, you will configure the migration and execute a live migration between two hosts.
Introduction: Before you begin
For this lab, you will need two Virtualization hosts: a Xen guest and a shared storage. You must connect the two Virtualization hosts via a UTP cable. One of the Virtualization hosts exports a shared storage via NFS. You must configure both of the Virtualization hosts so they migrate successfully. The Xen guest resides on the shared storage. On the Xen guest, you should install a streaming server. You must make sure that the streaming server still runs without any interruptions on the Xen guest, so the live migration takes place between one Virtualization host and the other. For Lab 2, you will refer the two Virtualization hosts as host1 and host2 .
Sequence 1: Configuring xend (both Xen hosts)
In this Lab procedure, you configure xend to start up as a HTTP server and a relocation server. The xend daemon does not initiate the HTTP server by default. It starts the UNIX domain socket management server (for xm) and communicates with xend. To enable cross-machine live migration, you must configure it to support live migration:
To make a backup of your xend-config.sxp file:
cp -pr /etc/xen/xend-config.sxp /etc/xen/xend-config.sxp.default
Edit /etc/xen/xend-config.sxp and make the following changes:
#(xend-unix-server yes)(xend-relocation-server
yes)(xend-relocation-port 8002)(xend-relocation-address
'')(xend-relocation-hosts-allow '')#(xend-relocation-hosts-allow '^localhost$
^localhost\\.localdomain$')
Restart xend:service and xend restart.
Sequence 2: Exporting a shared storage via NFS
For this lab procedure, you will configure NFS and use it to export a shared storage.
Edit /etc/exports and include the line: /xen *(rw,sync,no_root_squash)/
Save /etc/exports and restart the NFS server. Make sure that the NFS server starts by default:service nfs startchkconfig nfs on.
After starting the NFS server on host1, we can then mount it on host2:mount host1:/xen .
Now start the Xen guest on host1 and select fc6-pv1 (or fc6-pv2 from Lab 1):
xm create -c fc6-pv1
Sequence 3: Installing the Xen guest streaming server
For this lab step, you will install a streaming server, gnump3d, for our demonstration purposes. You will select gnump3d because it supports OGG vorbis files and is easy to install, configure, and modify.
Download gnump3d-2.9.9.9.tar.bz2 tarball from http://www.gnump3d.org/ . Unpack the tarball and in the gnump3d-2.9.9.9/ directory, compile, and install the gnump3d application:tar xvjf gnump3d-2.9.9.9.tar.bz2cd gnump3d-2.9.9.9/make install
Create a /home/mp3 directory and copy TruthHappens.ogg from Red Hat's Truth Happens page to mkdir /home/mp3wget -c http://www.redhat.com/v/ogg/TruthHappens.ogg
Start the streaming server by typing
command:gnump3d
On either one of the two Xen hosts, start running the Movie Player. If it is not installed, then install the totem and iso-codecs rpms before running the Movie Player. Click Applications, then Sound & Video, and finally Movie Player.
Click Movie, then Open Location. Enter http://guest:8888/TruthHappens.ogg.
Sequence 4: Performing live migration
Run the TruthHappens.ogg file on one of the two Xen hosts.
Perform the live migration from host1 to host2:
xm migrate –live fc6-pv1 host2
Open multiple window terminals on both Xen hosts with the following command:
watch -n1 xm list
Observe as the live migration beginss. Note how long it takes for migration to complete.
Challenge Sequence: Configuring VNC server from within the Xen guest
If time permits, from within the Xen guest, configure the VNC server to initiate when gdm starts up. Run VNC viewer and connect to the Xen guest. Play with the Xen guest when the live migration occurs. Attempt to pause/resume, and save/restore the Xen guest and observe what happens to the VNC viewer. If you connect to the VNC viewer via localhost:590x, and do a live migration, you won't be able to connect to the VNC viewer again when it dies. This is a known bug.