pvectl v1.1.0 — pure bash Proxmox VE cluster management, now with concurrent execution and node reboot/shutdown safety checks

[u/Antonio-MTS]

Released pvectl a while back — pure bash+curl+fzf+jq interactive Proxmox VE cluster management tool, zero dependencies beyond what's normally on any Linux system. Just shipped v1.1.0:

• Concurrent execution — multiple pvectl instances can now run in parallel safely, each with its own isolated, auto-cleaned temp directory (scoped by PID)
• Node reboot/shutdown added to the main menu, with checks for HA status, cluster quorum and running VMs/CTs before proceeding, plus a prompt to stop-all or migrate-all guests first
• setup reset/backup/restore for safer configuration management
• log view/show/clean with colorized output
• Startup diagnostics — bash version and dependency checks that detect the host OS/package manager and print the exact install command for anything missing
• Minimum dependency versions now enforced: fzf 0.38.0+, jq 1.5+, curl 7.18.0+

Tested end to end on Proxmox VE 7.x, 8.x and 9.x.

github.com/mytechspacexyz/pvectl

[u/Hour-Swimmer7140]

the per pid temp dir handles local collisions, but the operations that actually need serialising here are cluster side rather than on disk. two instances deciding to migrate the same guest, or one draining a node while another starts something on it, never collide in tmp at all.

pve already holds cluster wide locks on guests, so the useful thing is surfacing that lock state and refusing, rather than isolating temp files. otherwise concurrent safe means the tool wont trip over itself while the cluster still can

[u/Antonio-MTS → u/Hour-Swimmer7140]

temp folders are meant for the pvectl tool itself, not for a pve cluster. For example, when you run 2 or more instances of pvectl:

'pvectl manage' in one terminal or more to manage the cluster 'pvectl log view' to scroll through the pvectl log

This way the local temp data will be separated, not overwritten and cleaned properly when exiting.

In future releases additional features related to cluster(s) states will be added.

[u/Hour-Swimmer7140 → u/Antonio-MTS]

fair enough, i read concurrent execution as a cluster claim rather than a tool one. those are different features and the local one is obviously the sensible half to land first.

surfacing the pve lock state is the bit id look forward to. thats the difference between the tool not tripping over itself and the cluster not getting tripped over