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@us.ibm.com