Kaitlin Rupert wrote:
Yes, I agree with you that we should make use of the Providers supplied functions, like DefineSystem() as much possible. I had tried supplying the networkpoolname/bridgename in the VirtXML, and it works fine till then to get an XML which contains invalid networkpool/bridgename. But when we call cim_define() we dont make use of the XML generated till then. In cim_define() we make use of VSSD, various RASD and I did not find a relevant field in NetRASD which could be used for supplying the invalid name info.
I tried using ElementName, but was not much help. Can you suggest how or which of the VSSD, RASD fields could be used to supply the networkpool/birdge name.
The get_nasd_class() function takes a network name. So, the __init__ for the VirtCIM class should take a network name and pass this to the get_nasd_class() function.
When I replied yesterday, I thought __init__ was already taking the network name as an argument. Sorry for the confusion there.
Ya right, the get_nasd_class() takes the net_name. 1) The only place where the networkname/bridgename can be passed is through the PoolID, is this correct ? 2) Like the way we supply networkpool info as part of PoolID, how do we supply the same for Bridge type ? According to me PoolID='Bridge/virbr0' should work, right ? Also, I believe the PoolID='Bridge/virbr0' information translates to the following in the XML ? <interface type='bridge'> <mac address='00:11:22:33:44:aa'/> <source bridge='virbr0'/> </interface> I tried using the PoolID='Bridge/bridgewrong' to test the 05_RAPF_err.py tc and it worked for me on KVM. Using PoolID='Bridge/bridgewrong' the XML from the debug statement contained the interface type as network as below: xmlgen.c(640): New UUID Virt_VirtualSystemManagementService.c(990): System XML: <domain type='kvm'> <uuid>5ed4620c-3d04-43b4-995e-36e6da93cf63</uuid> <name>RAPF_domain</name> <on_poweroff>destroy</on_poweroff> <on_crash>destroy</on_crash> <os> <type>hvm</type> <boot dev='hd'/> </os> <currentMemory>131072</currentMemory> <memory>131072</memory> <vcpu>1</vcpu> <devices> *<interface type='network'> <mac address='00:11:22:33:44:aa'/> <source network='bridgewrong'/> </interface> *<disk type='file' device='disk'> <source file='/tmp/default-kvm-dimage'/> <target dev='hda'/> </disk> <graphics type='vnc' port='-1'/> </devices> </domain> But for Xen/XenFV , using PoolID='Bridge/bridgewrong' and with the above mapping of bridgeinfo supplied as part of the PoolID to network in the XML fails with the following error: *misc_util.c(72): Connecting to libvirt with uri `xen' libvir: QEMU error : no network with matching name Virt_VirtualSystemManagementService.c(771): Failed to define domain from XML* The above error thrown by the provider is valid for Xen/XenFV, since even virsh fails to define a VS when an non-existing networkpool info is used. [Note: it allowed the VS to be defined with non-existing bridge] How and why is it important to map from Bridge to network from the providers perspective ? Can't we just retain the information that is supplied through NetRASD as it is ? Am, I missing something ? Can you help me proceed with the implementation of non-existing networkpoolname/bridgename scenario in 05_RAPF_err.py . Thanks and Regards, Deepti.