[pve-devel] [PATCH manager/widget-toolkit 0/2] show altenative interface names in the web ui

[Thomas Lamprecht]

Am 15.07.25 um 10:36 schrieb Dominik Csapak:
> On 7/15/25 10:17, Thomas Lamprecht wrote:
>>
>>>     calculated for *each*, so e.g. if i have
>>>      nicX, nicY and nicZ all point to the same device, we'd have to make the altname list generation
>>>     more complicated
>>>
>>>
>>> IMHO it would be ok to always show the 'canonical' name (whatever ip link/kernel says)
>>> in the 'name' column and everything else in the 'altname' column regardless what is
>>> configured in /e/n/i
>>
>> There is no real canonical name, there's a legacy name that might be
>> called primary one, but as one can use the others transparently for it
>> we really must not think to much into that terminology, it's as first
>> class as the other names.
> 
> i would interpret the name the kernel has (e.g. what is in /proc/net/dev) as the 'canonical name' ?
> please correct me if i'm wrong about that though

Those files and folders will always use the legacy name with the
stricter naming length limits for not surprising any older tool
with the more flexible newer naming,

That's why legacy name might slightly the better term for these,
but as they will stay basically forever it's probably not really
useful to make that distinction either.

Most users won't do much directly with these files, and if they are
likely to be a bit more experienced to figure out this distinction.
Most users, even technical ones, will use iproute2 tools if they
can avoid poking /proc or /sys and especially the less experienced
one only will check /e/n/i and ip addr/link when they run into trouble,
which is they main underlying reason I want to show the altnames in
that config view, so that their live gets a little bit easier by seeing
what "iface XYZ" stanza they will need to adapt independent of the (alt)
name used. And as one can use all names with iproute2 already this has
the nice side effect of adding feature parity and consistency with a
side benefit of a smaller chance for broken upgrades on systemd naming
scheme policy changes. 


> ok then we have to think about how to organize the altnames structure properly
> otherwise it's a PITA to map from the name in the /e/n/i to all others
> 
> 
> (this is all implementation detail of course, but does make a bit of a headache)
> currently we have a hash with collections of 'altname' => 'what ip link reports'
> but in the case we have altnames in the /e/n/i, we'd actually need the a list of names that are 
> equivalent, and that either as a list to search through, or duplicated for each iface name that it 
> can reference, so e.g.
> 
> 
> if we have nicX, nicY, nicZ all alternatives to each other, now we have:
> {
>     'nicY' => 'nicX',
>     'nicZ' => 'nicX',
> }
> 
> but we actually want something like this?
> 
> {
>     'nicX' => ['nixY', 'nicZ'],
>     'nicY' => ['nicX', 'nicZ'],
>     'nicZ' => ['nicX', 'nicY'],
> }
> 
> 
> because when we want to show the alternative names of e.g. nicY the first structure is a bit bad to 
> search through
> 

So we basically have to start with a hash of all names from /e/n/i as keys
and an empty array, then go through the keys and values of the altname map
and add every name (independnt of "primary" = key or "altname" one of the
values for that entry where the /e/n/i name matches one of the keys or values.

fwiw, the API could already add more info if you want to future proof it
w.r.t. putting a distinction between legacy/primary name and altnames.

{

   'e-n-i-name' => {
        'primary' => '...',
         'altnames' => ['...'],
    },
    ...
}

That way we would be flexible with adapting the UI to user feedback while
keeping the API as is. For now we could just merge all primary and altname
with the e-n-i name filtered out in a renderer for the new column.