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

[Deepti B Kalakeri]

Kaitlin Rupert wrote:
>>>> 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.
>
I need to verify this.