[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Specifying names for tap interfaces
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
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
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
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
Well, that (169,N) points to - for the most part the pointer goes the
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
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:
Anyway, I'm open to suggestions about how we should tackle this problem.
Main Index |
Thread Index |