From Fedora Project Wiki
No edit summary
No edit summary
 
(7 intermediate revisions by the same user not shown)
Line 38: Line 38:


[root@felix tmp]# grep 'memory target' /var/log/xen/xend.log |tail -1
[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-32 (7) to 1000 MiB.
[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
[root@felix xen]# virsh dominfo f11 | grep memory
Line 46: Line 46:


After few minutes guest <code>free -m</code> still reports 519.
After few minutes guest <code>free -m</code> still reports 519.
Bug filed as http://bugzilla.redhat.com/499587


==== Balloon Down - PASS ====
==== Balloon Down - PASS ====
Line 52: Line 54:


[root@felix tmp]# grep 'memory target' /var/log/xen/xend.log |tail -1
[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-32 (7) to 256 MiB.
[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
[root@felix tmp]# virsh dominfo f11|grep memory
Line 68: Line 70:


[root@felix tmp]# grep 'memory target' /var/log/xen/xend.log |tail -1
[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-32 (7) to 1000 MiB.
[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
[root@felix tmp]# virsh dominfo f11|grep memory
Max memory:    1048576 kB
Max memory:    1048576 kB
Line 75: Line 77:


Guest <code>free -m</code> reports 519 again.
Guest <code>free -m</code> 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.

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.