Re: Specifying names for tap interfaces

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 20.06.2012 00:17, Martin Husemann wrote:
> On Wed, Jun 20, 2012 at 01:59:55AM +0200, Jean-Yves Migeon wrote:
>> This needs some thought regarding the cleanliness of the API, but I
>> would do it through properties, just for reusability (instead of rolling
>> out your own API).
> 
> I disagree - wether there should be an api to set interface names to arbitrary
> strings, or give interface names an arbitrary alias, or have a mapping layer
> that refers via arbitrary names to network devices, is completely orthogonal
> to the issue at hand. This needs *a lot* more design work.

It is not completely orthogonal. The problem is passing data back between:
- a process that creates a tap and which is the only one able to know
its real name (Qemu),
- tools that will use the tap's name to attach to something like a
bridge, but cannot know it in advance before Qemu creates it.

So we need an API/subsystem that somehow allows passing this tiny bit of
information between these two. Properties is one, adding an extra member
to ifnet is another one too.

> However, there already is a perfectly working api to create tap interfaces
> at will with a consistent number: ioctl(SIOCIFCREATE,...) and then open
> the corresponding /dev/tapN. There is no need to fork ifconfig or anything
> fancy.
> 
> Xen should just use this and create reliable/persistent mappings of
> domUs to tapNs.

"Xen" is not really concerned by this problem, only the xl toolstack and
Qemu are.

Speaking of which, another way of passing/storing this sort of data is
Xenstore. However, the script approach makes it hard to manage errors,
so it would have to be done "natively" inside Qemu.

BTW, what is the problem with symlinks like Mouse suggested? Pass down
the /dev/tap-foobar to Qemu, use SIOCIFCREATE and if successful, symlink
/dev/tap-foobar to /dev/tapN from Qemu? This avoids playing with ifnet
and kernel.

That would not be the first time symlinks are used for this, LVM comes
to mind.

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost