Dan Smith wrote:
DK> 1) DK> The XML config file is *just enough* to *define *the guest but not DK> start it. DK> I manually tried to define the guest with the above XML and I was able DK> to define it, but when I tried to start the defined guest it failed DK> with the following error:
DK> *virsh start 40_test_domain* DK> libvir: QEMU error : internal error QEMU quit during console startup DK> error: Failed to start domain 40_test_domain
DK> The only problem with the above XML file is the *Memory and DK> currentMemory *being set to* 0.
That's a pretty big problem. Why is this marked as XFAIL? This should be failing, and needs to be fixed ASAP.
When I define a KVM guest through the providers manually, I get a correctly-set memory value. Is this an error in the test?
Yes, the test case is passing the RASD values which is inturn used for generating the XML configuration of the domain. According to my analysis, to create a KVM guest we need atleast 1024 memory units. Currently the test library vsms.py which is responsible for creating MemRASD values is passing only VirtualQuantity=512. This value is *not sufficient* for creating a *KVM* guest, but is *just enough* for *Xen, XenFV* guests. Also, AllocationUnits is one of the important field of MemRASD that determines the Memory and CurrentMemory fields in the XML configuration. The provider code that generates the Memory and CurrentMemory part of the XML configuration is given below. static const char *mem_rasd_to_vdev(CMPIInstance *inst, struct virt_device *dev) { const char *units; int shift; cu_get_u64_prop(inst, "VirtualQuantity", &dev->dev.mem.size); cu_get_u64_prop(inst, "Reservation", &dev->dev.mem.size); dev->dev.mem.maxsize = dev->dev.mem.size; cu_get_u64_prop(inst, "Limit", &dev->dev.mem.maxsize); if (cu_get_str_prop(inst, "AllocationUnits", &units) != CMPI_RC_OK) { CU_DEBUG("Memory RASD has no units, assuming bytes"); units = "Bytes"; } if (STREQC(units, "Bytes")) shift = -10; else if (STREQC(units, "KiloBytes")) shift = 0; else if (STREQC(units, "MegaBytes")) shift = 10; else if (STREQC(units, "GigaBytes")) shift = 20; else return "Unknown AllocationUnits in Memory RASD"; if (shift < 0) { dev->dev.mem.size >>= -shift; dev->dev.mem.maxsize >>= -shift; } else { dev->dev.mem.size <<= shift; dev->dev.mem.maxsize <<= shift; } return NULL; } Currently, the default value for the AllocationUnits is not being set by the vsms.py test library. Hence according to the above code the units that will be considered will be Bytes, when this happens the final value that is currently being assigned will be (dev->dev.mem.size >>= -shift, 512>>10) 0. As mentioned above this value is not at all sufficient for the successful KVM creation. This problem for KVM can be solved by setting the VirtualQuantity as 1024 and the AllocationUnits as "KiloBytes". After making these changes to the vsms.py , the tc 40_RSC_start.py passed on KVM and Xen. And for XenFV the test case passed with additional modification in the 40_RSC_start.py tc, which required polling for enabled state to be set properly after RequestedStateChange(). 1) As an extention to the 40_RSC_start.py tc we can actually pass different combination of VirtualQuantity and AllocationUnits to test the mem_rasd_to_vdev code path. 2) Also, can I update our libvirt wiki where we post our test results with tips like the necessary value for Memory and CurrentMemory value, if you think its valuable and if my analysis is accurate. Any suggestions ?? Thanks and Regards, Deepti.