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>
The PoolID is used to pass in the network pool name. The providers currently don't support creating a guest with a bridge type. The format for PoolID is "NetworkPool/networkpool_name" - so passing "Bridge/bridgewrong" isn't the proper format.
I tried using the PoolID='Bridge/bridgewrong' to test the 05_RAPF_err.py tc and it worked for me on KVM.
If you tried to start this guest, you'd get the following error: type. libvir: QEMU error : internal error Network 'bridgewrong' not found
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*
Dan - do you think this is a check that we should be doing in the providers? I can see a situation where someone might want to create template guest - where the its not important if the network pool exists. It's unfortunate that a precheck is done in the Xen case but not the KVM case.
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 ?
If a network pool is suppled when a guest is defined, libvirt will handle the appropriate mapping to a bridge. This is why the providers define guests with the network type.
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 .
To use cim_define(), you'll need to remove the bridge related portion of the test. Only the network scenario is valid. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com