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=4359... (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@telecom-bretagne.eu>