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?
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(a)telecom-bretagne.eu>