Re: [Libvirt-cim] Re: KVM on Pegasus Test Run Summary for Sep 10 2008 [ Current Source]

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