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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list