[libvirt] [PATCH] Fix dnsmasq/radvd on bridges not being able to be bound to IPv6 address on "recent" kernels

[Benjamin Cama]

Le mercredi 20 juin 2012 à 11:10 +0100, Daniel P. Berrange a écrit :
> On Tue, Jun 19, 2012 at 07:00:58PM +0200, Benjamin Cama wrote:
> > Other solutions that I envisioned were:
> >       * Keeping the *-nic interface up: this would waste an fd for each
> >         bridge during all its life. May be acceptable, I don't really
> >         know.
> 
> Is that because closing the TAP device FD makes it go into offline
> state ?

Yes.

> In the great scheme of things, I don't think one extra
> file descriptor per network is too onerous - there would only ever
> be a handful of networks per host.

It depends on the usage. I am using libvirt to simulate networks,
linking some bridges and VMs together, and it *could* grow quite large
if one wanted to simulate big networks. For me, it's not about the
memory cost of an fd, which is small compared to a VM, but about limits
of the OS (1024 open fds by default; OK, it's still a quite large
number).

> >       * Stop using the dummy tap trick, and set the MAC address directly
> >         on the bridge: it is possible since quite some time it seems,
> >         even if then there is the problem of the bridge not being
> >         RUNNING when empty, contrary to what [2] says, so this will need
> >         fixing (and this fix only happened in 3.1, so it wouldn't work
> >         for 2.6.39)
> 
> While you can set the MAC address on a bridge, there are some
> problems with doing so. The MAC address you set on the bridge
> must match the MAC address of one of the enslaved interfaces
> or no traffic will flow. We can't use the MAC addr of any of
> the guest TAP devices, so we must have a dummy TAP device
> present in the bridge.

It looks like it has changed recently, according to this commit
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=43598813386f6205edf3c21f1fe97f731ccb4f15 (introduced in 3.3) if I understand it well.

[…]
> > Still, this patch is not exactly correct, as radvd get daemonized “too
> > soon” most of the time (i.e. when not debugging libvirtd…) and probes
> > the bridge once it has been set down (even if started before setting it
> > down), thus failing as before (and libvirt lets it be like that: this
> > would need some more checking, maybe). One /may/ introduce some delay
> > between networkStartRadvd() and setting the dummy tap down to solve it,
> > but it seemed too hackish to me. But I couldn't come with a better
> > solution. I would welcome suggestions here.
> 
> Introducing delays is indeed hackish & potentially unreliable if
> starting a network on a highly loaded system. The only real way
> to avoid that race would be to leave the dummy tap device in the
> online state permanently AFAICT.

Does the solution I posted earlier seem OK to avoid that?

Regarding keeping the device operationally up, I don't really know if
it's the best solution or not. I don't know if setting the bridge to a
“disconnected” state when no VM is connected to it has a meaning.

Regards,
-- 
Benjamin Cama <benjamin.cama at telecom-bretagne.eu>