[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