This BAOI guide provides a structured method for diagnosing a proxmox cluster without quorum.
Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.
Étapes à suivre
1
Collect
To identify the exact error, time time and context.
2
Limit
Identify the systems and users involved.
3
Test
Use appropriate tools or commands to confirm cause.
4
Correct
Apply a targeted and reversible correction.
5
Validate
Play the full screenplay and check the logs.
Commands utiles
pvecm status
systemctl status corosync
À retenir
Keep the initial state.
Avoid multiple simultaneous changes.
Document the final result.
Technical deep dive
Virtualization: disk chains and quorum do not tolerate shortcuts
Technical checkpoints
An AVHDX belongs to a Hyper-V checkpoint chain; manually deleting or renaming it can break parent/child relationships.
Consolidation should use Hyper-V/PowerShell and be preceded by parent-chain and free-space checks.
For Hyper-V, read VHDX/AVHDX chain; for Proxmox, read quorum, members and corosync latency.
Get-VHD <path.avhdx>
pvecm status
pvecm nodes
Topic-specific pitfalls
Copying/renaming an AVHDX in production without understanding its parent can make the VM unbootable.
Forcing quorum on multiple network partitions can create split brain and corruption.
How to validate
The Hyper-V chain is cleanly consolidated and the VM boots without orphaned checkpoints.
The Proxmox cluster regains quorum with expected nodes/links before further changes.
Operational context
A Proxmox cluster without quorum is a cluster-membership and voting problem, not simply a failed web interface. Diagnose node visibility, corosync transport, expected votes and time/network consistency before forcing quorum or changing cluster membership.
Step-by-step checks
Run the cluster status from more than one surviving node and compare membership, quorum state, expected votes and which nodes each member can actually see.
Check corosync link status and the dedicated cluster-network path for packet loss, VLAN/MTU mismatches, firewall filtering or an asymmetric route between nodes.
Confirm node clocks and name resolution are consistent, then inspect corosync and pve-cluster logs around the moment quorum was lost instead of restarting services blindly.
Before any recovery action, identify whether the missing node is temporarily unreachable, permanently failed or intentionally removed; quorum overrides can create split-brain if another partition is still active.
Useful verification commands
Use commands only on systems you administer and capture the read-only output before making a configuration change.
Quorum is restored only when the surviving nodes agree on one cluster membership and the expected vote count matches the intended topology; management and VM operations should then work without a forced local-only override.
Evidence to keep
Keep pvecm status/nodes output from multiple nodes, corosync link state, packet-loss/MTU results, timestamps, expected votes and the relevant corosync/pve-cluster log window.
Frequently asked question
Should I force quorum with pvecm expected 1?
Only as a tightly controlled recovery action when you have proved there is no second active partition. It is not a diagnostic shortcut and can permit conflicting writes in a split-brain scenario.