[ovs-dev] [PATCH 3 of 5] Disable brcompatd

[Ben Pfaff]

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[0] 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.

Good catch.

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
vSwitch eventually.

> 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.