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

[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.

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.