Recommended Services
Supported Scripts
Setting Up a Proxmox VE High-Availability Cluster with Ceph Storage

A single Proxmox node is a single point of failure: if the hardware dies, every VM on it goes down until you manually restore from backup. A Proxmox HA cluster with Ceph fixes that by spreading VM disks across multiple nodes as replicated storage, so when a node fails, its VMs simply restart on a surviving node — because their disk data was never only on the failed machine.

What You Need Before Starting

RequirementWhy
At least 3 Proxmox nodesCluster quorum needs an odd number ≥ 3 to avoid split-brain
At least 3 nodes contributing Ceph OSDsCeph’s default replication factor of 3 needs 3 separate failure domains
A dedicated network for Ceph trafficStorage replication is bandwidth-heavy; sharing it with VM traffic causes contention
Enterprise-grade SSDs, not consumer drivesCeph write latency is sensitive to drive endurance and consistent IOPS

Step 1: Build the Cluster

# On the first node
pvecm create prod-cluster

# On each additional node
pvecm add 10.0.0.11   # IP of the first node

Verify quorum before continuing — a cluster without quorum won’t let you do much of anything, by design, to prevent split-brain:

pvecm status

Step 2: Install and Configure Ceph

Proxmox has first-class Ceph integration in the GUI under Datacenter → Ceph, but the underlying steps are:

# On each node contributing storage
pveceph install
pveceph init --network 10.10.0.0/24   # dedicated Ceph network
pveceph mon create                     # Ceph monitor
pveceph osd create /dev/sdb            # one OSD per physical disk

Once at least three OSDs across three nodes are up, create a Ceph pool and a matching Proxmox storage entry so VM disks can actually be placed on it:

pveceph pool create vm-pool --size 3 --min_size 2

Step 3: Enable HA on the VMs That Need It

HA isn’t automatic for every VM — you opt each one in, and assign it to an HA group if you want to control which nodes it’s allowed to run on:

ha-manager add vm:101 --state started --group prod-group
ha-manager status

How Failover Actually Plays Out

EventWhat happens
A node loses network/powerRemaining nodes detect the loss via corosync heartbeat and confirm quorum is still held
FencingThe failed node is fenced (isolated) so it can’t come back and write to shared storage inconsistently
VM restartHA manager starts the affected VMs on a healthy node, reading their disks from Ceph — no data was only on the dead node

The Trade-Off

Ceph gives you this resilience at the cost of write latency — every write is replicated to multiple OSDs before it’s acknowledged, and that network round-trip is slower than writing to local NVMe. For workloads where raw disk latency matters more than automatic failover, local storage with a separate backup/replication strategy (see Proxmox Backup Server) can be the better fit.

Conclusion

A Proxmox HA cluster with Ceph turns hardware failure from an outage into a brief automatic restart. It needs at least three nodes, a dedicated storage network, and a deliberate choice about which VMs are worth the write-latency trade-off — but for anything that genuinely can’t go down when a single server fails, it’s the standard open-source answer.

Leave a Reply

Your email address will not be published. Required fields are marked *