Re: Specifying names for tap interfaces

[Roger Pau Monne <roger.pau%citrix.com@localhost>]

Mouse wrote:
> > Well in Linux you can give any name to tap interfaces
>
> And other interfaces, IIRC.
>
> This is something I've never liked about Linux, though I'm not entirely
> sure why.
>
> > Qemu opens /dev/tap and creates a new /dev/tapX, then fetches the
> > name of this interface using the TAPGIFNAME.  In the past, Qemu had a
> > parameter that you could use to set the bridge Qemu has to pass to
> > the hotplug script, but this is no longer present, and the script
> > Qemu calls after creating the interface only knows the name of the
> > newly created interface, which is not really helpful, [...]
>
> So, the problem is that the tap unit is not known until Qemu starts,
> and Qemu provides no way to associate that interface with other
> attributes of the particular Qemu instance that created it, and under
> Linux this is addressed by hiding that information in the interface
> name.

Yes, under Linux the name of the interface to be created is passed to 
Qemu, so it is decided and known before the interface is created.

> This strikes me as horrible design, abusing the interface name,
> of all things, to pass information through Qemu; it would be much
> cleaner to give Qemu arguments which it passes verbatim to the script.

Passing a set of arguments to append to the script to call upon creating 
the network interface doesn't seem like a better idea to me, for 
instance error checking of the execution of that script becomes much 
more difficult, and if we can control the execution of that script 
directly, that  gives us the flexibility of choosing how to recover from 
errors.

> Hm, it occurs to me that in a sense that's what the design is now.  Is
> there any reason the `interface name' has to actually be an interface
> name?  Could we let Qemu think it's an interface name but have it
> actually have nothing to do with any interface name?

Well, Qemu creates that interface, and it needs it in order to inject 
and read traffic to and from the guest. So it needs to be a real tap 
interface, which will be used by the guest.

> > Wouldn't it be possible to create a network interface with a random
> > name, that still points to (169,N), even if N is not part of the
> > name?
>
> Well, that (169,N) points to - for the most part the pointer goes the
> other way.
>
> > > Overall, it seems easiest to teach qemu to use 'ifconfig tapN
> > > create' as an alternative to clone/set-name.
> > I'm not really sure using an external command is better than
> > performing a set of ioctls, it's much more trickier to catch errors,
>
> It is, however, immensely more flexible.

Yes, but you need all the fork machinery, to be able to fork a process, 
wait for it for finish or kill it if stuck and check the return value. 
Also it requires many more resources than a simple ioctl and is more 
prone to errors and bugs.

> > and I would say that overall I doubt Qemu developers would ever agree
> > to switching from using /dev/tap to ifconfig.
>
> I don't know Qemu developers at all, but are they interested in a clean
> design that is reasonably portable, or do they think Linux is all they
> care to bother with and if it happens to work on something else that's
> fine but of no particular value to them?  If they're closer to the
> former end of that spectrum, surely we can work out something that's
> not too gross for both us and Linux.  (And if they're more towards the
> latter, then we'll probably have to have private patches anyway.)

We already have a separate file for tap device creation (tap-bsd.c), 
which we share with Open and Free, so I don't think they will put much 
objections on changing that to something more suitable if a strong 
argument is made.

> Actually, part of the problem is that inteface names are a separate
> namespace unto themselves.  It occurs to me that what we want here is,
> loosely put, a symlink for an interface name - but symlinks are
> filesystem objects, and interface names have nothing to do with the
> filesystem.

Yes, that will be good, being able to create interface name "symlinks" 
(unless we start polluting /dev/ with a forest of symlinks). Should this 
be a global thing for all network interfaces?

I've found some information about a remote interface (QMP) that allows 
fetching information from Qemu instances, theoretically we should be 
able to fetch the "tap" device name from there, but it seems like the 
required command to fetch network interfaces information was never 
added. I've sent and email to qemu-devel, asking about this missing 
command, since it seems it was about to be commited a long time ago:

http://wiki.qemu.org/Google_Summer_of_Code_2010/QMP#query-netdev

Anyway, I'm open to suggestions about how we should tackle this problem.

Thanks, Roger.