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(a)cn.ibm.com IBM China Development Lab, Shanghai, China TEL: (86)-21-61008057 ------------------------------------------------------------------------ _______________________________________________ Libvirt-cim mailing list Libvirt-cim(a)redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim

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.

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. ------------------------------------------------------------------------ _______________________________________________ Libvirt-cim mailing list Libvirt-cim(a)redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim

>> >> 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.

>> >> 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.

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