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.
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com