I tried to reproduce this on my system, but I see the following error:

CIM_ERR_FAILED: ResourceSettings Error: No NetworkPool specified and no default available ERROR - Exception: DefineSystem() failed to create domain: test_domain InvokeMethod(DefineSystem): CIM_ERR_FAILED: ResourceSettings Error: No NetworkPool specified and no default available

This is odd, because I have a network pool defined:

Name State Autostart ----------------------------------------- default-net active no

The provider complains with the following:

Virt_VirtualSystemManagementService.c(298): Failed to get default network pool: No default pool found for type 10 Virt_VirtualSystemManagementService.c(573): rasd_to_vdev(KVM_NetResourceAllocationSettingData): No NetworkPool specified and no default available Virt_VirtualSystemManagementService.c(886): Failed to classify resources: No NetworkPool specified and no default available std_invokemethod.c(305): Method `DefineSystem' returned 1

My issue appears to be caused by a different test suite - it's inadvertently deleting the network pool. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com

Dan Smith wrote:

DK> ComputerSystem - 40_RSC_start.py: XFAIL Bug: 00001 DK> ERROR - Exception: (1, u'CIM_ERR_FAILED: Invalid state transition') DK> ERROR - Exception: RequestedStateChange() could not be used to start domain: 'test_domain' DK> InvokeMethod(RequestStateChange): CIM_ERR_FAILED: Invalid state transition DK> Bug:<00001>

What is this? Certainly RequestStateChange() is not broken on KVM, right? And if it is, it definitely shouldn't be an XFAIL.

The above tc *On Xen* : the test case passes *On KVM* : the test case XFAIL's with below reason. ComputerSystem - 40_RSC_start.py: XFAIL Bug: 00001 ERROR - Exception: (1, u'CIM_ERR_FAILED: Domain Operation Failed') ERROR - Exception: RequestedStateChange() could not be used to start domain: '40_test_domain' InvokeMethod(RequestStateChange): CIM_ERR_FAILED: Domain Operation Failed Bug:<00001> The XML from the debug statement is as follows: <domain type='kvm'> <uuid>a01c02b7-c8a0-4a49-9c90-0a35e19865da</uuid> <name>40_test_domain</name> <on_poweroff>destroy</on_poweroff> <on_crash>destroy</on_crash> <os> <type>hvm</type> <boot dev='hd'/> </os> <currentMemory>0</currentMemory> <memory>0</memory> <vcpu>1</vcpu> <devices> <interface type='network'> <mac address='11:22:33:aa:bb:cc'/> <source network='default-net55'/> </interface> <disk type='file' device='disk'> <source file='/tmp/default-kvm-dimage'/> <target dev='hda'/> </disk> <graphics type='vnc' port='-1'/> </devices> </domain> 1) The XML config file is *just enough* to *define *the guest but not start it. I manually tried to define the guest with the above XML and I was able to define it, but when I tried to start the defined guest it failed with the following error: *virsh start 40_test_domain* libvir: QEMU error : internal error QEMU quit during console startup error: Failed to start domain 40_test_domain The only problem with the above XML file is the *Memory and currentMemory *being set to* 0. *I then assigned *1024* in place of *0* for *Memory and currentMemory *and I was able to define and start the domain. I was able to start the domain only when both the values *Memory and currentMemory *were not equal to *0*. The *Memory and currentMemory *being 0 is not a problem in case of Xen and XenFV. I tried checking the difference and the limitation for this field on libvirt.org, but was not much successful. 2) I found one more peculiar problem, even though I was able to successfully define KVM domain either using tc or manually, or started the KVM guest using the virsh, I was not find any info using the virsh -c qemu:///system list --all. Can this be a problem with my machine ? I was able to use virsh for other guests though. *On XenFV* : the test case fails with following error. ComputerSystem - 40_RSC_start.py: XFAIL Bug: 00002 ERROR - EnabledState should be 2 not 0 ERROR - Exception: Attributes were not set as expected for domain: 'test_domain' Bug:<00002> I tried inserting delay in the test case between the call_request_state_change() and check_attributes(), and the test case Passed :). PS : The machine had the following network pool *virsh net-list Name State Autostart ----------------------------------------- default-net active no * Thanks and Regards, Deepti.

------------------------------------------------------------------------

_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim

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.

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@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim