From Fedora Project Wiki

No edit summary
(add {{autolang}})
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{autolang|base=yes}}
{{QA/Test_Case
{{QA/Test_Case
|description=This test case checks that worst-case live migration using libvirt between two Fedora 12 hosts works correctly.  The worst-case for live migration happens when the guest in question is very busy and changing memory very rapidly, which causes the same pages to be transmitted multiple times to the destination.
|description=This test case checks that live migration properly cleans up after itself if the migration were to fail for any reason.  There are three stages to live migration:
# Prepare runs on the destination machine, and sets up the incoming qemu process for migration
# Perform runs on the source machine, and actually migrates the guest
# Finish runs on the destination machine, and cleans up after the migration is complete (or has failed).
 
If Prepare fails, the qemu process on the destination machine should be destroyed, and nothing further should be done.  If Perform fails, then it should return a negative error code, which will be passed to Finish, which should clean up the qemu on the destination machine.  Only if both Prepare and Perform succeeds should Finish start the VM on the destination machine and destroy the VM on the source machine.
|actions=
|actions=
# On the source machine, edit the guest so that it has a fairly large amount of memory (at least 2GB, more if you can spare it).
# On the source machine, start the guest.
# On the source machine, start the guest.
# Once the guest has fully booted, find out the IP address of the guest (by logging into the guest and running ifconfig, or whatever is equivalent in the guest OS of your choice).  From the source machine, start a ping to the guest:<br><br><code>$ ping <guest-IP></code><br><br>
# Once the guest has fully booted, find out the IP address of the guest (by logging into the guest and running ifconfig, or whatever is equivalent in the guest OS of your choice).  From the source machine, start a ping to the guest:<br><br><code>$ ping <guest-IP></code><br><br>
# Download this code to the guest: [[File:live-migration-memeater.c]] and compile it using<br><br><code>$ gcc -g -Wall live-migration-memeater.c -o live-migration-memeater</code><br><br>
# Now on the source machine execute:<br><br><code>$ virsh migrate --live <guestname> qemu+ssh://<destination host>/system foo://bar</code><br><br>
# Start the memchanger inside the guest by executing:<br><br><code>$ ./live-migration-memeater</code><br><br>
# Now on the destination machine execute: <br><br><code># iptables -A INPUT -m multiport --dports 49152:49216 -j DROP</code><br><br>
# Now on the source machine execute:<br><br><code>$ virsh migrate --live <guestname> qemu+ssh://<destination host>/system<br><br>
# Now on the source machine execute:<br><br><code>$ virsh migrate --live <guestname> qemu+ssh://<destination host>/system</code><br><br>
# Shutdown the guest on the destination machine.  Once it's successfully shut down, edit the guest on the source machine and give it random, differing amounts of memory: 1024MB, 2111MB, etc.  Then repeat the test for these differing amounts of memory.
# Repeat the entire test for as many different guest OS's as are relevant.  We would at least like to see the following guests:
## Fedora 12
## Fedora 11
## RHEL-4
## RHEL-5
## SUSE
|results=
|results=
# After executing the virsh migrate command, the guest should migrate over to the destination machine, and not be running anymore on the source machine. Use <code>virsh list</code> on both machines to verify this.  Additionally, the ping that was started in step 3 should continue uninterrupted.  Note that this migration may take significantly longer than a migration of an idle guest.
# After executing the virsh migrate command with the last parameter of foo://bar, the prepare step should fail, the migration should fail, and the guest should still be running on the source machine.
# After executing the virsh migrate command in step 5, the perform step of migration should fail, and the guest should still be running on the source machine.
}}
}}
[[Category:Virtualization Live Migration]]
[[Category:Virtualization Live Migration]]

Latest revision as of 09:12, 13 April 2011


Description

This test case checks that live migration properly cleans up after itself if the migration were to fail for any reason. There are three stages to live migration:

  1. Prepare runs on the destination machine, and sets up the incoming qemu process for migration
  2. Perform runs on the source machine, and actually migrates the guest
  3. Finish runs on the destination machine, and cleans up after the migration is complete (or has failed).

If Prepare fails, the qemu process on the destination machine should be destroyed, and nothing further should be done. If Perform fails, then it should return a negative error code, which will be passed to Finish, which should clean up the qemu on the destination machine. Only if both Prepare and Perform succeeds should Finish start the VM on the destination machine and destroy the VM on the source machine.


How to test

  1. On the source machine, start the guest.
  2. Once the guest has fully booted, find out the IP address of the guest (by logging into the guest and running ifconfig, or whatever is equivalent in the guest OS of your choice). From the source machine, start a ping to the guest:

    $ ping <guest-IP>

  3. Now on the source machine execute:

    $ virsh migrate --live <guestname> qemu+ssh://<destination host>/system foo://bar

  4. Now on the destination machine execute:

    # iptables -A INPUT -m multiport --dports 49152:49216 -j DROP

  5. Now on the source machine execute:

    $ virsh migrate --live <guestname> qemu+ssh://<destination host>/system

Expected Results

  1. After executing the virsh migrate command with the last parameter of foo://bar, the prepare step should fail, the migration should fail, and the guest should still be running on the source machine.
  2. After executing the virsh migrate command in step 5, the perform step of migration should fail, and the guest should still be running on the source machine.
Retrieved from "https://fedoraproject.org/w/index.php?title=QA:Testcase_Migration_failure_cleans_up_properly&oldid=231762"