Dan Smith wrote:
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.
Cool, I have not yet got a chance to review the patches.
I think you should change the default VirtualQuantity to 32, and the
AllocationUnits to "MegaBytes" for this case.
I will try using this. Thanks.
Regards,
Deepti.
Thanks!
------------------------------------------------------------------------
_______________________________________________
Libvirt-cim mailing list
Libvirt-cim(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-cim