FedoraProject - Changes related to "Test Day:2011-04-14 Virtualization" [en]

QA:Testcase Live Migration using libvirt/virsh

2013-05-25T23:03:36Z

Add link to bug with storage migration

Releases/Branched

2013-05-18T20:24:53Z

‎Questions and Answers: recommend mock over rpmbuild

Releases/Branched

2013-05-18T20:18:16Z

Note the empty updates repo available for convenience

Releases/Branched

2013-05-18T19:41:38Z

replace old horrible page with a new shiny one.

Show changes

@@ Line 1: / Line 1: @@
-{{autolang|base=yes}}
 {{QA/Test_Case
-|description=This test case checks that basic live migration using libvirt between two Fedora hosts works correctly.
+|description=
 |actions=
-# On the source machine, edit the guest so that it has some small amount of memory (say, 768MB).
-# On the source machine, start the guest.
+{{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.}}
-# 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>
-# Now on the source machine execute:<br><br><code>$ virsh migrate --live <guestname> qemu+ssh://<destination host>/system</code><br><br>
+# On the source host, prep the migration:
-# 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.
+#* <code>source-host$ sudo virsh start test-day-vm-migrate< && virt-viewer --connect qemu:///system test-day-vm-migrate</code>
-# Repeat the entire test for as many different guest OS's as are relevant.  We would at least like to see the following guests:
+#* 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</code>
-## Fedora 16
+# The destination host VM should be started and have storage prepped as mentioned above.
-## Fedora 15
+# 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>
-## RHEL-5
+# 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>
-## RHEL-6
+# After migration completes, verify the migrated VM is running on the destination
-## Windows XP
+#* <code>source-host$ virt-viewer --connect qemu:///system test-day-vm</code>
-## Windows Vista
+#* <code>dest-vm$ virt-viewer --connect qemu:///system test-day-vm-migrate</code>
-## SUSE
+#* Verify the simple echo loop is still running, guest appears to be working okay.
 |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.
+All steps complete without error and the migrated VM behaves as expected.
 }}
-[[Category:Virtualization Live Migration]]

@@ Line 138: / Line 138: @@
 A: No. Mixing releases like this is a very bad idea. Your better options are:
-* Obtain the src.rpm for the package you wish and try and rpmbuild --rebuild it (which may or may not work depending on dependencies)
+* Obtain the src.rpm for the package you wish and try and "mock rebuild" it (which may or may not work depending on dependencies)
 * Ask the Fedora maintainer in a bug report to update the stable version if permitted by policy.

@@ Line 108: / Line 108: @@
 Branched goes through several phases:
-The Branched compose runs every day starting at 09:15UTC. All branched builds at that time that are stable are composed and sycned out. Note that during freezes there will be many days where 0 packages are added to the compose. Branched is under "development/VERSION" on the mirrors. You can find a local "VERSION" mirror [http://mirrors.fedoraproject.org/publiclist/Fedora/VERSION/ on the public mirror list]. Compose time varies depending on number of changes but is typically between 5 and 8 hours.
+The Branched compose runs every day starting at 09:15UTC. All branched builds at that time that are stable are composed and sycned out. Note that during freezes there will be many days where 0 packages are added to the compose. Branched is under "development/VERSION" on the mirrors. You can find a local "{{FedoraVersionNumber|next}}" mirror [http://mirrors.fedoraproject.org/publiclist/Fedora/{{FedoraVersionNumber|next}}/ on the public mirror list]. Compose time varies depending on number of changes but is typically between 5 and 8 hours.
 Right after branching off from rawhide, but before alpha change freeze, Branched is much like Rawhide. All packages built the previous day are composed and synced out. Bodhi is not used yet.
-At alpha change freeze, Bodhi (the Fedora updates system) is enabled. All builds must now use it. Builds are pushed to updates-testing repository and after meeting critera for stable are added to the base package repository, which is still composed once a day. During the Alpha change freeze, only updates that fix accepted blocker bugs or freeze exceptions are allowed to go stable.
+At alpha change freeze, Bodhi (the Fedora updates system) is enabled. All builds must now use it. Builds are pushed to updates-testing repository and after meeting critera for stable are added to the base package repository, which is still composed once a day. During the Alpha change freeze, only updates that fix accepted blocker bugs or freeze exceptions are allowed to go stable. There is also an empty updates repository, so that you can leave stable updates configured during the branch period and not have to change this after the release.
 As soon as Alpha is set to "go", the Alpha change freeze is lifted and packages can once again go to the base repository when marked stable.
@@ Line 126: / Line 126: @@
 Package maintainers should read and follow the [[Updates_Policy#Branched_release|Branched release updates policy]] for building any packages in Branched.
 Branched packages are not 100% signed until the Alpha Change freeze milestone.
 == Questions and Answers ==