Re: Specifying names for tap interfaces

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Jun 22, 2012 at 02:57:09PM +1000, Darren Reed wrote:
> > it'll be longer anyway, because the point of aliases (beside fixing
> > xen problems) is to give meaningfull names. typing 'team-foo-dmz' will
> > always be longer than 'wm0'. prefixing it with keywork: isn't a big
> > deal.
> 
> So you want add a label to a network interface?
> 
> Sort of how we can label a disk?

It would be more like a GPT label than a plain disk label, but yes,
that's the idea. With the restriction that multiple interfaces can't have
the same label at the same time in a system. And I want to be able
to lookup interfaces by label instead of by name (BTW, I want to do this
with gpt partitions too, even if right now we can't do that).

> 
> >> On 21/06/2012 8:01 PM, Roger Pau Monne wrote:
> >>> While this is true if you give a name to the interface on the config
> >>> file, but how can the toolstack (xl, that launches Qemu) choose an
> >>> interface name and pass it to Qemu when no one is specified? Well,
> >>> we might be able to search for a free tap device and pass this as the
> >>> desired name, but this is a really racy solution, as someone else might
> >>> request a tap device while we are launching Qemu, and take our chosen
> >>> tap device behind our back, so we will end up failing to create that
> >>> domain.
> >>>
> >>> Also, I don't think there's anyway to create vifs interfaces with a
> >>> specific name, which I think will also be an interesting feature to
> >>> have.
> >>
> >> So in that second paragraph you've identified the real problem.
> > 
> > I dissagree that this is the real problem. There is a desired feature:
> > being able to tag an interface with a user-provided string, and
> > using this string instead of its name for various task. This is not
> > restricted to xen xvif or tap devices, I have other use cases too
> > (on a system with lots of interface, having a meaningfull string
> > for them would be helpfull). But I don't think remplacing the actual
> > interface name with a user-specified string is the way to go. This
> > user-specified string should add information, not replace existing
> > information.
> 
> I'm not sure that I follow what you're saying.
> 
> Can you please expand on that?

Right now, the unique identifier of an interface is its name, which is
set by the system when the interface is discovered. I don't think we should
change this part, because we are used to the names as they are now, and it
also carry some information (wm0 is an intel adapter, tap0 is a pseudo
interface, xvif5-0 is a Xen PV backend interface connected to the interface
of index 0 in the guest id 5, etc).
But sometimes we'd like to have more, user-defined information easily
available for interfaces, on systems with lots of interfaces.
example 1: xvif5-0 is connected to interface 0 of domU 5. But what is
domU 5 ? I have to use xm list to match the id against a domU's name.
example 2: I have a system with 2 quad-port intel. I know wm6 is
the third port of the second quad-port adapter, but what is it connected to ?

With xaliases (which could also be called label, this is probably the righ
name for that), users could add some informations to interfaces
(either by hand or by some script). 
In example 1, the /usr/pkg/etc/xen/scripts/vif-bridge script could
label xvif5-0 with the domU's name followed by interface index in the domU
(say, if by domU's name is proxy, the label would be proxy0).
In example 2, /etc/ifconfig.wm5 could contains (this is just an example of
course):
label team-foo-vlan

Then, ifconfig would display the label as part of interface data,
which can give the information to the admin.

In addition, if we make sure labels are unique in a system, we
could refer to interfaces by label instead of by name (just like
I'd like to use a GPT label in fstab instead of /dev/dkX), we could
use labels in places where names are actually used. If we make the kernel
know that label:X in ifreq is interface's label X and not interface's
name label:X, modifications to network tools should be minimal.

For those who knows nothing aboud xen: a domU is a VM. When a VM is started,
for each network interface in the domU there is a corresponding interface
in the dom0 called xvif<x>-<y>, created when the VM is started and destroyed
when the VM is destroyed. A VM reboot is a destroy/create cycle, so
the domU's id change and a new xvif<x>-<y> is created, with a different x
each time. each time a xvif<x>-<y> is created or destroyed,
/usr/pkg/etc/xen/scripts/vif-bridge is called with parameters.
The domU's name is specified in the Xen VM config file,
/usr/pkg/etc/xen/scripts/vif-bridge has easy access to this information.
This is for PV domUs.
For HVM domUs, there is a a qemu process started for each domU which emulates
disks (a PIIX4 usually) and network controllers (this can be a few different
models, including ne2000 and e1000). just as with plain qemu, 
for each emulated network device a tap device is created in the dom0, so
that qemu can do something usefull with data from the emulated device.
Up to now (with the old xm toolstack), qemu creates a tapn device and
calls a script to configure it (connect to a bridge usually).
With the new xl toolstack, the script is called by xl and not by qemu,
and xl has problems to know the name of the tap device created by qemu.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--