Introduction
If you’re building a two-node Proxmox VE 9 cluster, you might wonder what happens when one of the nodes goes offline.
Does the remaining node keep running virtual machines?
Can it take over automatically?
This guide explains exactly what happens inside a two-node Proxmox cluster when one node fails — and how to prevent downtime using a QDevice for quorum.
Note: A two node Proxmox VE cluster is NOT recommended in production environments.
Understanding Quorum in a Proxmox Cluster
Proxmox uses Corosync for cluster communication and quorum management. Each node has one vote, and the cluster must have more than 50% of votes to make configuration changes safely.
Quorum protects your cluster from “split-brain” — a dangerous situation where two nodes believe they are both in charge and might run the same VM simultaneously.
| Number of Nodes | Votes Needed for Quorum | If One Node Fails |
|---|---|---|
| 1 | 1 | Cluster offline — no redundancy |
| 2 | 2 | Quorum lost — limited functionality |
| 3 | 2 | Quorum maintained — cluster stays operational |
What Happens When One Node Goes Down (Without QDevice)
In a two-node Proxmox VE 9 cluster without a QDevice, if one node goes down:
The surviving node stays physically online
Virtual machines already running on that node continue to run
But the cluster loses quorum, so:
You cannot start or migrate VMs
You cannot make configuration changes
High Availability (HA) fails over is disabled
Typical CLI message:
Essentially, the node becomes isolated — it still runs workloads, but the cluster behaves as read-only until quorum is restored.
Why Quorum Loss Happens
With only two nodes, each has 1 vote (total 2).
When one node goes down, only 1 vote remains — not enough for majority.
Proxmox intentionally pauses all cluster operations to prevent data corruption.
The Solution: Add a QDevice (Quorum Device)
A QDevice (or quorum device) acts as a third vote in the cluster.
It doesn’t host VMs — it only participates in quorum decisions.
When one Proxmox node fails, the QDevice and the remaining node together keep quorum alive, so your cluster continues to function normally.
Typical QDevice Setup
| Node | Role | IP Address | Vote |
|---|---|---|---|
| pve1 | Proxmox Node | 10.0.0.1 | 1 |
| pve2 | Proxmox Node | 10.0.0.2 | 1 |
| qdevice | Quorum Device | 10.0.0.3 | 1 |
Total votes = 3
If one node fails → 2 votes remain → quorum is still valid.
Benefits of Using a QDevice
Maintains quorum when one node goes down
Enables automatic HA failover
Prevents split-brain
Simple to configure — can run on a lightweight VM, Raspberry Pi, or small Linux host
Checking Cluster and Quorum Status
Use these commands to check your cluster health:
Output example:
List all nodes:
If quorum is lost, you can still manage local VMs through the node shell, but cluster-wide management will be blocked until quorum returns.
Temporary Emergency Fix (Single Node Mode)
If one node is permanently down and you need to regain control temporarily:
⚠️ Use only when you’re 100% sure the other node is offline, not just disconnected — otherwise you risk split-brain.
After repairs:
Best Practices for Two-Node Proxmox Clusters
| Component | Best Practice |
|---|---|
| Cluster Size | Use 2 nodes + 1 QDevice |
| QDevice Location | External VM or physical host |
| Network | Dedicated Corosync link (1 GbE or faster) |
| Storage | Shared (Ceph, NFS, iSCSI) or ZFS replication |
| HA | Enable only if QDevice is configured |
| Monitoring | Use pvecm status and journalctl -u corosync |
Comparison: With vs Without QDevice
| Event | Without QDevice | With QDevice |
|---|---|---|
| One node fails | Cluster loses quorum | Cluster stays operational |
| HA restart | Disabled | Works automatically |
| Configuration changes | Blocked | Allowed |
| Risk of split-brain | Medium | Very Low |
Conclusion
In a two-node Proxmox VE 9 cluster, losing one node means losing quorum — your running VMs survive, but the cluster becomes read-only. To achieve true high availability, always deploy a QDevice or a lightweight third quorum node. It’s a simple setup that ensures your cluster stays functional and safe even if one node fails.