What a Proxmox cluster is (and is not)

Why this matters in production

Many operators misunderstand what a Proxmox cluster is. They expect automatic failover, shared storage, and centralised management — and they get some of that, but not all. This lesson clarifies the actual capabilities.

What a cluster provides

flowchart LR
  A[Cluster] --> B[Centralised management]
  A --> C[Configuration replication]
  A --> D[Quorum]
  A --> E[Live migration with shared storage]
  A -. not .-> F[Automatic failover]
  A -. not .-> G[Shared storage]
  A -. not .-> H[Replication]

What the cluster does NOT provide

• Automatic failover. HA is a separate feature that requires cluster-managed VMs, shared storage, and explicit configuration.
• Storage. A cluster does not include storage. You must add shared or distributed storage yourself (NFS, iSCSI, Ceph).
• Replication. Replication is a separate feature; you set it up per VM.
• Cross-site. A single cluster assumes a low-latency network. Multi-site requires multiple clusters.

Prerequisites for cluster formation

Before running pvecm create:

• All nodes are running Proxmox VE 9.x.
• NTP is working on every node (time skew breaks Corosync).
• Forward AND reverse DNS resolves correctly for every node.
• A dedicated, low-latency network for Corosync.
• At least 3 nodes (or 2 + QDevice).

Single-node clusters

Proxmox allows a single-node cluster. This gives you centralised management features (pmxcfs locking, multi-node view if you add nodes later) but no quorum tolerance.

flowchart LR
  N1[Single node] -->|no quorum tolerance| Q[Quorum]

A single-node cluster can become a multi-node cluster by adding nodes.

Multi-node cluster

flowchart TB
  N1[pve-01]
  N2[pve-02]
  N3[pve-03]
  N1 --> C[Corosync]
  N2 --> C
  N3 --> C
  C --> Q[Quorum]

With 3 nodes, the cluster tolerates 1 node loss. With 2 nodes + QDevice, it tolerates the loss of either the master or the secondary (the QDevice acts as tiebreaker).

Common anti-patterns

• 2-node cluster without QDevice. Loses quorum if either node fails.
• Cluster over a slow or unreliable network. Corosync requires low-latency; WAN clusters without QDevice are unreliable.
• Sharing the Corosync network with VM guest traffic. A backup or VM I/O burst can starve Corosync, causing spurious node evictions.
• Running cluster operations on the management interface. Use a separate network for cluster communication.

Production considerations

Common mistakes

• Joining a node with the wrong hostname.
• Running cluster nodes on different Proxmox versions (must match).
• Using a slow WAN as the cluster network.
• Confusing cluster features with HA features.

Key takeaways

• A cluster gives you centralised management, configuration replication, quorum, and live migration (with shared storage).
• It does NOT give you automatic failover, storage, or replication.
• DNS and NTP must work before the cluster forms.

Knowledge check