A Proxmox VE cluster combines several servers into a single managed infrastructure. This provides centralized management, live VM migration, and optional high availability (HA).
Cluster Requirements
- A minimum of 3 nodes for HA (for quorum)
- Identical Proxmox VE version on all nodes
- Reliable network between nodes (latency < 5 ms)
- Time synchronization (NTP/Chrony) on all nodes
- Unique hostname and IP for each node
Creating a Cluster
# On the first (master) node
pvecm create my-cluster --link0 192.168.1.100
# Check status
pvecm statusAdding a Node to the Cluster
# On the new node (make sure the master is reachable via SSH)
pvecm add 192.168.1.100 --link0 192.168.1.101
# Check the list of nodes
pvecm nodesConfiguring High Availability (HA)
HA automatically restarts a VM on another node if the current one fails:
# Add a VM to an HA group via CLI
ha-manager add vm:100 --group ha-group --state started
# Create an HA group
ha-manager groupadd ha-group --nodes "node1,node2,node3" --restricted 0
# HA status
ha-manager statusConfiguring the Corosync Network
# Add a second link for the cluster network (backup)
pvecm add 192.168.1.100 --link0 192.168.1.101 --link1 10.0.0.101
# /etc/pve/corosync.conf — view the configuration
cat /etc/pve/corosync.confQuorum Recovery
# When quorum is lost (a node is unreachable)
# Temporarily lower the expected quorum (DANGEROUS — for maintenance only)
pvecm expected 1
# Remove the unreachable node from the cluster
pvecm delnode pve3
# Restore the cluster configuration on the remaining nodes
systemctl restart corosync pve-clusterpvecm expected 1 in a production environment without understanding the consequences can lead to split-brain and data loss. Always consult the documentation.
Cluster Monitoring
# Status of all nodes
pvesh get /nodes
pvecm status
# Cluster logs
journalctl -u corosync -f
# Ping test between nodes
corosync-cfgtool -sCommon Corosync and quorum errors
Most cluster problems show up right when you create or add a node — Corosync strictly checks configuration consistency and reports a mismatch immediately instead of running in a half-working state.
Corosync Cluster Engine Authentication error
cluster not ready - no quorum? (500)
TOTEM ] Retransmit List: 15 16 17- Authentication error: the /etc/corosync/authkey file differs between nodes — usually from manually copying the configuration instead of using the standard command. Reinstall the node from scratch via
pvecm add. - no quorum? (500): the cluster has less than half its votes online — any configuration changes through the web interface are blocked until quorum is restored.
- Retransmit List growing: the Corosync network is overloaded or dropping packets — move cluster traffic to a dedicated, low-latency link.
A useful habit is to compare when the problem started against the network change and package update log: two-thirds of such incidents line up with planned maintenance rather than appearing on their own.
Quorum options with two nodes
The classic setup needs an odd number of votes; for two servers there are three practical options.
| Option | Votes | Cost | When to use |
|---|---|---|---|
| QDevice (external arbiter) | +1 vote | Lightweight service outside the cluster | A third independent host is available for the arbiter |
| A third full node | +2 votes | A full server | Budget allows a third physical node |
| No HA, manual intervention | — | None | The cluster exists only for live migration |
When a Proxmox cluster is not the right fit
Clustering adds not just capabilities but also operational overhead.
- Two servers with no QDevice and no readiness to manually restore quorum after a failure — the risk of a full management outage outweighs the benefit of live migration.
- Nodes in different data centers with network latency above 5-10 ms — Corosync and HA become unstable, and false failovers can occur.
- One-off tasks or test setups — the operational overhead of running a cluster (certificates, quorum, time sync) does not pay off.
Verifying the setup result
After creating the cluster and configuring HA, confirm that quorum is stable and failover actually works.
# Quorum and node list
pvecm status
# Real latency between nodes on the cluster network
corosync-cfgtool -s
# Test: disable the network link on one node and see whether the VM in the HA group restarts on another
ha-manager statusIf, after a node failure, the VM from the HA group comes back up on another node within a minute, the setup works. The recovery procedure for a lost quorum is covered in recovering Proxmox quorum.
Frequently asked questions
Why does a Proxmox cluster need an odd number of nodes for quorum?
Quorum means more than half the votes out of the total node count, and with an even number the network can easily split into two equal halves, each believing it's the real cluster — that's called split-brain. An odd number of votes guarantees that exactly one part of the cluster stays in the majority no matter how the connection breaks.
Does High Availability turn on automatically once nodes join a cluster?
No, joining a cluster only links the nodes for management and live migration; High Availability is configured separately by adding the chosen VM to an HA group and listing which nodes it's allowed to restart on after a failure. Without that step, the VM just keeps running normally, only on clustered infrastructure.
What is fencing, and why is it required for reliable HA?
Fencing is a mechanism that forcibly cuts power to a failed node through an external device such as IPMI or a managed PDU. Without fencing, the cluster can't be sure a failed node truly stopped rather than just losing connectivity briefly, and it may start the same VM on another node at once — which is exactly how split-brain happens.
Can HA be set up on two nodes without a third node or a QDevice?
Technically yes, but without an extra arbiter vote, quorum between two nodes is lost easily whenever either one fails, and recovery needs manual intervention from an administrator. Stable, automatic HA needs a third vote — either a lightweight external QDevice or a full third node — otherwise the cluster risks a complete management outage from a single failure.