Setting Up a Proxmox Cluster for High Availability

An error when setting up a Proxmox cluster can cost you your data. Typical scenario: two nodes, no shared storage configured, the cluster constantly loses quorum, VMs crash every week. We know how to fix this. Over many projects for companies of various sizes — from startups to enterprise — our goal is to have your VMs automatically migrate on node failure and downtime measured in minutes, not hours.

How to Set Up a Proxmox Cluster for High Availability?

We share practical configurations battle-tested in production. This article covers key architectural decisions: from storage selection to fencing setup. The cost is calculated individually but is typically 20–30% lower than VMware alternatives.

Problems We Solve

Minimum Number of Nodes: 3

Quorum (majority vote) is required for cluster decisions. With 2 nodes, on communication loss each considers itself the sole survivor — a split-brain occurs, and both attempt to launch the same VMs, leading to data corruption. 3 nodes guarantee that any single failure leaves a majority. According to Proxmox documentation, quorum is critical for cluster integrity.

How to Avoid Common Network Pitfalls?

The most frequent issue is that shared storage is not configured or is configured incorrectly. HA in Proxmox requires shared storage: the VM must be accessible from any node. If the VM disk resides on the local ZFS of the host, on its failure the VM cannot migrate — data is unavailable.

The second issue is a single network interface for all traffic. Cluster network (corosync), migration network, and VM traffic on one NIC: under high load, corosync loses packets, the cluster considers the host dead and initiates fencing — forcibly powering it off via IPMI. In reality the host is alive, just busy. Result — unnecessary failover and downtime.

Network Architecture: What and Why

Recommended scheme for 3 nodes:

Corosync on a dedicated interface is mandatory. If a separate physical NIC is unavailable, use VLAN with QoS priority.

How to Choose Shared Storage for Proxmox HA?

The choice of shared storage determines fault tolerance and budget. Compare the main options.

Comparison of Shared Storage Options

Ceph — built into Proxmox, distributed storage directly on the node disks. Each node contributes disks to a Ceph pool, data is replicated across 3 nodes automatically. Downside: Ceph consumes ~2–4 GB RAM per OSD.

NFS/iSCSI — external storage array. Easier to manage but a single point of failure if the array itself is not HA.

Shared ZFS via iSCSI — ZFS on a dedicated storage server, exported as an iSCSI LUN and mounted on all nodes.

Creating the Cluster

# On the first node — create the cluster
pvecm create pve-cluster --link0 address=10.10.1.1 --link1 address=10.10.2.1
# On the second and third nodes — join
pvecm add 10.10.1.1 --link0 address=10.10.1.2 --link1 address=10.10.2.2
pvecm add 10.10.1.1 --link0 address=10.10.1.3 --link1 address=10.10.2.3
# Check cluster status
pvecm status

--link0 and --link1 — 2 independent corosync paths. On loss of one, the cluster continues through the other. This is the redundant ring protocol, critical for stability.

Configuring the HA Manager

After setting up shared storage, enable HA for specific VMs:

# Add a VM to HA group
ha-manager add vm:101 --state started --max_restart 3 --max_relocate 2

# Create HA group with node priorities
ha-manager groupadd production-group --nodes pve1:3,pve2:2,pve3:1 --restricted 1
ha-manager add vm:101 --group production-group

max_restart — how many times HA restarts the VM on the current node before evacuation. max_relocate — how many times it migrates to another node. restricted — VM launches only on nodes in the group.

Why Is Fencing Critical?

Fencing is a mandatory HA component. Proxmox must be able to forcibly power off the problematic node before launching its VMs on another host. Without fencing, data corruption may occur: two hosts writing to the same disk simultaneously. Configure via IPMI/iDRAC/iLO:

# Configure IPMI fencing for node pve1
pvesh set /nodes/pve1/config --wakeonlan 0
# Add fence agent configuration in /etc/pve/corosync.conf

totem {
  ring0_addr: 10.10.1.1
  ring1_addr: 10.10.2.1
}
quorum {
  provider: corosync_votequorum
}
nodelist {
  node {
    name: pve1
    nodeid: 1
  }
}
logging {
  to_syslog: yes
}

Live Migration and Load

Proxmox supports live migration (analogous to vMotion) for VMs without shutdown. For correct operation: identical or compatible CPUs on all nodes (flag --cpu host limits migration — use --cpu kvm64 for compatibility), shared storage, migration network on a separate interface.

# Manual live migration of VM 101 to node pve2 qm migrate 101 pve2 --live 1 --migration_network 10.10.3.0/24 

What Is Included in the Work

1. Full documentation of cluster, network, and storage configuration
2. Access to Proxmox, IPMI, monitoring for your administrator
3. Training your team on basic operations (3–4 hours)
4. Guarantee of HA configuration operability for 30 days
5. Post-release support: 3 months of phone/email consultations
6. Data migration from existing infrastructure (if needed)
7. Automatic recovery scripts for typical failures

Get a consultation from an engineer before starting — we will select the optimal architecture for your budget and load. Order a turnkey setup and get a cluster ready for production. Fault tolerance savings can reach up to 40% compared to traditional solutions. Contact us to evaluate your project.

Timelines

Setup of a 3-node cluster with Ceph: 3–5 days. With external storage (NFS/iSCSI): 2–3 days. From scratch, including OS installation on hosts: add 1–2 days.