QA:Testcase Live Migration using libvirt/virsh

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Completely rework the page, add lot's of preparation steps, use modern test case format)
(Fix migration command, add some more tips)
Line 22: Line 22:
 
** Open a terminal, <code>su -</code>
 
** Open a terminal, <code>su -</code>
 
** <code>mkdir -p /root/.ssh && chmod 700 /root/.ssh</code>
 
** <code>mkdir -p /root/.ssh && chmod 700 /root/.ssh</code>
 +
** Make note of the guest IP here, since it is required for the migration step: <code>ifconfig -a</code>
  
 
== Create the VM to migrate ==
 
== Create the VM to migrate ==
Line 47: Line 48:
  
 
|actions=
 
|actions=
 +
 +
{{admon/tip | This example uses tunnelled migration | Tunnelled migration passes all traffic through libvirtd, so no extra firewall ports need to be opened. <br>It has a usability hurdle though: qemu+ssh URIs will only work if it can authenticate without user input.}}
  
 
# On the source host, prep the migration:
 
# On the source host, prep the migration:
Line 52: Line 55:
 
#* Log in to the guest graphical desktop. Open a terminal, start a simple loop like <code>dest-vm$ for i in `seq 1 10000`; do echo $i; sleep 1; done
 
#* Log in to the guest graphical desktop. Open a terminal, start a simple loop like <code>dest-vm$ for i in `seq 1 10000`; do echo $i; sleep 1; done
 
# The destination host VM should be started and have storage prepped as mentioned above.
 
# The destination host VM should be started and have storage prepped as mentioned above.
# On the source host, perform the migration: <code>source-host$ sudo virsh migrate --verbose --live --p2p --tunnelled test-day-vm-migrate
+
# Verify you can SSH to the storage host non-interactively as root: <code> su - </code>  , then <code> ssh root@$DEST-VM-IP</code> , then <code>exit</code>
 +
# On the source host, perform the migration: <code>source-host$ sudo virsh migrate --verbose --p2p --tunnelled --live test-day-vm-migrate qemu+ssh://$DEST-VM-IP/system</code>
 
# After migration completes, verify the migrated VM is running on the destination
 
# After migration completes, verify the migrated VM is running on the destination
 
#* <code>source-host$ virt-viewer --connect qemu:///system test-day-vm</code>
 
#* <code>source-host$ virt-viewer --connect qemu:///system test-day-vm</code>

Revision as of 13:43, 24 May 2013


Contents

Description

Live migrate a VM between 2 Fedora hosts, and verify it is running correctly on the new host. These test steps aim for the simplest setup possible, using just a single host and two VMs: one as the migration destination, and one VM to migrate.

Setup

If you've been following along with a test day, you should have an up to date Fedora VM available. This will be the host that we migrate the VM to.

Warning (medium size).png
The default network setup does not allow the migrated guest to maintain continuous network connectivity.
In real deployments you would want to use bridged networking, but it isn't required for these basic tests.

SSH key access

  • On the physical host, create an SSH key for root:
    • su -
    • ssh-keygen
  • Set up the SSH key as an authorized key for the destination host VM
    • sudo virsh start test-day-vm
    • virt-viewer --connect qemu:///system test-day-vm
    • Open a terminal, su -
    • mkdir -p /root/.ssh && chmod 700 /root/.ssh
    • Make note of the guest IP here, since it is required for the migration step: ifconfig -a

Create the VM to migrate

If you've been following the test day, you likely only have 1 VM created. Feel free to skip this step if you have multiple VMs available.

  • Clone the existing test day VM: sudo virt-clone -o test-day-vm -n test-day-vm-migrate --auto-clone
  • If your test day VM is using nested virt, you want to turn that off for the new VM since it can cause migration compatibility issues since we are migrating into a VM:
    • sudo virsh edit test-day-vm-migrate
    • Delete the entire <cpu> block
  • Edit the guest so that it has a smaller amount of memory. My destination had 4G, and the migrating VM had 2G. You can likely much smaller.
  • Start the VM, verify it works correctly.

Sharing storage

Inside the destination VM, setup shared storage using sshfs:

  • sudo virsh start test-day-vm && virt-viewer --connect qemu:///system test-day-vm
  • yum install sshfs
  • sshfs root@HOST-IP:/var/lib/libvirt/images /var/lib/libvirt/images
  • sudo setsebool -P virt_use_fusefs=1
  • Edit /etc/libvirt/qemu.conf, uncomment user=root and group=root, sudo service libvirtd restart
    • XXX: That part is likely a bug

How to test

Idea.png
This example uses tunnelled migration
Tunnelled migration passes all traffic through libvirtd, so no extra firewall ports need to be opened.
It has a usability hurdle though: qemu+ssh URIs will only work if it can authenticate without user input.
  1. On the source host, prep the migration:
    • source-host$ sudo virsh start test-day-vm-migrate< && virt-viewer --connect qemu:///system test-day-vm-migrate/code>
    • Log in to the guest graphical desktop. Open a terminal, start a simple loop like <code>dest-vm$ for i in `seq 1 10000`; do echo $i; sleep 1; done
  2. The destination host VM should be started and have storage prepped as mentioned above.
  3. Verify you can SSH to the storage host non-interactively as root: <code> su - , then ssh root@$DEST-VM-IP , then exit
  4. On the source host, perform the migration: source-host$ sudo virsh migrate --verbose --p2p --tunnelled --live test-day-vm-migrate qemu+ssh://$DEST-VM-IP/system
  5. After migration completes, verify the migrated VM is running on the destination
    • source-host$ virt-viewer --connect qemu:///system test-day-vm
    • dest-vm$ virt-viewer --connect qemu:///system test-day-vm-migrate
    • Verify the simple echo loop is still running, guest appears to be working okay.
  6. Stop the migrated VM:
    • dest-vm$ sudo virsh destroy test-day-vm-migrate
    • Verify that after destroying the VM, it no longer appears in dest-vm$ sudo virsh list --all . (that is because we didn't pass the --persistent option to 'virsh migrate')
  7. Verify that the VM is stopped on the original host: source-host$ sudo virsh list --all (the VM is still there because we didn't pass the --undefinesource option to 'virsh migrate')

Expected Results

All steps complete without error and the migrated VM behaves as expected.

  1. Step #1 completes without error
  2. The system boots into runlevel 5
  3. Program completes with exit code 0

Optional

If you have pre-existing VMs of other operating systems, please try migrating those as well.