proxmox-network-interface-pinning working and then not.

tomtom13

Renowned Member
Dec 28, 2016
114
14
83
43
So, I've wanted to try pin interface names, and give the shot the proxmox blessed script.

So I've run the script the for the motherboard 10G interface:
pve-network-interface-pinning generate --interface enp12s0 --target-name eth_mobo_10g

I've checked whenever interfaces file updated, everything looked OK on the surface. I've rebooted the node couple of times to see whenever there are any problems occurring - no issue there. I've added the eth_mobo_10g to the vmbr0 just in case next steps would not pan out.

"Time for something more fancy"

So, let's try x550 pcie card. Similar command.
Code:
 pve-network-interface-pinning generate --interface enp9s0f0 --target-name eth_pcie_x550_10g_0
pve-network-interface-pinning generate --interface enp9s0f1 --target-name eth_pcie_x550_10g_1

Everything looks OK, interfaces file seems updated ... howver after the reboot I get this:

Screenshot 2025-10-05 at 20.05.32.png

Seems that those are just hanging there in "mid-air", couple more reboots - still the same.
good old fashioned ifconfig - nothing exists:
Code:
ifconfig | grep eth_
eth_mobo_10g: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
eth_mobo_2g5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

ip link, even more emptiness:
Code:
ip link | grep eth_
2: eth_mobo_10g: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP mode DEFAULT group default qlen 1000
3: eth_mobo_2g5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr10 state UP mode DEFAULT group default qlen 1000

So now, I would like to solve this problem before I move to more funky cards and start doing this cluster wide.

Have I done something wrong ?

I did check link folder:
Code:
/usr/local/lib/systemd/network# ls -la
total 27
drwxr-xr-x 2 root root  6 Oct  5 19:42 .
drwxr-xr-x 3 root root  3 Oct  5 17:35 ..
-rw-r--r-- 1 root root 74 Oct  5 17:37 50-pve-eth_mobo_10g.link
-rw-r--r-- 1 root root 74 Oct  5 17:35 50-pve-eth_mobo_2g5.link
-rw-r--r-- 1 root root 81 Oct  5 19:42 50-pve-eth_pcie_x550_10g_0.link
-rw-r--r-- 1 root root 81 Oct  5 19:42 50-pve-eth_pcie_x550_10g_1.link

Code:
cat 50-pve-eth_pcie_x550_10g_0.link
[Match]
MACAddress=REDACTED but checked and MAC matches.
Type=ether

[Link]
Name=eth_pcie_x550_10g_0
 
Last edited:
Your interface is name is too long, Linux kernel only supports up to 15 bytes (= 15 ASCII characters). That's most likely why it doesn't work.

I'll check what's wrong with validation - but in the meanwhile you should be able to fix your issue by using a shorter name.
 
  • Like
Reactions: Stoiko Ivanov
@shanreich Thanks for the heads up !
Do you know where this limitation came from, I've never used long names for ethernet in my life, but I've used very long names for interfaces to drives that I've wrote in the past and those used networking stack (albeit not ethernet layer). Would it be more of systemd introduced problem ?

In the meantime - when I've got my self into this pickle - how to undo the changes (eradicate traces of it) before I'll go for shorter name?
 
Last edited:
Strange, we used CAN interfaces that uses whole networking stack and created interface per destination mailbox & destination combo ... it was interface bonanza (not saying that it was a sane solution but fitted the intended use case) ... I remember the names going up to 40 characters and how we didn't hit that limit just puzzles me ?!?!?! I guess we've not used all the parts of network stack. Saying that, I always stuck to ethX.Y in my naming schemes but wanted this time to be a bit more fancy.

@shanreich & @fba thanks for your help !
 
In the meantime - when I've got my self into this pickle - how to undo the changes (eradicate traces of it) before I'll go for shorter name?
For reverting the pinning itself, it should suffice to remove the generated link files from /usr/local/lib/systemd/network

Additionally you would also need to check at least /etc/network/interfaces for any mentions of the name that you tried to use and change it back to the initial name. If you're using the SDN or the firewall, you would need to adjust the name of the interface there as well if it is used.
 
@shanreich thanks. I've tried that, so far it worked, I just wanted to know that there is no magic kung-fu with root-fs/boot params/deeper systemd configuration.
 
Last edited: