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

[Gabriel Goller <g.goller@proxmox.com>]

On 10.07.2025 17:08, Thomas Lamprecht wrote:
>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.

Ah true, didn't think of this. Yeah this would create a mess, nevermind.

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

If we really want to make pin and unpin involutive, we would need to
store somewhere the interface names or store the interface naming
policy.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel