Re: Specifying names for tap interfaces

[Darren Reed <darrenr%fastmail.net@localhost>]

On 6/07/2012 12:05 AM, Roger Pau Monne wrote:
> Christos Zoulas wrote:
>> On Jul 5,  9:37am, roger.pau%citrix.com@localhost (Roger Pau Monne) wrote:
>> -- Subject: Re: Specifying names for tap interfaces
>>
>> ...
>> | I haven't tried yet, but I assume passing the fd to Qemu will work, and
>> | I plan on using that to fix the Qemu problem. Anyway I had this half
>> | done, because I think it's an interesting feature, not only as a fix to
>> | the Qemu issue.
>>
>> Yes, but it is a solution looking for a problem. Until we actually have
>> a use that makes this feature necessary, we should not add it just to avoid
>> creeping featurism and complexity.
>>
>> | For example being able to name Xen virtual interfaces in
>> | the Dom0 with a user defined name (both tap and vif), but I'm sure other
>> | users will come up with other uses.
>>
>> Yes, that's nice, but purely cosmetic.
>
> It allows users to have persistent interfaces, even after Dom0/DomU reboot, 
> so you can for example graph the traffic a single guest is using, which is 
> not possible now.

Being able to specify the name of a network interface is
useful but I don't think the qemu case is the killer example.

The Virtual Network Stacks project that's listed the NetBSD
wiki would benefit greatly from this because it will allow
each network stack to have its own "lo0" (for example) whilst
the underlying system sees lo0, lo1, etc.

Being able to rename a network device into the name of another
also has advantages. For example, if you replace your fxp0 with
a wm0, it may be easier to tell the system to use a different
name than to adjust the myriad of things in /etc/rc.conf that
use fxp0.

One of the big beneficiaries of being able to rename network
interfaces is when you have a system policy to name everything
as "ethX" or "netX" or "lanX" because then your PXE image that
you install doesn't need to do any tricks to work out which NIC
is the primary one, it is always the same on all hardware. On
top of that, if the automatic naming policy does not follow the
mac id then replacing the first network interface with something
else does not cause disruption if a different driver is used.

But all of these use cases require a solution that is much more
substantial than what has currently being put forward but by
the same token, properly solving this will enable the Xen
problem to be addressed. I think there is more to gain by doing
this once and doing it properly than by allowing a partial
solution.

As a related issue, if the output of ifconfig is going to
contain names that do not directly relate to physical devices
then it needs to be easier to discover them all that by doing
"drvctl -p <nic>" on each of them.

Darren