Re: [Libvirt-cim] [TEST] Issue with VirtualSystemManagementService/06_addresource.py

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