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

[Deepti B Kalakeri]

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.