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