From Fedora Project Wiki

(add save/restore test case from clalance)
 
(add {{autolang}})
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{autolang|base=yes}}
{{QA/Test_Case
{{QA/Test_Case
|description=This test case will verify that a F-11 guest can be saved and restored.
|description=This test case will verify that a rawhide guest can be saved and restored.
|actions=
|actions=
* To save and restore the guest, run:
# Save the rawhide domU using:<pre>$> virsh save rawhide /var/lib/xen/save/rawhide-save</pre>
<pre>
# Wait 20 to 30 seconds, then run <pre>$> virsh restore /var/lib/xen/save/rawhide-save</pre> to restore the guest
  $> xm save f11 /var/lib/xen/save/f11-save
# After the guest is restored, make sure it has the right memory size, the right number of processors, no softlockups, etc.
  $> sleep 20
# Run the previous step with varying memory sizes for the guest, notably around the 4GB boundary.
  $> xm restore /var/lib/xen/save/f11-save
# Copy [[File:Xen-domu-stress-save-restore.c]] into the guest, then compile it with <pre>$> gcc -O2 Xen-domu-stress-save-restore.c -o Xen-domu-stress-save-restore</pre>
</pre>
# Now run the resulting executable inside the guest <pre>$> ./xen-domu-stress-save-restore</pre>
* After the guest is restored, make sure it has the right memory size, the right number of processors, no softlockups, etc.
# While the test is running in the guest, run a few save/restore iterations in the dom0:<pre>$> for i in `seq 1 10` ; do virsh save rawhide /var/lib/xen/save/rawhide-save ; virsh restore /var/lib/xen/save/rawhide-save ; done</pre>
* Run the previous step with varying memory sizes for the guest, notably around the 4GB boundary.
# Similarly, put the guest under some load - e.g. a kernel compile or program that allocates and modifies large amounts of memory - and run many save/restore iterations.
* Copy [[File:Xen-domu-stress-save-restore.c|foo]] into the guest, compile and run with:
<pre>
$> gcc -O0 -Wall -g xen-domu-stress-save-restore.c -o xen-domu-stress-save-restore
$> ./xen-domu-stress-save-restore
</pre>
* While the test is running in the guest, run a few save/restore iterations in the dom0:
<pre>
$> for i in `seq 1 10` ; do xm save f11 /var/lib/xen/save/f11-save ; xm restore /var/lib/xen/save/f11-save ; done
</pre>
* Similarly, put the guest under some load - e.g. a kernel compile or program that allocates and modifies large amounts of memory - and run many save/restore iterations.
|results=
|results=
* The save/restores complete successfully with now oops, lockups or error messages.
# The save/restores complete successfully with no oops, lockups or error messages.
}}
}}
[[Category:Virtualization XenDomU Test Cases]]
[[Category:Virtualization XenDomU Test Cases|Save and restore]]

Latest revision as of 09:42, 13 April 2011

Description

This test case will verify that a rawhide guest can be saved and restored.


How to test

  1. Save the rawhide domU using:
    $> virsh save rawhide /var/lib/xen/save/rawhide-save
  2. Wait 20 to 30 seconds, then run
    $> virsh restore /var/lib/xen/save/rawhide-save
    to restore the guest
  3. After the guest is restored, make sure it has the right memory size, the right number of processors, no softlockups, etc.
  4. Run the previous step with varying memory sizes for the guest, notably around the 4GB boundary.
  5. Copy File:Xen-domu-stress-save-restore.c into the guest, then compile it with
    $> gcc -O2 Xen-domu-stress-save-restore.c -o Xen-domu-stress-save-restore
  6. Now run the resulting executable inside the guest
    $> ./xen-domu-stress-save-restore
  7. While the test is running in the guest, run a few save/restore iterations in the dom0:
    $> for i in `seq 1 10` ; do virsh save rawhide /var/lib/xen/save/rawhide-save ; virsh restore /var/lib/xen/save/rawhide-save ; done
  8. Similarly, put the guest under some load - e.g. a kernel compile or program that allocates and modifies large amounts of memory - and run many save/restore iterations.

Expected Results

  1. The save/restores complete successfully with no oops, lockups or error messages.