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.