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

[Kaitlin Rupert]

>> 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 at linux.vnet.ibm.com