Proxmox ops
Reached over SSH as pve1 / pve2 (root). Read infra/proxmox.md for this
environment's node names, VMIDs, and storage layout before acting.
For the complete command surface of this platform, read capabilities/proxmox.md.
Diagnose first
hh run pve1 "pvesh get /version" # API alive hh run pve1 "qm list && pct list" # inventory + states hh run pve1 "cat /proc/loadavg; free -h; df -h /"# node pressure hh run pve1 "pvesm status" # storage health/usage hh run pve1 "pvecm status" # quorum, if clustered hh run pve1 "ha-manager status" # HA, if used
Common cases
- VM won't start: check
qm status <id> --verbose, thenjournalctl -u pvedaemon -n 100, then the VM configqm config <id>for a missing disk or ISO still mounted. - VM stuck / unresponsive:
qm monitor <id>info, considerqm reset <id>(confirm first, it is a hard reset). - Storage full blocking operations:
pvesm statusanddf -h; clear old vzdump archives or snapshots, do not delete VM disks. - Node hot or thrashing: identify the VM with
qm list+ guest load; often a backup window or a runaway guest.
State-changing (confirm first, name the target and effect)
hh run pve1 "qm snapshot <id> pre-change-$(date +%F)" # snapshot before risk hh run pve1 "qm start|stop|reboot|shutdown <id>" hh run pve1 "pct start|stop|reboot <id>" hh run pve1 "qm migrate <id> <target-node> --online" # if clustered hh run pve1 "vzdump <id> --storage <backupstore> --mode snapshot"
Never run qm destroy / pct destroy or storage-wiping operations without an
explicit go-ahead, and prefer a fresh backup or snapshot first.
Handoff
If the fault is inside the guest OS, SSH into the guest itself. If it is the storage under the node (ZFS on TrueNAS), switch to truenas-ops.


