On Wed, 2009-07-29 at 17:32 +0100, Daniel P. Berrange wrote: > On Wed, Jul 29, 2009 at 12:27:58AM -0400, Aron Griffis wrote: > > (Sorry, my first posting included some gnulib droppings in the > > patch. This removes that, everything else is the same.) > > > > As far as I can tell, there's no reason to format the device string in > > brAddTap(). Delegate the job to TUNSETIFF, thereby removing the loop > > and the MAX_TAP_ID artificial limit. This patch allows me to get > > 421 guests running before hitting other limits. > > Very bizarre, the kernel seems to interpret 'vnet%d' and auto > fillin the unique integer for us. So this patch is just removing > the equivalent logic from libvirt. Wonder why we had it there in > the first place !
I could think of two theories: 1) I had a vague notion older kernel versions rejected any names containing %d except tun%d or tap%d; not true, this behaviour looks like it has been around forever 2) Maybe we were doing it so as to avoid querying the ifname the kernel allocated; that would be silly, since SETIFF does return the allocated name to userspace So, I dunno either - maybe it was just a misunderstanding about (1) Patch looks good to me Cheers, Mark. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list