[ovs-dev] [PATCH 3 of 5] Disable brcompatd
blp at nicira.com
Thu Oct 1 17:15:10 UTC 2009
Ian Campbell <Ian.Campbell at citrix.com> writes:
> On Wed, 2009-09-30 at 11:57 +0100, Ian Campbell wrote:
>> The compat layer is now unused in the vswitch branch of XenServer.
> Unfortunately this turned out to be not quite true...
> The compatibility layer is still used by /etc/xen/qemu-ifup to add the
> emulated network device (tapX.Y) to the bridge. This is easy enough to
> fix by patching that script to use ovs-vsctl but there is no equivalent
> hook to remove tapX.Y from the bridge -- with Linux bridging this
> happens automatically when the device disappears and brcompatd takes
> care of it for Vswitch. Without brcompatd the tap devices accumulate
> in /etc/ovs-vswitchd.conf
> I think this can be solved by using udev hotplug events to catch tap*.*
> being added and removed (in older kernels apparently the add event
> only occurred after the tap device was brought up, but that appears to
> have been fixed in 2.6.7 at least). This is a slightly invasive change
> so I'm afraid I have turned brcompatd back on for the time being but I
> hope to finally disable it soon.
It's been a bit of a struggle figuring out the correct model for
specifying ports in ovs-vswitchd.conf. For static environments,
it makes sense to just specify all the ports that might appear
and not worry about it if a few are missing. My original design
for vSwitch sort of assumed that we'd have hooks that trigger
whenever a port arrives or disappears. The "Linux bridge model"
where ports that disappear get immediately and permanently
deleted makes a lot more sense in a very dynamic environment.
Maybe that's what Open vSwitch should implement, too, in the end,
or maybe it should even be configurable on a per-port basis.
I hope that it is practical to handle this properly in udev for
now, but I guess that is really a wart that we should fix in Open
> While looking at this I noticed that for vif devices you use
> dump-vif-details to add a bunch of VIF information to the configuration,
> (port.vifX.Y.net-uuid, port.vifX.Y.vif-mac, port.vifX.Y.vif-uuid and
> port.vifX.Y.vm-uuid) but you do not do this for tapX.Y, should you?
> tapX.Y and vifX.Y are essentially the same device (both correspond to
> the same VIF device in the XenAPI), traffic will flip over when the
> guest loads its PV drivers so I suspect in the vswitch controller you
> want to handle them the same. Perhaps since the MAC address is the same
> for vifX.Y and tapX.Y you already get this via the entries added for
> vifX.Y and do the right thing?
We intentionally don't bother with tap devices. The controller
is smart and knows that tapX.Y and vifX.Y are related and does
the right thing.
More information about the dev