Re: [Libvirt-cim] [PATCH] [TEST] Adding 05_RAPF_err.py to verify RAPF
>> 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(a)linux.vnet.ibm.com