[Libvirt-cim] CimTest Report for KVM on F9 23-07-2008

[Dan Smith]

DK> Yes, the test case is passing the RASD values which is inturn used
DK> for generating the XML configuration of the domain.  According to
DK> my analysis, to create a KVM guest we need atleast 1024 memory
DK> units.  Currently the test library vsms.py which is responsible
DK> for creating MemRASD values is passing only VirtualQuantity=512.

Aiee.  The libvirt XML specifies memory in kilobytes, which means 512
rounds to zero.  The fact that you can create a Xen guest is probably
just because of a lack of verification.  The QEMU command line takes
memory in megabytes, so anything less than that isn't really valid.

This was changed (fixed) in my recent patch to make the providers
honor AllocationUnits in the MemRASD on DefineSystem().

DK> This value is *not sufficient* for creating a *KVM* guest, but is
DK> *just enough* for *Xen, XenFV* guests.

Perhaps just enough to create the guest, but not start it.  Not even
MS-DOS can run in 512 bytes of memory...

DK> Also, AllocationUnits is one of the important field of MemRASD
DK> that determines the Memory and CurrentMemory fields in the XML
DK> configuration.

Indeed, which is why I wrote the (still unreviewed) test for
AllocationUnits last week.

DK> 1) As an extention to the 40_RSC_start.py tc we can actually pass
DK> different combination of VirtualQuantity and AllocationUnits to test
DK> the mem_rasd_to_vdev code path.

My test exercises all of the AllocationUnits paths.  40_RSC_start
isn't the proper place for that, IMHO.

I think you should change the default VirtualQuantity to 32, and the
AllocationUnits to "MegaBytes" for this case.

Thanks!

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvirt-cim/attachments/20080729/fb34da05/attachment.sig>