Kaitlin Rupert wrote:
RASD - 01_verify_rasd_fields.py: FAIL The test case do not have any problem. I am seeing a peculiar behavior. The EnumerateInstance operation from the provider on the RASD is returning None value in the NetworkName field. I commented out the destroy and undefine part of the test case and checked if the wbemcli ein operation on RASD returned proper NetworkName value, which did. The rasd_from_vdev() function in Virt_RASD.c is indirectly called via enu_rasds -> _get_rasds(). The NetworkName value seem to be assigned properly when called from the VSSDC.c vssd_to_rasd() function. But when called from EnumInstances() in the Virt_RASD.c the NetworkName is getting reset to null.
Thanks Deepti for providing debug - this helped me track the issue down. The actual error is in the virt_device_dup() function in device_parsing.c I'll follow up with a patch to fix this.
Thats good :)
ResourceAllocationFromPool - 01_forward.py: FAIL Though the networkpool information is supplied with the Xen domain while creating it.. once created the xml will have the bridge information instead of pool. Because of the provider would not have the source networkpool information when queried, this test fails with the following error:
device_parsing.c(325): No network source defined, leaving blank Virt_DevicePool.c(444): Unable to determine pool since no network source defined
This is a consequence of how the libvirt Xen driver works. When the guest is defined, the XML is converted from a "network" type interface to a "bridge" type.
Yeah! you had told me about this previously as well. But how should we go about fixing these tests for Xen. I am yet to decide. -- Thanks and Regards, Deepti B. Kalakeri IBM Linux Technology Center deeptik@linux.vnet.ibm.com