Network interface pinning inconsistencies: ISO installer vs pve-network-interface-pinning generate

[VictorSTS]

This lab is using PVE9.1.4, no subscription (although don't think there's anything different in Enterprise repo in this regard). Using nested PVE to test Ceph configs, etc. When installing the nested PVE with the iso I choosed to pin the network interfaces, so a config file is created at /usr/local/lib/systemd/network/50-pmx-nic0.link and the nic is pinned correctly.

Then I added a second nic to the VM. Ran pve-network-interface-pinning generate to pin this second nic but to my surpise it did not recognize the previously pinned nic:

pve-network-interface-pinning generate
This will generate name pinning configuration for all interfaces - continue (y/N)?
y
Name for link 'nic0' (enp6s18, enxbc24112c9db4) will change to 'nic0'
Name for link 'ens19' (enp6s19, enxbc241148fd38) will change to 'nic1'
Generating link files
Successfully generated .link files in '/usr/local/lib/systemd/network/'
Updating /etc/pve/nodes/zataca-pve05-IEB01/host.fw.new
Updating /etc/network/interfaces.new
Updating /etc/pve/sdn/controllers.cfg
Updating /etc/pve/sdn/fabrics.cfg
Successfully updated Proxmox VE configuration files.

Please reboot to apply the changes to your configuration

It also creates it's own configuration files:

/usr/local/lib/systemd/network/50-pve-nic0.link
/usr/local/lib/systemd/network/50-pve-nic1.link

Please notice the naming inconsistency (pve vs pmx) of these files. If at some point you start playing with vlans, different bridges on the host, etc, your network may not work as expected because your nic0 may not be associated with the MAC you expect it to be. Don't know the precedence of systemd when using these .link files, but I assume alphanumeric ordering, so the pinning done at install time would take precedence.

Is this just a bug or am I missing something?

 

[jaminmc]

The .link files are to make the network interface name be based on the MAC address of the nic. That way if there is a hardware change, and the PCI buss format changes, the NIC name will stay the same. The enxbc241148fd38 is in alias to a nic that is based on the mac address also, but it isn't as pretty.

Also, If a NIC is not online when the command is run, or passed through to a VM. It will not update the NIC name.

 

[fba]

I think first hand it is a bug, that the installer and the pinning tool use different naming scheme for the .link files.
So it seems reasonable to create an entry on bugzilla.proxmox.com

Aside of that, you could work around with pve-network-interface-pinning generate --interface ens19 --target-name nic1

 

[shanreich]

Yes, that looks unintentional. Either the pinning tool should respect the files generated by the installer or the installer should generate them with the same naming scheme as the pinning tool.

 

[VictorSTS]

The .link files are to make the network interface name be based on the MAC address of the nic. That way if there is a hardware change, and the PCI buss format changes, the NIC name will stay the same. The enxbc241148fd38 is in alias to a nic that is based on the mac address also, but it isn't as pretty.

Also, If a NIC is not online when the command is run, or passed through to a VM. It will not update the NIC name.

Thanks, but that's unrelated to the issue I described.

Aside of that, you could work around with pve-network-interface-pinning generate --interface ens19 --target-name nic1

Problem is that I end up with two .link files for nic0 because pve-network-interface-pinning doesn't recognize there's already a pinned name due to different .link file naming scheme. Both /usr/local/lib/systemd/network/50-pmx-nic0.link and /usr/local/lib/systemd/network/50-pve-nic0.link exists. In this use case, nic1 is pinned correctly by the tool because it wasn't there at install time.

Opened a bug report [1], hope it's easy to fix!

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=7273

 

[fba]

This was meant as example for adding an interface after the pinning of the installer was used.