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

[Daniel P. Berrange]

On Wed, Jun 20, 2012 at 02:48:55PM +0200, Benjamin Cama wrote:
> 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.


Ok, that's a bit too recent for us to be able to rely on in
libvirt.

> 
> […]
> > > 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?

If you're happy that your latest patch is good enough, then so
am I.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|