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

[Kaitlin Rupert]

>>> 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.
> Wrt to the tc when working with NetRASD requires the domain to be 
> created with interface type as bridge.
> NetRASD lists the domains which are created with bridge as the network 
> type. Please correct me if I am wrong.

You'll only get a NetRASD instance if the guest has an interface that is 
tied to a virtual network.  That is - if the guest's bridge belongs to a 
defined virtual network.

> I suggest we keep the default network type for all the three Virtual 
> types to be bridge and the give
> another function which allows to add network type other than bridge to 
> the domain when required
> 

The original Xen XML used an ethernet style network as the default.  Can 
you verify which (if any) test cases will be affected if we change Xen 
to use a bridge style network as the default?

In general, I'd like to see the default XML for all three types be as 
similar as possible (where it makes sense).  So I think this is a sound 
idea.

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