Configure migrations

Procedure 4.4. To configure your system

1. Configure your DNS or /etc/hosts and ensure it is consistent across all hosts. Make sure that the three hosts can perform name resolution with each other. As a test, use the ping command to ping each host from one another.

   $ ping HostA
   $ ping HostB
   $ ping HostC

2. Ensure that the UID and GID of your Compute and libvirt users are identical between each of your servers. This ensures that the permissions on the NFS mount works correctly.

3. Export NOVA-INST-DIR/instances from HostA, and have it readable and writable by the Compute user on HostB and HostC.

   For more information, see: SettingUpNFSHowTo or CentOS / Redhat: Setup NFS v4.0 File Server

4. Configure the NFS server at HostA by adding the following line to the /etc/exports file:

   NOVA-INST-DIR/instances HostA/255.255.0.0(rw,sync,fsid=0,no_root_squash)

   Change the subnet mask (255.255.0.0) to the appropriate value to include the IP addresses of HostB and HostC. Then restart the NFS server:

   # /etc/init.d/nfs-kernel-server restart
   # /etc/init.d/idmapd restart

5. Set the 'execute/search' bit on your shared directory.

   On both compute nodes, make sure to enable the 'execute/search' bit to allow qemu to be able to use the images within the directories. On all hosts, run the following command:

   $ chmod o+x NOVA-INST-DIR/instances 

6. Configure NFS at HostB and HostC by adding the following line to the /etc/fstab file:

   HostA:/ /NOVA-INST-DIR/instances nfs4 defaults 0 0

   Ensure that you can mount the exported directory can be mounted:

   $ mount -a -v

   Check that HostA can see the "NOVA-INST-DIR/instances/" directory:

   $ ls -ld NOVA-INST-DIR/instances/

   drwxr-xr-x 2 nova nova 4096 2012-05-19 14:34 nova-install-dir/instances/

   Perform the same check at HostB and HostC, paying special attention to the permissions (Compute should be able to write):

   $ ls -ld NOVA-INST-DIR/instances/

   drwxr-xr-x 2 nova nova 4096 2012-05-07 14:34 nova-install-dir/instances/

   $ df -k

   Filesystem           1K-blocks      Used Available Use% Mounted on
   /dev/sda1            921514972   4180880 870523828   1% /
   none                  16498340      1228  16497112   1% /dev
   none                  16502856         0  16502856   0% /dev/shm
   none                  16502856       368  16502488   1% /var/run
   none                  16502856         0  16502856   0% /var/lock
   none                  16502856         0  16502856   0% /lib/init/rw
   HostA:        921515008 101921792 772783104  12% /var/lib/nova/instances  ( <--- this line is important.)

7. Update the libvirt configurations so that the calls can be made securely. These methods enable remote access over TCP and are not documented here, please consult your network administrator for assistance in deciding how to configure access.

   • SSH tunnel to libvirtd's UNIX socket

   • libvirtd TCP socket, with GSSAPI/Kerberos for auth+data encryption

   • libvirtd TCP socket, with TLS for encryption and x509 client certs for authentication

   • libvirtd TCP socket, with TLS for encryption and Kerberos for authentication

   Restart libvirt. After you run the command, ensure that libvirt is successfully restarted:

   # stop libvirt-bin && start libvirt-bin
   $ ps -ef | grep libvirt

   root 1145 1 0 Nov27 ? 00:00:03 /usr/sbin/libvirtd -d -l

8. Configure your firewall to allow libvirt to communicate between nodes.

   By default, libvirt listens on TCP port 16509, and an ephemeral TCP range from 49152 to 49261 is used for the KVM communications. Based on the secure remote access TCP configuration you chose, be careful choosing what ports you open and understand who has access. For information about ports that are used with libvirt, see the libvirt documentation.

9. You can now configure options for live migration. In most cases, you do not need to configure any options. The following chart is for advanced usage only.

Procedure 4.5. To use shared storage live migration with XenServer hypervisors

1. Add an NFS VHD storage to your master XenServer, and set it as default SR. For more information, please refer to the NFS VHD section in the XenServer Administrator's Guide.

2. Configure all the compute nodes to use the default sr for pool operations. Add this line to your nova.conf configuration files across your compute nodes:

   sr_matching_filter=default-sr:true

3. Create a host aggregate:

   $ nova aggregate-create <name-for-pool> <availability-zone>

   The command displays a table that contains the ID of the newly created aggregate.

   Now add special metadata to the aggregate, to mark it as a hypervisor pool:

   $ nova aggregate-set-metadata <aggregate-id> hypervisor_pool=true

   $ nova aggregate-set-metadata <aggregate-id> operational_state=created

   Make the first compute node part of that aggregate:

   $ nova aggregate-add-host <aggregate-id> <name-of-master-compute>

   At this point, the host is part of a XenServer pool.

4. Add additional hosts to the pool:

   $ nova aggregate-add-host <aggregate-id> <compute-host-name>

   	Note
   	At this point, the added compute node and the host are shut down, to join the host to the XenServer pool. The operation fails, if any server other than the compute node is running/suspended on your host.