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.