Troubleshooting playbook ยท Reviewed 2026-10-23
Proxmox node offline playbook
A cautious triage path for a Proxmox node that appears offline, loses network access, or may affect cluster quorum and guests.
When to use this
Use this before forcing a reboot or changing cluster membership. It focuses on host reachability, guest impact, storage, and quorum awareness.
Protect data and access first
- Do not remove or recreate cluster configuration just to clear an offline status.
- Avoid power cycling a node until guest state, storage state, and quorum implications are understood.
Before you change anything
- Record the node name, last known time, affected guests and storage.
- Check out-of-band console access if available.
- Identify whether the node belongs to a cluster and how many voting nodes remain.
Decision path
Separate reachability from service state
Check DNS, ping, management interface and local console independently.
Check: You know whether this is a network, host, or web-interface problem.
Assess cluster safety
Check quorum and the state of other nodes before changing services or membership.
Check: No action is taken that could create split-brain risk.
Check storage and guests
Identify whether storage is reachable and whether guests are running, fenced, or unavailable.
Check: The recovery action accounts for guest and data impact.
Recover the smallest layer
Restore network, host service, or web service only after identifying the failed layer.
Check: The node rejoins cleanly and guest status is verified.
Stop and escalate when
- Quorum is lost or cluster state is unclear.
- Shared storage shows errors or a degraded array.
- A guest may be running simultaneously on more than one node.