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.