Re: Specifying names for tap interfaces

[Roger Pau Monné <roger.pau%entel.upc.edu@localhost>]

On Wed, Jun 20, 2012 at 9:59 PM, Jean-Yves Migeon
<jeanyves.migeon%free.fr@localhost> wrote:
> 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.

But then when the hotplug script tries to do a `brconfig bridge0 add
tap-foobar` it will fail.

Also, as someone already suggested it will be interesting to be able
to give interfaces associated with guests a permanent name, which this
approach doesn't solve. The solution should be at least applicable to
both tap and vif interfaces, but since we are there, why not make it
work for all network interfaces? I think other users might benefit
from this feature (like not having to rewrite firewall rules when
changing network cards).

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