[pve-devel] [PATCH pve-manager 1/1] cli: add pveeth

[Thomas Lamprecht]

Am 10.07.25 um 16:53 schrieb Gabriel Goller:
> On 09.07.2025 21:45, Stefan Hanreich wrote:
>>> [snip]
>> Example invocations of pveeth:
>>
>> $ pveeth pin --nic enp1s0 --force 0 --dry_run 0
>>
>> Generates a pinning for enp1s0 (if it doesn't exist already) and
>> updates the configuration file.
>>
>> $ pveeth pin --force 1 --dry_run 0
> 
> s/pin/unpin
> 
>> Deletes all existing pins and re-generates them.
>>
>> For more information on the parameters see the API description.
>>
>> I've decided to let dry_run generate the configuration files in the
>> current working directory, since it is then easy to diff the generated
>> files with the existing configuration files using the diffviewer of
>> the users' choice.
>>
>> Additionally, when writing the configuration files, they get backed up
>> by creating a .bak at the location of the configuration file.
>>
>> Currently we only support a fixed prefix: 'nic'. This is because we
>> rely on PHYISCAL_NIC_RE for detecting physical network interfaces
>> across several places in our codebase. For now, nic has been added as
>> a valid prefix for NICs in pve-common, so we use that prefix here.
> 
> This would be nice to have as a comment in the code, I can already see
> people that want to change the prefix and start editing the constant :)
> 
>> In order to support custom prefixes, we would have to remove every
>> place in the code relying on PHYISCAL_NIC_RE (at least), in order to
>> avoid breakage.
> 
> When pinning, could we add the previous old name as an altname? So tools
> that respect altnames could work transparently.
> 
> This should be as simple as adding, e.g.:
> 
>      AlternativeName=ens18
> 
> to the link file.

This can interfere with automatic naming of unpinned/new interfaces and can
get really confusing if the automatic derived name changes due to replugging
the NIC to another slot and then the pinned alt name is wrong, as it suggest
that the NIC is in a different slot. Or if the layout changes otherwise and
another NIC would get this alt name, so there might be different NICs then
with very similar names.

> 
> However, unpinning has a problem. Currently, we reset to the
> `ID_NET_NAME_PATH` name from `udevadm` and remove the link file, but we
> don't know the current systemd `NamePolicy`.
> 
> For example, if the original interface was `ens18` using Slot policy,
> after pinning it becomes `nic0`. When unpinning, the interface becomes
> `ens18` again (because I'm using slot policy), but the config files
> reference `enp0s18` (because `pveeth` assumes we use path policy). This
> breaks the network configuration.
> 
> I think the solution is to avoid deleting the link file during
> unpinning. Instead, we should just update the interface name.
> 
> The problem is that we can't determine which policy was originally used,
> so pin-unpin cycles *don't* restore the original interface name.
> 

This I'd need to think through, just wanted to comment on above before
I forget.