[Libvirt-cim] [PATCH] [TEST] Adding 05_RAPF_err.py to verify RAPF

Kaitlin Rupert kaitlin at linux.vnet.ibm.com
Tue Apr 8 18:38:51 UTC 2008


Deepti B Kalakeri wrote:
> 
> 
> Dan Smith wrote:
>> DK> +def check_bridge_name(bridgename):
>> DK> +    bridge_list = live.available_bridges(server)
>> DK> +    vbr = None DK> +    if bridgename in bridge_list:
>> DK> +        import random
>> DK> +        vbr = bridgename + str(random.randint(1, 100))
>> DK> +        if vbr in bridge_list:
>> DK> +            logger.error('Need to give different bridge name 
>> since it already exists')
>> DK> +            return None
>> DK> +    else:
>> DK> +        vbr = bridgename
>> DK> +    return vbr
>>
>> I think this would make a lot more sense as:
>>
>>   def get_unique_bridge():
>>       bridge = "invalid-bridge"
>>         while bridge not in live.available_bridges():
>>           bridge += str(random.randint(1,100))
>>         return bridge
>>
>>   
> Ok , will modify this.
>> DK> +    if virt != 'XenFV':
>> DK> +        bridge = vsxml.set_vbridge(server)
>>
>> Can you explain why this special case exists?
>>
>>   
> The network information for the XenFV is getting assigned by default.
> The def _devices(): section of the XenFV is calling the
> 
> self.set_bridge(CIM_IP) and hence the bridge information is getting 
> assigned by default.
> While this is not the case with the Xen and KVM.

KVM also calls set_bridge() in the _devices() call.

Xen does not, but the _devices() call for Xen sets the interface as an 
ethernet type.  So there's no need to set a bridge for the Xen case.

-- 
Kaitlin Rupert
IBM Linux Technology Center
kaitlin at linux.vnet.ibm.com




More information about the Libvirt-cim mailing list