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

[Deepti B Kalakeri]

Kaitlin Rupert wrote:
>>> 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.
I can retain the network part of the tc, but I remember we were of the 
opinion for keeping some of the test case to use virsh so that the 
providers is able to handle the information for the VS created outside 
using VSMS.

Thanks and Regards,
Deepti.