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

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=4... (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?