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

Ian Campbell Ian.Campbell at citrix.com
Thu Oct 1 13:09:54 UTC 2009


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.

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?

Ian.

[0] According to rumour in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547790






More information about the dev mailing list