SVI/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-03-31 06:34:17 -04:00
Code Issues 2.6k Packages Projects Releases 10 Wiki Activity

Add pve-network-interface-pinning to PVE post-install #1785

New Issue
Closed
opened 2025-11-20 05:17:23 -05:00 by saavagebueno · 7 comments
saavagebueno commented 2025-11-20 05:17:23 -05:00
Owner
Copy Link

Originally created by @mmomjian on GitHub (Aug 25, 2025).

🌟 Briefly describe the feature

Add pve-network-interface-pinning to PVE post-install

📝 Detailed description

It would be helpful to add pve-network-interface-pinning generate as an option to the PVE post install script (link)

Source: PVE docs

💡 Why is this useful?

This helps reduce the chance of NICs changing names after PCIE device changes.

Originally created by @mmomjian on GitHub (Aug 25, 2025). ### 🌟 Briefly describe the feature Add pve-network-interface-pinning to PVE post-install ### 📝 Detailed description It would be helpful to add `pve-network-interface-pinning generate` as an option to the PVE post install script ([link](https://community-scripts.github.io/ProxmoxVE/scripts?id=post-pve-install)) Source: [PVE docs](https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_using_the_pve_network_interface_pinning_tool) ### 💡 Why is this useful? This helps reduce the chance of NICs changing names after PCIE device changes.
saavagebueno added the enhancement label 2025-11-20 05:17:23 -05:00
saavagebueno commented 2025-11-20 05:17:23 -05:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Aug 26, 2025):

I'm not a fan of such interventions per se, most users are ultimately happy that they can use the little bit of terminal. Then you should ask them whether networks are pinned? To be honest, I can see this going wrong and some users then saying we'll change something on their network cards or something else.

@MickLesk commented on GitHub (Aug 26, 2025): I'm not a fan of such interventions per se, most users are ultimately happy that they can use the little bit of terminal. Then you should ask them whether networks are pinned? To be honest, I can see this going wrong and some users then saying we'll change something on their network cards or something else.
saavagebueno commented 2025-11-20 05:17:23 -05:00
Author
Owner
Copy Link

@lasharor commented on GitHub (Aug 26, 2025):

I think this is a usefull request. Or at least to point out that this is an option in the latest PVE version. I don't really see what the downside is. Especially if done during post install.

@lasharor commented on GitHub (Aug 26, 2025): I think this is a usefull request. Or at least to point out that this is an option in the latest PVE version. I don't really see what the downside is. Especially if done during post install.
saavagebueno commented 2025-11-20 05:17:24 -05:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Aug 26, 2025):

The main hurdle for normal users is risk of breaking network connectivity.

-> The pve-network-interface-pinning tool creates .link files and rewrites key configs (/etc/network/interfaces, host firewall, SDN configs).
-> If the user doesn’t fully understand what’s happening, a reboot could result in renamed NICs and the host losing network access.
-> the most home-lab users are fine with systemd’s predictable naming as-is; they rarely hit renaming issues.
-> pining is mainly valuable for more complex setups (servers with multiple PCIe NICs, frequent hardware changes).

So enabling it automatically in post-install is dangerous — safer is just to inform users that the option exists, or provide it as a separate optional tool/script.

@MickLesk commented on GitHub (Aug 26, 2025): The main hurdle for normal users is risk of breaking network connectivity. -> The pve-network-interface-pinning tool creates .link files and rewrites key configs (/etc/network/interfaces, host firewall, SDN configs). -> If the user doesn’t fully understand what’s happening, a reboot could result in renamed NICs and the host losing network access. -> the most home-lab users are fine with systemd’s predictable naming as-is; they rarely hit renaming issues. -> pining is mainly valuable for more complex setups (servers with multiple PCIe NICs, frequent hardware changes). So enabling it automatically in post-install is dangerous — safer is just to inform users that the option exists, or provide it as a separate optional tool/script.
saavagebueno commented 2025-11-20 05:17:24 -05:00
Author
Owner
Copy Link

@mmomjian commented on GitHub (Aug 26, 2025):

I was picturing an option -“do you want to pin network interface names? This may disrupt network connection until the next reboot”

@mmomjian commented on GitHub (Aug 26, 2025): I was picturing an option -“do you want to pin network interface names? This may disrupt network connection until the next reboot”
saavagebueno commented 2025-11-20 05:17:24 -05:00
Author
Owner
Copy Link

@michelroegl-brunner commented on GitHub (Aug 26, 2025):

This would be, as stated by @MickLesk before, better suited in its own script/tool. There is no need to bloat existing scripts with functions most useres would prob. never use.

@michelroegl-brunner commented on GitHub (Aug 26, 2025): This would be, as stated by @MickLesk before, better suited in its own script/tool. There is no need to bloat existing scripts with functions most useres would prob. never use.
saavagebueno commented 2025-11-20 05:17:24 -05:00
Author
Owner
Copy Link

@mmomjian commented on GitHub (Aug 26, 2025):

I feel like you could make that argument about everything in the post install script tbh. Why is disabling HA not its own script for example? Either way it doesn’t bother me, I will continue to configure my nodes myself

@mmomjian commented on GitHub (Aug 26, 2025): I feel like you could make that argument about everything in the post install script tbh. Why is disabling HA not its own script for example? Either way it doesn’t bother me, I will continue to configure my nodes myself
saavagebueno commented 2025-11-20 05:17:24 -05:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Aug 26, 2025):

In this case, however, you can't just assume that you are the only one; the scripts have been used almost 1 million times in the last few months. Some users don't even know how curl works or what nano is.
The post installer script intentionally whiptails everyone through, with additional hints etc.

Perhaps conceivable as a single script, but not as an extension. It is not a core component of the installation.

@MickLesk commented on GitHub (Aug 26, 2025): In this case, however, you can't just assume that you are the only one; the scripts have been used almost 1 million times in the last few months. Some users don't even know how curl works or what nano is. The post installer script intentionally whiptails everyone through, with additional hints etc. Perhaps conceivable as a single script, but not as an extension. It is not a core component of the installation.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
🛑 Failure to comply with the guidelines
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
Implemented in VED waiting push to Main
in project pipeline
invalid
investigation
json
maintenance
new script
new script
nice to have
not a script issue
not planned
organization
pull-request
Mirrored from GitHub Pull Request
 question
refactor
rename script
security
update script
website
wontdo
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/ProxmoxVE#1785
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?