No edit summary |
No edit summary |
||
(5 intermediate revisions by the same user not shown) | |||
Line 83: | Line 83: | ||
Did further testing, doing the "stress" test (steps 5 and 6). The test succeeded for the first few iterations, but then failed. Filed http://bugzilla.redhat.com/499598 | Did further testing, doing the "stress" test (steps 5 and 6). The test succeeded for the first few iterations, but then failed. Filed http://bugzilla.redhat.com/499598 | ||
== Pause/Unpause testing == | |||
=== 64-bit guest === | |||
No problems encountered. | |||
== CPU hotplug/hotunplug == | |||
=== 64-bit guest === | |||
Booted up the guest with 8 vCPUs. Was able to hot-unplug 6 of them, so I got down to a total of 2 vCPUs. Then, trying to hot-plug the 6, nothing happend. http://bugzilla.redhat.com/499611 filed. | |||
== Block attach/detach == | |||
=== 64-bit guest === | |||
Booted up the guest with only xvda attached. Attached xvdb with the virsh attach-disk command, success. Mounted the disk inside the guest, wrote some data, fine. Detached the disk from the guest, which says it succeeded, but actually failed; dom0 bug, filed as http://bugzilla.redhat.com/499616. Unmount the disk inside the guest, which succeeds, but stack trace, filed as http://bugzilla.redhat.com/499621. Trying to make an ext4 fs on the "huge", fake, 5TB disk resulted in a complete guest lockup, filed as http://bugzilla.redhat.com/499630. Attaching 70 disks to the guest worked. | |||
== Static binaries == | |||
=== 64-bit guest === | |||
Ran the example test program without problems. Also ran f-spot without problems. | |||
== Execshield == | |||
=== 64-bit guest === | |||
Ran the example test programs without problems. | |||
== Kernel Command-line == | |||
=== 64-bit guest === | |||
Added the mem= parameter to the guest command-line. The guest properly started with only 1GB, although it didn't give back the spare memory to the HV, which would be nice. Bug file http://bugzilla.redhat.com/499644 | |||
== PVFB == | |||
=== 64-bit guest === | |||
PVFB works, as does the scroll wheel. | |||
== Kernel Crash == | |||
=== 64-bit guest === | |||
When trying to invoke a kernel crash via "echo c > /proc/sysrq-trigger", nothing happens. http://bugzilla.redhat.com/499648 filed. |
Latest revision as of 15:04, 7 May 2009
Notes from virtualization test day Test_Day:2009-05-07_Virtualization specifically for Test_Day:2009-05-07_Virtualization:XenDomU.
Xen DomU
Install
Worked for
- dom0 RHEL-5.3 with updated 5.4 test packages, 2.6.18-141.el5xen #1 SMP Wed May 6 03:54:02 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
- Quad-Core AMD Opteron(tm) Processor 2350
- fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc pni monitor cx16 lahf_lm cmp_legacy svm cr8_legacy
Memory Ballooning
64 bit guest
Original guest was 768M. Test was:
virsh shutdown f11 virsh dumpxml f11 > f11.xml
- Add currentMemory parameter which defines minimum memory given to guest at boot.
<memory>1048576</memory> <currentMemory>524288</currentMemory>
- Enact this guest config in Xen via libvirt.
virsh define f11.xml virsh start f11
See: QA_talk:Testcase_Virtualization_XenDomU_Memory_Ballooning
Balloon Up - fail?
[root@felix tmp]# grep -i memory f11.xml <memory>1048576</memory> <currentMemory>524288</currentMemory> # guest is running... [root@felix xen]# virsh setmem f11 $(( 1024 * 1000 )) [root@felix tmp]# grep 'memory target' /var/log/xen/xend.log |tail -1 [2009-05-06 23:24:23 28390] DEBUG (XendDomainInfo:664) Setting memory target of domain f11 (7) to 1000 MiB. [root@felix xen]# virsh dominfo f11 | grep memory Max memory: 1048576 kB Used memory: 524288 kB
After few minutes guest free -m
still reports 519.
Bug filed as http://bugzilla.redhat.com/499587
Balloon Down - PASS
[root@felix tmp]# virsh setmem f11 $(( 1024 * 256 )) [root@felix tmp]# grep 'memory target' /var/log/xen/xend.log |tail -1 [2009-05-06 23:36:08 28390] DEBUG (XendDomainInfo:664) Setting memory target of domain f11 (7) to 256 MiB. [root@felix tmp]# virsh dominfo f11|grep memory Max memory: 1048576 kB Used memory: 262144 kB
Guest free -m
reports 256.
Balloon Back Up - PASS
Apparently I'm mistaken in my understanding of <memory>
and <currentMemory>
tags.
I was not able to balloon above 519.
[root@felix tmp]# virsh setmem f11 $(( 1024 * 1000 )) [root@felix tmp]# grep 'memory target' /var/log/xen/xend.log |tail -1 [2009-05-06 23:40:04 28390] DEBUG (XendDomainInfo:664) Setting memory target of domain f11 (7) to 1000 MiB. [root@felix tmp]# virsh dominfo f11|grep memory Max memory: 1048576 kB Used memory: 524288 kB
Guest free -m
reports 519 again.
Save/Restore testing
64-bit guest
Guest originally had 768MB of memory. I followed the test instructions, and did a "virsh save" followed by a "virsh restore" on the guest, which was successful. Owing to bug 499587, shut down the guest, and tried to give it 4096MB of memory. Failed to boot. After some testing, any number > 2047MB would cause the boot to fail. http://bugzilla.redhat.com/499592 filed to track that. Successfully did a save/restore with 2047MB of memory.
Did further testing, doing the "stress" test (steps 5 and 6). The test succeeded for the first few iterations, but then failed. Filed http://bugzilla.redhat.com/499598
Pause/Unpause testing
64-bit guest
No problems encountered.
CPU hotplug/hotunplug
64-bit guest
Booted up the guest with 8 vCPUs. Was able to hot-unplug 6 of them, so I got down to a total of 2 vCPUs. Then, trying to hot-plug the 6, nothing happend. http://bugzilla.redhat.com/499611 filed.
Block attach/detach
64-bit guest
Booted up the guest with only xvda attached. Attached xvdb with the virsh attach-disk command, success. Mounted the disk inside the guest, wrote some data, fine. Detached the disk from the guest, which says it succeeded, but actually failed; dom0 bug, filed as http://bugzilla.redhat.com/499616. Unmount the disk inside the guest, which succeeds, but stack trace, filed as http://bugzilla.redhat.com/499621. Trying to make an ext4 fs on the "huge", fake, 5TB disk resulted in a complete guest lockup, filed as http://bugzilla.redhat.com/499630. Attaching 70 disks to the guest worked.
Static binaries
64-bit guest
Ran the example test program without problems. Also ran f-spot without problems.
Execshield
64-bit guest
Ran the example test programs without problems.
Kernel Command-line
64-bit guest
Added the mem= parameter to the guest command-line. The guest properly started with only 1GB, although it didn't give back the spare memory to the HV, which would be nice. Bug file http://bugzilla.redhat.com/499644
PVFB
64-bit guest
PVFB works, as does the scroll wheel.
Kernel Crash
64-bit guest
When trying to invoke a kernel crash via "echo c > /proc/sysrq-trigger", nothing happens. http://bugzilla.redhat.com/499648 filed.