[TEST] test cases fix list and assignment for the next week
Hi Zhengang and Deepti, I've list the failing test cases during our discussion yesterday. I've assigned and names listed as well, it's be great to shoot for completion before May 4th. =) Thanks! 1) CS.40 --- maybe provider issue -- Deepti InvokeMethod(DefineSystem): *** Provider Virt_VirtualSystemManagementService(27073) exiting due to a SIGSEGV signal 2) EAFP.01 & 02 ----- still in working --Daisy 3) ElementConfroms.02 & 04: -- Deepti 4) ElementSettingData.03 --- make sure clean the vs before running -- Zhengang 5) HostSystem.02 -- the difference of rpm and source provider in memory. "kilobyte" vs "megabyte", we have to add branch here -- Daisy 6) Memory 02 --- InvokeMethod(DefineSystem): *** Provider Virt_VirtualSystemManagementService(5492) --Daisy exiting due to a SIGSEGV signal 7) NetworkPort 03 ---- known bug 8) Processor 02 --- InvokeMethod(DefineSystem): *** Provider Virt_VirtualSystemManagementService(15585) exiting due to a SIGSEGV signal -- Deepti 9) RASD.01 & 02 --- "kilobyte" vs "megabyte", we have to add branch here --Zhengang 10) ReferenceProfile.01 & 02 --- also add branch --Deepti 11) ResourceAllocatedFromPool.01~04 --- rpm vs latest with different report message, we have to add branch here -- Daisy 12) ResourcePoolConfigurationService.03 04 06 07 -- CIM_ERR_NOT_SUPPORTED in rpm, we have to add message here -- Deepti 13) SettingsDefine 02 ---- Because of InstanceID, "Domain-0/0" vs "Domain-0/proc", Jay looked into this issue 14) VSSD.04 --- fail on rpm, pass on src, we have to add branch -- Daisy 15) VSMS.01 -- InvokeMethod(DefineSystem): -- Zhengang .02 -- destroy and undefine rpm: destroy branch "rpm" vs "latest" -- Zhengang .06 -- InvokeMethod(AddResourceSettings): CIM_ERR_FAILED: Failed to create domain -- Zhengang 16) VSSDataComponent.03 -- we have to add branch for "error code" -- Daisy Best, Regards Daisy Guo Lian Yun E-mail: yunguol@cn.ibm.com IBM China Development Lab, Shanghai, China TEL: (86)-21-61008057
Thanks Daisy for the list. Regards, Deepti. Guo Lian Yun wrote:
Hi Zhengang and Deepti,
I've list the failing test cases during our discussion yesterday.
I've assigned and names listed as well, it's be great to shoot for completion before May 4th. =)
Thanks!
1) CS.40 --- maybe provider issue -- Deepti InvokeMethod(DefineSystem): *** Provider Virt_VirtualSystemManagementService(27073) exiting due to a SIGSEGV signal
2) EAFP.01 & 02 ----- still in working --Daisy
3) ElementConfroms.02 & 04: -- Deepti
4) ElementSettingData.03 --- make sure clean the vs before running -- Zhengang
5) HostSystem.02 -- the difference of rpm and source provider in memory. "kilobyte" vs "megabyte", we have to add branch here -- Daisy
6) Memory 02 --- InvokeMethod(DefineSystem): *** Provider Virt_VirtualSystemManagementService(5492) --Daisy exiting due to a SIGSEGV signal
7) NetworkPort 03 ---- known bug
8) Processor 02 --- InvokeMethod(DefineSystem): *** Provider Virt_VirtualSystemManagementService(15585) exiting due to a SIGSEGV signal -- Deepti
9) RASD.01 & 02 --- "kilobyte" vs "megabyte", we have to add branch here --Zhengang
10) ReferenceProfile.01 & 02 --- also add branch --Deepti
11) ResourceAllocatedFromPool.01~04 --- rpm vs latest with different report message, we have to add branch here -- Daisy
12) ResourcePoolConfigurationService.03 04 06 07 -- CIM_ERR_NOT_SUPPORTED in rpm, we have to add message here -- Deepti
13) SettingsDefine 02 ---- Because of InstanceID, "Domain-0/0" vs "Domain-0/proc", Jay looked into this issue
14) VSSD.04 --- fail on rpm, pass on src, we have to add branch -- Daisy
15) VSMS.01 -- InvokeMethod(DefineSystem): -- Zhengang .02 -- destroy and undefine rpm: destroy branch "rpm" vs "latest" -- Zhengang .06 -- InvokeMethod(AddResourceSettings): CIM_ERR_FAILED: Failed to create domain -- Zhengang
16) VSSDataComponent.03 -- we have to add branch for "error code" -- Daisy
Best, Regards
Daisy Guo Lian Yun E-mail: yunguol@cn.ibm.com IBM China Development Lab, Shanghai, China TEL: (86)-21-61008057
------------------------------------------------------------------------
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
15) VSMS.01 -- InvokeMethod(DefineSystem): -- Zhengang .02 -- destroy and undefine rpm: destroy branch "rpm" vs "latest" -- Zhengang .06 -- InvokeMethod(AddResourceSettings): CIM_ERR_FAILED: Failed to create domain -- Zhengang The VSMS.06 failure seems to come from a missing <source> node in the network device section of the xml generated from the following code: src/Virt_VirtualSystemManagementService.c: _update_resources_for()
xml = system_to_xml(dominfo); if (xml != NULL) { CU_DEBUG("New XML:\n%s", xml); connect_and_create(xml, ref, &s); } else { cu_statusf(_BROKER, &s, CMPI_RC_ERR_FAILED, "Internal error (xml generation failed)"); } For the same domain, virsh & system_to_xml() gives different results on the network section. -------------virsh------------- <interface type='bridge'> <mac address='11:22:33:aa:bb:cc'/> *<source bridge='testbridge'/>* </interface> ------------system_to_xml()------ <interface type='bridge'> <mac address='11:22:33:aa:bb:cc'/> *<script path='vif-bridge'/>* </interface> The missing <source> node caused the virDomainDefineXML() failed in connect_and_create(). I'm not sure where this need to be fixed. The provider or the test case? -- - Zhengang
ZL> For the same domain, virsh & system_to_xml() gives different results ZL> on the network section. ZL> -------------virsh------------- ZL> <interface type='bridge'> ZL> <mac address='11:22:33:aa:bb:cc'/> ZL> *<source bridge='testbridge'/>* ZL> </interface> ZL> ------------system_to_xml()------ ZL> <interface type='bridge'> ZL> <mac address='11:22:33:aa:bb:cc'/> ZL> *<script path='vif-bridge'/>* ZL> </interface> I think what we really want is <source network="foo">. Is this KVM or Xen? And I assume this is a recent version of the providers? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
ZL> For the same domain, virsh & system_to_xml() gives different results ZL> on the network section. ZL> -------------virsh------------- ZL> <interface type='bridge'> ZL> <mac address='11:22:33:aa:bb:cc'/> ZL> *<source bridge='testbridge'/>* ZL> </interface> ZL> ------------system_to_xml()------ ZL> <interface type='bridge'> ZL> <mac address='11:22:33:aa:bb:cc'/> ZL> *<script path='vif-bridge'/>* ZL> </interface>
I think what we really want is <source network="foo">.
Is this KVM or Xen? And I assume this is a recent version of the providers? This is on latest KVM provider on F9, though I tested with a qemu-only system. But I saw same error message on Deepti's test report.
-- - Zhengang
Zhengang Li wrote:
Dan Smith wrote:
ZL> For the same domain, virsh & system_to_xml() gives different results ZL> on the network section. ZL> -------------virsh------------- ZL> <interface type='bridge'> ZL> <mac address='11:22:33:aa:bb:cc'/> ZL> *<source bridge='testbridge'/>* ZL> </interface> ZL> ------------system_to_xml()------ ZL> <interface type='bridge'> ZL> <mac address='11:22:33:aa:bb:cc'/> ZL> *<script path='vif-bridge'/>* ZL> </interface>
I think what we really want is <source network="foo">.
Is this KVM or Xen? And I assume this is a recent version of the providers? This is on latest KVM provider on F9, though I tested with a qemu-only system. But I saw same error message on Deepti's test report.
I think what Dan meant is that we should be using a network interface type for the cimtest guests. Dan - should the provider return an error if the guest doesn't use a network type interface? -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
KR> I think what Dan meant is that we should be using a network KR> interface type for the cimtest guests. Well, the providers should be creating <source network='something'>, so I need to check and make sure we're doing that. KR> Dan - should the provider return an error if the guest doesn't use KR> a network type interface? Meaning an existing guest created outside the providers with a network type we don't support? I dunno, I'll have to think on that one. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
KR> I think what Dan meant is that we should be using a network KR> interface type for the cimtest guests.
Well, the providers should be creating <source network='something'>, so I need to check and make sure we're doing that.
I checked whether the provider adds the <source network='something'> and it does for KVM. I tried creating the KVM guest with two interface types: 1) Network Type : It needs the following fields in the xml file: <interface type='network'> <mac address='11:22:33:aa:bb:cc'/> <source network='default-net'/> </interface> We are handling this in the provider code. 2) Bridge Type : It needs the following fields in the xml file: <interface type='bridge'> <mac address='11:22:33:aa:bb:cc'/> <source bridge='testbridge'/> </interface> The provider code in the xmlgen.c file does not support the KVM guest to be created with the "bridge" type. 1) Also, I noticed that for creating the Xen guest we do not require the <source > field in the <interface > section for both Network and Bridge interface Types. But for the KVM guest its compulsory to have the <source > field in the <interface > section for both Network and Bridge interface Types. 2) Any specific reason for not supporting the KVM guest to be created for the bridge type interface, and supporting Xen guest with only bridge type ? 3) Also, I did not understand the need for the script field in the interface section. We can create the Xen, KVM guests without this.
KR> Dan - should the provider return an error if the guest doesn't use KR> a network type interface?
Meaning an existing guest created outside the providers with a network type we don't support? I dunno, I'll have to think on that one.
------------------------------------------------------------------------
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
Thanks and Regards, Deepti.
Well, the providers should be creating <source network='something'>, so I need to check and make sure we're doing that.
I checked whether the provider adds the <source network='something'> and it does for KVM. I tried creating the KVM guest with two interface types:
1) Network Type :
It needs the following fields in the xml file: <interface type='network'> <mac address='11:22:33:aa:bb:cc'/> <source network='default-net'/> </interface>
We are handling this in the provider code.
2) Bridge Type : It needs the following fields in the xml file:
<interface type='bridge'> <mac address='11:22:33:aa:bb:cc'/> <source bridge='testbridge'/> </interface> The provider code in the xmlgen.c file does not support the KVM guest to be created with the "bridge" type.
Excellent find Deepti. Thanks for looking into this - I think this is an issue with the provider. You're correct - this is an issue in xmlgen.c What is happening here is the following: 1) Guest is created using virsh using network type bridge. 2) xen_net_to_xml() in xmlgen.c gets called instead of kvm_net_to_xml(). 3) Since xend is fine with using a bridge interface without the <source bridge=''/> tag defined, we don't specify one in the xmlgen code. QEMU borks when it attempts to create the guest with the new XML.
1) Also, I noticed that for creating the Xen guest we do not require the <source > field in the <interface > section for both Network and Bridge interface Types. But for the KVM guest its compulsory to have the <source > field in the <interface > section for both Network and Bridge interface Types. 2) Any specific reason for not supporting the KVM guest to be created for the bridge type interface, and supporting Xen guest with only bridge type ?
If you use the network interface type, the libvirt gets all the necessary network information from the virtual network. We don't have to worry about whether the bridge exists, etc.
3) Also, I did not understand the need for the script field in the interface section. We can create the Xen, KVM guests without this.
This is a good point. Actually, I thought there was some talk of having both Xen and KVM guests use the network interface, but I might be mistaken.
KR> Dan - should the provider return an error if the guest doesn't use KR> a network type interface?
Meaning an existing guest created outside the providers with a network type we don't support? I dunno, I'll have to think on that one.
Right - that's the issue here. We have a KVM guest with a bridge network type. The AddResource() call fails because it generates the new XML incorrectly. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
KR> This is a good point. Actually, I thought there was some talk of KR> having both Xen and KVM guests use the network interface, but I KR> might be mistaken. Yeah, and I think this is a good idea. There's no real benefit to supporting the bridge type during the creation of guests because it will only result in a lack of association to a pool. KR> Right - that's the issue here. We have a KVM guest with a bridge KR> network type. The AddResource() call fails because it generates KR> the new XML incorrectly. I guess what we need to do is make sure that device_parsing.c can parse a guest with a bridge type of interface and that xmlgen.c writes it back out correctly. Then, we won't break existing guests, but won't support creating them in that configuration from scratch. Does that sound reasonable? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
KR> This is a good point. Actually, I thought there was some talk of KR> having both Xen and KVM guests use the network interface, but I KR> might be mistaken.
Yeah, and I think this is a good idea. There's no real benefit to supporting the bridge type during the creation of guests because it will only result in a lack of association to a pool.
KR> Right - that's the issue here. We have a KVM guest with a bridge KR> network type. The AddResource() call fails because it generates KR> the new XML incorrectly.
I guess what we need to do is make sure that device_parsing.c can parse a guest with a bridge type of interface and that xmlgen.c writes it back out correctly. Then, we won't break existing guests, but won't support creating them in that configuration from scratch.
Does that sound reasonable?
It means we'd need to do the same with all the interface types (user, ethernet, etc). It's a lot of extra work, but it allows us to manage existing guests. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
Well, the providers should be creating <source network='something'>, so I need to check and make sure we're doing that.
I checked whether the provider adds the <source network='something'> and it does for KVM. I tried creating the KVM guest with two interface types:
1) Network Type :
It needs the following fields in the xml file: <interface type='network'> <mac address='11:22:33:aa:bb:cc'/> <source network='default-net'/> </interface>
We are handling this in the provider code.
2) Bridge Type : It needs the following fields in the xml file:
<interface type='bridge'> <mac address='11:22:33:aa:bb:cc'/> <source bridge='testbridge'/> </interface> The provider code in the xmlgen.c file does not support the KVM guest to be created with the "bridge" type.
Excellent find Deepti. Thanks for looking into this - I think this is an issue with the provider.
You're correct - this is an issue in xmlgen.c What is happening here is the following:
1) Guest is created using virsh using network type bridge. 2) xen_net_to_xml() in xmlgen.c gets called instead of kvm_net_to_xml(). 3) Since xend is fine with using a bridge interface without the <source bridge=''/> tag defined, we don't specify one in the xmlgen code. QEMU borks when it attempts to create the guest with the new XML.
1) Also, I noticed that for creating the Xen guest we do not require the <source > field in the <interface > section for both Network and Bridge interface Types. But for the KVM guest its compulsory to have the <source > field in the <interface > section for both Network and Bridge interface Types. 2) Any specific reason for not supporting the KVM guest to be created for the bridge type interface, and supporting Xen guest with only bridge type ?
If you use the network interface type, the libvirt gets all the necessary network information from the virtual network. We don't have to worry about whether the bridge exists, etc. Well, I think we still need the bridge to exist on the system, to be able to use the virtual network available on the machine. In order to see whether the bridge is really required to be present on
Kaitlin Rupert wrote: the machine. I created a virtual network with the following network config file. <network> <name>default</name> <uuid>91e73602-dd76-464c-aaf7-99002d45d289</uuid> <forward/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254' /> </dhcp> </ip> </network> Though I have not specified the bridge info anywhere in the config file , the libvirt assigned its own bridge "vnet0" , see the dump below: virsh net-dumpxml default <network> <name>default</name> <uuid>91e73602-dd76-464c-aaf7-99002d45d289</uuid> <forward mode='nat'/> <bridge name='vnet0' stp='on' forwardDelay='0' /> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254' /> </dhcp> </ip> </network> I then 1) brought the vnet0 down 2) deleted the bridge 3) tried creating the KVM guest with the following network information in it: <interface type="network"> <mac address="00:11:22:33:44:aa"/> <source network="default"/> </interface> and got the following error while creating the guest virsh create new_kvm_net.xml libvir: QEMU error : internal error Failed to add tap interface 'vnet%d' to bridge 'vnet0' : Operation not supported error: Failed to create domain from new_kvm_net.xml Is there any other way to create the virtual network where it does not bother to have a bridge to exist?
3) Also, I did not understand the need for the script field in the interface section. We can create the Xen, KVM guests without this.
This is a good point. Actually, I thought there was some talk of having both Xen and KVM guests use the network interface, but I might be mistaken.
KR> Dan - should the provider return an error if the guest doesn't use KR> a network type interface?
Meaning an existing guest created outside the providers with a network type we don't support? I dunno, I'll have to think on that one.
Right - that's the issue here. We have a KVM guest with a bridge network type. The AddResource() call fails because it generates the new XML incorrectly.
Thanks and Regards, Deepti.
DK> Well, I think we still need the bridge to exist on the system, to DK> be able to use the virtual network available on the machine. In DK> order to see whether the bridge is really required to be present DK> on the machine. Sure, but we can rely on libvirt to handle that for us. DK> Though I have not specified the bridge info anywhere in the config DK> file , the libvirt assigned its own bridge "vnet0" , see the dump DK> below: Right. DK> 1) brought the vnet0 down DK> 2) deleted the bridge DK> 3) tried creating the KVM guest with the following network information This isn't a valid thing to do, though. If the user goes behind libvirt and breaks the networking config, then I think the expectation is that things will not work :) DK> and got the following error while creating the guest DK> virsh create new_kvm_net.xml DK> libvir: QEMU error : internal error Failed to add tap interface DK> vnet%d' to bridge 'vnet0' : Operation not supported DK> error: Failed to create domain from new_kvm_net.xml This is because libvirtd tried to attach the domain's ethernet adapter to a bridge that no longer exists. This _should_ fail and it does. DK> Is there any other way to create the virtual network where it does DK> not bother to have a bridge to exist? I'm not sure what you're asking here, but as far as I can tell, things are behaving as they should. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Kaitlin Rupert wrote:
Well, the providers should be creating <source network='something'>, so I need to check and make sure we're doing that.
I checked whether the provider adds the <source network='something'> and it does for KVM. I tried creating the KVM guest with two interface types:
1) Network Type :
It needs the following fields in the xml file: <interface type='network'> <mac address='11:22:33:aa:bb:cc'/> <source network='default-net'/> </interface>
We are handling this in the provider code.
2) Bridge Type : It needs the following fields in the xml file:
<interface type='bridge'> <mac address='11:22:33:aa:bb:cc'/> <source bridge='testbridge'/> </interface> The provider code in the xmlgen.c file does not support the KVM guest to be created with the "bridge" type.
Excellent find Deepti. Thanks for looking into this - I think this is an issue with the provider.
You're correct - this is an issue in xmlgen.c What is happening here is the following:
1) Guest is created using virsh using network type bridge. 2) xen_net_to_xml() in xmlgen.c gets called instead of kvm_net_to_xml(). 3) Since xend is fine with using a bridge interface without the <source bridge=''/> tag defined, we don't specify one in the xmlgen code. QEMU borks when it attempts to create the guest with the new XML.
1) Also, I noticed that for creating the Xen guest we do not require the <source > field in the <interface > section for both Network and Bridge interface Types. But for the KVM guest its compulsory to have the <source > field in the <interface > section for both Network and Bridge interface Types. 2) Any specific reason for not supporting the KVM guest to be created for the bridge type interface, and supporting Xen guest with only bridge type ?
If you use the network interface type, the libvirt gets all the necessary network information from the virtual network. We don't have to worry about whether the bridge exists, etc.
3) Also, I did not understand the need for the script field in the interface section. We can create the Xen, KVM guests without this.
This is a good point. Actually, I thought there was some talk of having both Xen and KVM guests use the network interface, but I might be mistaken.
KR> Dan - should the provider return an error if the guest doesn't use KR> a network type interface?
Meaning an existing guest created outside the providers with a network type we don't support? I dunno, I'll have to think on that one.
Right - that's the issue here. We have a KVM guest with a bridge network type. The AddResource() call fails because it generates the new XML incorrectly.
Also, Should not the following piece of code in Virt_Device.c be setting appropriate value in the cim_type for the "network" type as well ? static int net_set_type(CMPIInstance *instance, struct net_device *dev) { uint16_t cim_type; if (STREQC(dev->type, "ethernet") || STREQC(dev->type, "bridge")) cim_type = CIM_NET_ETHERNET; else cim_type = CIM_NET_UNKNOWN; CMSetProperty(instance, "LinkTechnology", (CMPIValue *)&cim_type, CMPI_uint16); return 1; } Thanks and Regards, Deepti.
DK> Also, Should not the following piece of code in Virt_Device.c be DK> setting appropriate value in the cim_type for the "network" type DK> as well ? Yep. Patch on the way. Thanks Deepti! -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Guo Lian Yun wrote:
Hi Zhengang and Deepti,
I've list the failing test cases during our discussion yesterday.
I've assigned and names listed as well, it's be great to shoot for completion before May 4th. =)
Thanks!
1) CS.40 --- maybe provider issue -- Deepti InvokeMethod(DefineSystem): *** Provider Virt_VirtualSystemManagementService(27073) exiting due to a SIGSEGV signal
This test case XFAIL because of Bug: 91410 on the F9 with rpm for me. But it fails on F9 with the latest libvirt-cim sources. The error message is as below: *ERROR - Unexpected rc code 1 and description: CIM_ERR_FAILED: ResourceSettings Error: Resource type not supported on this platform ERROR - Exception: Unable create domain test_domain using DefineSystem() InvokeMethod(DefineSystem): CIM_ERR_FAILED: ResourceSettings Error: Resource type not supported on this platform * Here is the flow of the code: define_system -> create_system -> classify_resources -> rasd_to_vdev() is called for PROC, MEM, NET, DISK -> _sysvirt_rasd_to_vdev(). The _sysvirt_rasd_to_vdev does not have any code that is related to PROC dev type and hence the error message. The part of the code in the VSMS.c from where the error message is returned as below : static const char *_sysvirt_rasd_to_vdev(CMPIInstance *inst, struct virt_device *dev, uint16_t type) { if (type == CIM_RES_TYPE_DISK) { return disk_rasd_to_vdev(inst, dev); } else if (type == CIM_RES_TYPE_NET) { return net_rasd_to_vdev(inst, dev); } else if (type == CIM_RES_TYPE_MEM) { return mem_rasd_to_vdev(inst, dev); } return "Resource type not supported on this platform"; } Is this valid ?
2) EAFP.01 & 02 ----- still in working --Daisy
3) ElementConfroms.02 & 04: -- Deepti
4) ElementSettingData.03 --- make sure clean the vs before running -- Zhengang
5) HostSystem.02 -- the difference of rpm and source provider in memory. "kilobyte" vs "megabyte", we have to add branch here -- Daisy
6) Memory 02 --- InvokeMethod(DefineSystem): *** Provider Virt_VirtualSystemManagementService(5492) --Daisy exiting due to a SIGSEGV signal
7) NetworkPort 03 ---- known bug
8) Processor 02 --- InvokeMethod(DefineSystem): *** Provider Virt_VirtualSystemManagementService(15585) exiting due to a SIGSEGV signal -- Deepti
This test case passes on the F9 with rpm for me. But it fails for F9 with the latest libvirt-cim sources. same prob as above for CS.40.
9) RASD.01 & 02 --- "kilobyte" vs "megabyte", we have to add branch here --Zhengang
10) ReferenceProfile.01 & 02 --- also add branch --Deepti
11) ResourceAllocatedFromPool.01~04 --- rpm vs latest with different report message, we have to add branch here -- Daisy
12) ResourcePoolConfigurationService.03 04 06 07 -- CIM_ERR_NOT_SUPPORTED in rpm, we have to add message here -- Deepti
13) SettingsDefine 02 ---- Because of InstanceID, "Domain-0/0" vs "Domain-0/proc", Jay looked into this issue
14) VSSD.04 --- fail on rpm, pass on src, we have to add branch -- Daisy
15) VSMS.01 -- InvokeMethod(DefineSystem): -- Zhengang .02 -- destroy and undefine rpm: destroy branch "rpm" vs "latest" -- Zhengang .06 -- InvokeMethod(AddResourceSettings): CIM_ERR_FAILED: Failed to create domain -- Zhengang
16) VSSDataComponent.03 -- we have to add branch for "error code" -- Daisy
The comments for the other test case failures is sent as part of the another mail with subject "KVM test report on Fedora 9 (4/30)" Thanks and Regards, Deepti.
DK> Is this valid ? No, but it's expected. We're waiting for Jay's processor stuff to be completed before we add that link back in there. Hopefully that will happen before the end of next week. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
participants (5)
-
Dan Smith -
Deepti B Kalakeri -
Guo Lian Yun -
Kaitlin Rupert -
Zhengang Li