From Scratch to Production-Ready
Proxmox VE 8.x · Ceph Reef · PBS · PDM · Corosync

Proxmox VE
High Availability Cluster

End-to-end implementation guide for a 3-node Proxmox HA cluster with Ceph distributed storage, LACP-bonded live migration, centralized backups, and automatic VM failover.

3-Node HA Cluster Corosync Quorum Ceph RBD ×3 PBS Backup PDM Multi-Site LACP 4-NIC Bond
A Note on the IPs Used All IPs in this guide are sanitized examples on the 192.168.x.x private range. Replace them with your environment's actual values: 192.168.10.x = Management · 192.168.20.x = Corosync · 192.168.30.x = Migration · nodes are pve01, pve02, pve03 (Node 1 / 2 / 3).
Contents
What This Guide Builds

A complete 3-node Proxmox VE High Availability cluster with replicated Ceph storage, LACP-bonded migration network, centralized PBS backups, and PDM multi-cluster management — designed for maximum redundancy, fast live migration, and automatic VM failover with zero manual intervention on node failure.

00 Architecture & Why HA Matters
Why a Real HA Cluster?

Six capabilities a production HA cluster gives you that a single Proxmox host cannot:

Zero-Touch Failover
VMs restart on a surviving node within ~60 seconds of host failure — no manual intervention.
Replicated Storage
Ceph writes every block to all 3 nodes — survive a node loss with zero data loss.
Live Migration
Move running VMs between hosts over a 4-NIC LACP bond with zero downtime.
Network Isolation
Three dedicated planes — management, Corosync heartbeat, migration — no contention.
Centralized Backups
PBS handles dedup, incremental backup, and one-click restore across all nodes.
Single Pane of Glass
PDM aggregates multiple Proxmox clusters under one management UI.
Cluster Architecture — Live Topology

A live view of the running cluster. Watch the heartbeat pulse across the Corosync ring, data replicate down into Ceph, backups flow to PBS — and VM 100 stay continuously available as it migrates across nodes.

PBS Backup Server · dedup PDM Datacenter Manager ‹ Corosync heartbeat · quorum 3/3 › // NODE 1 pve01 Primary · OSD · Mon · Mgr // NODE 2 pve02 Secondary · OSD · Mon · Mgr // NODE 3 pve03 Secondary · OSD · Mon · Mgr Ceph RADOS · pool: VM-Disk replicated ×3 · every block mirrored to all three nodes VM 100 HA · live
Corosync heartbeat Ceph replication Backup / management HA VM (live migration)
Figure 1 — Live topology. Three nodes form the Corosync quorum and a Ceph ×3 replicated pool; PBS and PDM sit outside the cluster. VM 100 keeps running as it moves between hosts.
Key Components Deployed
ComponentTechnologyPurpose
Cluster EngineCorosyncCluster quorum, heartbeat, node communication
Distributed StorageCeph RADOSReplicated block storage for HA-protected VMs
Backup InfrastructurePBSCentralised VM backup and restore across all nodes
Datacenter ManagementPDMSingle-pane-of-glass for the entire cluster
Migration FabricLACP BondHigh-bandwidth 4× NIC bond for live VM migration
High AvailabilityPVE HA ManagerAutomatic VM restart and relocation on node failure
01 Infrastructure Inventory
Node Inventory (Sanitized)
NodeManagement IPCorosync IPMigration IPRole
pve01 (Node 1)192.168.10.11/24192.168.20.11/24192.168.30.11/24Primary
pve02 (Node 2)192.168.10.12/24192.168.20.12/24192.168.30.12/24Secondary
pve03 (Node 3)192.168.10.13/24192.168.20.13/24192.168.30.13/24Secondary
Network Architecture
PlaneSubnetInterfacePurpose
Management192.168.10.0/24vmbr0 / eth0Web UI, SSH, API, IPMI
Corosync Heartbeat192.168.20.0/24eth5 (dedicated)Cluster quorum and heartbeat only
Live VM Migration192.168.30.0/24bond0 (4× NICs)LACP bonded migration fabric
Storage Design
StorageTypeDiskUsage
local-lvmLVM-ThinsdaOS, local non-HA VMs
VM-DiskCeph RBDsdb (all nodes)HA-protected VMs — replicated 3 ways
PBSPBS RepositoryDedicated PBS hostCentralised backup for all VMs
Prerequisites Checklist
Three physical/bare-metal servers with Proxmox VE 8.x installed on sda
Each node has at least 5 NICs: 1× management, 1× Corosync, 4× migration bond
sdb available and unpartitioned on all three nodes (for Ceph OSD)
All nodes reachable over the management network
Proxmox Backup Server installed and accessible (separate host or VM)
Root SSH access to all nodes
Corosync and migration networks are isolated (no gateway required)
PHASE 1 Node Preparation

Before building the cluster, each node must be correctly named and have full hostname resolution between all peers. Proxmox identifies cluster members by hostname, not by IP address.

1.1Hostname Configuration

Execute on each node individually via SSH or the Proxmox console.

bash · run on Node 1 (pve01)
hostnamectl set-hostname pve01
hostname
# Expected output: pve01
bash · Node 2 (pve02) / Node 3 (pve03)
hostnamectl set-hostname pve02   # on Node 2
hostnamectl set-hostname pve03   # on Node 3
hostname
1.2/etc/hosts on ALL Nodes

Every node must resolve every peer by name. This must be applied on all three nodes.

/etc/hosts — identical on all three nodes
127.0.0.1        localhost
192.168.10.11    pve01.cluster.local    pve01
192.168.10.12    pve02.cluster.local    pve02
192.168.10.13    pve03.cluster.local    pve03
1.3Verify Bidirectional Resolution
bash · ping by hostname from every node
# From pve01
ping -c 3 pve02
ping -c 3 pve03

# From pve02
ping -c 3 pve01
ping -c 3 pve03

# From pve03
ping -c 3 pve01
ping -c 3 pve02
⚠ All pings must succeed before moving to Phase 2. A failed hostname resolution will cause cluster join to fail or result in split-brain scenarios.
1.4Update & Reboot
bash · on each node
apt update && apt full-upgrade -y
reboot
After reboot
Verify the node comes back online and the hostname is still correct before proceeding.
PHASE 2 Network Configuration

Two dedicated network planes are configured: a 4-NIC LACP bond for VM live migration (high bandwidth), and a dedicated Corosync interface (low-latency, isolated heartbeat).

2.1Identify Network Interfaces
bash
# List all interfaces
ip -o link show | awk '{print $2, $9}'

# Alternative
ls /sys/class/net/
Interface names vary by hardware
Real names will be like enp3s0, eno1, eth0. Replace eth0..eth5 in the examples with your actual names.
2.2Configure the Migration Bond (LACP — 4 NICs)

The bond aggregates 4 physical NICs via IEEE 802.3ad for maximum migration bandwidth.

Web UI Method
  • Log in to the Proxmox Web UI of the node
  • Navigate to: Node → System → Network
  • Click Create → Linux Bond
FieldValue
Namebond0
Slaves / Memberseth1 eth2 eth3 eth4 (4 migration NICs)
ModeLACP (802.3ad)
Hash Policylayer2+3
IPv4/CIDR(leave blank — bond is enslaved to a bridge)
CommentMigration Bond — 4× NIC LACP
CLI Method — /etc/network/interfaces
ini · pve01 (Node 1)
auto lo
iface lo inet loopback

# Management Interface
auto eth0
iface eth0 inet static
    address 192.168.10.11/24
    gateway 192.168.10.1

# Corosync Heartbeat — dedicated NIC, no gateway
auto eth5
iface eth5 inet static
    address 192.168.20.11/24

# Migration Bond — 4 NICs in LACP
auto bond0
iface bond0 inet manual
    bond-slaves eth1 eth2 eth3 eth4
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer2+3
    bond-lacp-rate fast

# Migration Bridge over bond0
auto vmbr1
iface vmbr1 inet static
    address 192.168.30.11/24
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0

For pve02 / pve03: use the same structure, replacing host octets with .12 and .13 on each subnet.

2.3Apply & Verify
bash
# Apply network changes without rebooting
ifreload -a

# Verify bond is active and all slaves are up
cat /proc/net/bonding/bond0

# Verify all interfaces are up with correct IPs
ip addr show

# Test migration network connectivity (from pve01)
ping -c 3 192.168.30.12   # pve02 migration IP
ping -c 3 192.168.30.13   # pve03 migration IP

# Test Corosync network connectivity (from pve01)
ping -c 3 192.168.20.12
ping -c 3 192.168.20.13
⚠ Switch-side LACP: Ensure your switch supports 802.3ad and the port group is configured for LACP. Without it, use bond-mode active-backup instead.
PHASE 3 Cluster Creation & Node Joining

The cluster is created on pve01; pve02 and pve03 join it. Corosync runs over the isolated 192.168.20.0/24 heartbeat network.

3.1Create the Cluster on pve01
Web UI
  • Log in: https://192.168.10.11:8006
  • Datacenter → Cluster → Create Cluster
  • Name: proxmox-ha-cluster · Ring 0 Address: 192.168.20.11
CLI Alternative
bash · on pve01
pvecm create proxmox-ha-cluster --ring0_addr 192.168.20.11
pvecm status
3.2Retrieve Join Information

On pve01: Datacenter → Cluster → Join Information → Copy Information. Or via CLI: pvecm info

3.3Join pve02 to the Cluster
⚠ Before joining: ensure pve02 has no existing VMs or containers. Both qm list and pct list must return empty. Backup configs from /etc/pve/qemu-server/ and /etc/pve/lxc/ first if any exist.
  • Log in to pve02: https://192.168.10.12:8006
  • Datacenter → Cluster → Join Cluster
  • Paste join info · Peer: 192.168.10.11 · Ring 0: 192.168.20.12
bash · CLI alternative on pve02
pvecm add 192.168.10.11 \
    --ring0_addr 192.168.20.12 \
    --use_ssh
3.4Join pve03 to the Cluster

Repeat with pve03 — peer 192.168.10.11, Ring 0 192.168.20.13.

3.5Verify Cluster State
bash · run from any node
pvecm status

# Expected:
#   Name: proxmox-ha-cluster
#   Nodes: 3
#   Quorum: 2  (quorate)
#   Nodeid   Votes  Name
#   1        1      pve01 (local)
#   2        1      pve02
#   3        1      pve03
3.6Configure Migration Network
Datacenter → Options → Migration:
  • Type: secure
  • Network: 192.168.30.0/24

All live VM migrations now traverse the bonded high-bandwidth network — not the management interface.

PHASE 4 Proxmox Backup Server (PBS)

PBS provides centralised, deduplicated backup storage for all VMs across the cluster. Install on a dedicated host (physical or VM) — never on cluster nodes themselves.

4.1Install PBS on a Dedicated Host
bash · on the PBS host
# Add PBS repository
echo 'deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription' \
    > /etc/apt/sources.list.d/pbs.list

# Add Proxmox GPG key
wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg \
    -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg

# Install & start
apt update && apt install -y proxmox-backup-server
systemctl enable --now proxmox-backup
4.2Create the Backup Datastore

In PBS UI (https://<pbs-host>:8007): Administration → Datastores → Add Datastore

FieldValue
Namevm-backups
Backing Path/mnt/backup-store
GC Scheduledaily
Prune Scheduledaily
4.3Create Backup User & API Token
bash · on PBS host
# Create dedicated backup user
proxmox-backup-manager user create backup-user@pbs \
    --password 'StrongPassword123!'

# Grant datastore permissions
proxmox-backup-manager acl update /datastore/vm-backups \
    --auth-id 'backup-user@pbs' \
    --role DatastoreBackup

# Generate API token (save the output — won't be shown again)
proxmox-backup-manager user generate-token backup-user@pbs cluster-token
4.4Add PBS as Cluster Storage

In Proxmox UI: Datacenter → Storage → Add → Proxmox Backup Server. Fill in PBS host IP, backup-user@pbs, the API token, datastore vm-backups, and the fingerprint from PBS Dashboard.

4.5Schedule Backups

Datacenter → Backup → Add — daily at 02:00, mode snapshot, compression zstd, target PBS.

Why PBS rules
PBS uses content-addressable deduplication and incremental forever. After the first full backup, subsequent runs are minutes — not hours — and use a fraction of the storage.
PHASE 5 Ceph Distributed Storage

Ceph provides the replicated block storage (RBD) that makes true VM HA possible. With replication factor 3, every VM disk is written simultaneously to all three nodes — if any node fails, the VM restarts on a survivor with its local copy.

Dedicated OSD disk
The sdb disk on each node is used exclusively for Ceph OSD. It must be completely empty — no partitions, no filesystem, no LVM signature.
5.1Wipe sdb on All Nodes
bash · run on EACH node
# Verify sdb is the correct disk — CHECK CAREFULLY
lsblk

# Wipe all signatures, partitions, filesystem headers
wipefs -af /dev/sdb
sgdisk --zap-all /dev/sdb

# Zero the first 100MB to clear any LVM/RAID metadata
dd if=/dev/zero of=/dev/sdb bs=1M count=100 status=progress

# Confirm disk is clean
lsblk /dev/sdb
# Expected: sdb  [no children, no filesystem]
5.2Install Ceph on All Nodes

Via Web UI on each node: Node → Ceph → Install Ceph → choose Reef (latest stable) → Start Installation.

bash · CLI alternative on each node
pveceph install --repository no-subscription
ceph --version
5.3Initialize Ceph on pve01
bash · on pve01
pveceph init --network 192.168.10.0/24

# The network here defines where Ceph public traffic goes.
# For a dedicated Ceph network, use your storage network instead.
5.4Create Monitors on All Nodes

Monitors maintain the cluster map and quorum — you need at least 3 for fault tolerance.

bash · run on each node
pveceph mon create     # on pve01, pve02, and pve03

# Verify
ceph mon stat
# Expected: e3: 3 mons at {...}, quorum 0,1,2
5.5Create Managers on All Nodes
bash
pveceph mgr create     # on each node
ceph mgr stat
5.6Create OSD on Each Node

One OSD per node, using the dedicated sdb disk.

bash
pveceph osd create /dev/sdb     # on each node

# Verify all 3 OSDs are up and in
ceph osd stat
# Expected: 3 osds: 3 up, 3 in

ceph health
# Expected: HEALTH_OK

ceph status
5.7Create the VM-Disk Pool
Datacenter → Ceph → Pools → Create:
  • Name: VM-Disk
  • Size / Replicas: 3 (one copy per node)
  • Min. Size: 2 (pool accepts writes if 2/3 OSDs are up)
  • PG Autoscale: on
  • Add as Storage: ✓ (creates the Proxmox storage target automatically)
bash · CLI alternative
pveceph pool create VM-Disk --size 3 --min_size 2 --pg_autoscale_mode on
pvesm add rbd VM-Disk --pool VM-Disk --content images --krbd 0

ceph osd pool ls
ceph osd pool stats VM-Disk
5.8Full Ceph Health Check
bash
ceph health detail
ceph status

# Expected:
#   cluster:   HEALTH_OK
#   services:  mon: 3 daemons, quorum pve01,pve02,pve03
#              mgr: pve01(active), pve02, pve03
#              osd: 3 osds: 3 up, 3 in
#   data:      pools: 1 pools, N pgs · pgs: N active+clean
  Healthy when HEALTH_OK and all 3 OSDs are up & in. Investigate any HEALTH_WARN before creating HA VMs.
PHASE 6 Proxmox Datacenter Manager (PDM)

PDM provides a unified single-pane-of-glass over multiple Proxmox clusters, PBS instances, and remote sites. It doesn't replace the per-cluster UI — it sits above it.

6.1Install PDM on a Dedicated Host
bash · on PDM host
echo 'deb http://download.proxmox.com/debian/pdm bookworm pdm-no-subscription' \
    > /etc/apt/sources.list.d/pdm.list

wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg \
    -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg

apt update && apt install -y proxmox-datacenter-manager
systemctl enable --now proxmox-datacenter-manager
systemctl status proxmox-datacenter-manager
6.2Access PDM Web Interface

PDM listens on port 8443: https://<pdm-host>:8443 — default user admin@pdc.

6.3Add the Proxmox Cluster to PDM
Remote → Add → Proxmox VE Cluster:
  • ID / Name: proxmox-ha-cluster
  • Host: 192.168.10.11 (pve01 management IP)
  • Port: 8006
  • Username: root@pam

PDM connects to pve01 and enumerates all cluster nodes automatically.

6.4Add PBS to PDM

Remote → Add → Proxmox Backup Server — once added, PDM displays backup status across the entire datacenter in a single view.

6.5PDM Capabilities
FeatureDescription
Cluster OverviewDashboard of all nodes, VMs, and health across every cluster
Cross-Cluster MigrationMigrate VMs between different Proxmox clusters
Backup StatusUnified view of all backup jobs and last status across all nodes
Resource UsageAggregate CPU, memory, storage usage across the entire datacenter
Remote ManagementManage multiple Proxmox clusters from one interface
PHASE 7 High Availability Configuration

With cluster + Ceph running, HA can now be configured. Proxmox HA monitors VMs and restarts them on a surviving node within seconds of host failure. Only VMs on shared storage (the Ceph VM-Disk pool) can be HA-protected.

7.1HA Architecture
ComponentRole
CRM (Cluster Resource Manager)Decides where resources run and coordinates failover decisions
LRM (Local Resource Manager)Runs on each node, executes start/stop/migrate commands locally
7.2Verify HA Services
bash
systemctl status pve-ha-crm
systemctl status pve-ha-lrm
ha-manager status
7.3Create an HA Group

HA Groups define which nodes a VM can run on, and the failover priority.

Datacenter → HA → Groups → Add:
  • ID: production-ha
  • Nodes: pve01:3, pve02:2, pve03:1 (priority:score)
  • Restricted: No · No Failback: No

Higher score = preferred host. pve01 is primary; pve02 the natural failover target; pve03 is last resort.

7.4Add VMs to HA
⚠ Shared storage required: Only VMs with disks on the Ceph VM-Disk pool can be HA-protected. Adding a VM on local-lvm to HA will fail.
Datacenter → HA → Resources → Add:
  • VM ID: 100
  • Group: production-ha
  • State: started
  • Max Restart: 3 · Max Relocate: 3
bash · CLI alternative
ha-manager add vm:100 --group production-ha --state started
ha-manager status
ha-manager resources
7.5HA Resource States
StateMeaning
startedVM should be running — HA keeps it running on any available node
stoppedVM should be stopped — HA won't start it automatically
disabledHA management temporarily disabled for this VM
ignoredHA completely ignores this VM
PHASE 8 Testing & Validation

Before declaring the cluster production-ready, every subsystem is validated through controlled testing.

8.1Cluster Health
bash
pvecm status
pvecm nodes
corosync-cfgtool -s

# Expected ring output (Link ID 0 udp):
#   nodeid: 2:  connected
#   nodeid: 3:  connected
8.2Ceph Benchmark
bash
ceph status
ceph osd tree
ceph osd pool stats VM-Disk

# I/O benchmarks
rados bench -p VM-Disk 10 write --no-cleanup
rados bench -p VM-Disk 10 seq
rados bench -p VM-Disk 10 rand

# Clean up
rados -p VM-Disk cleanup
8.3Live Migration Test
bash
# Start a test VM on pve01 (VM ID 100 on the VM-Disk pool)
qm start 100

# Live migrate to pve02
qm migrate 100 pve02 --online 1
qm status 100

# Migrate back
qm migrate 100 pve01 --online 1
8.4HA Failover Test — Node Failure Simulation
⚠ Maintenance window only. The test node will reboot abruptly. Don't run this against a production workload.
bash
# 1. Ensure test VM 100 is running on pve01
ha-manager status

# 2. Monitor HA events from pve02
journalctl -u pve-ha-crm -f

# 3. Simulate failure (hard poweroff)
# Press the power button, or via IPMI:
#   ipmitool chassis power off
# OR less destructive — isolate Corosync only:
iptables -A INPUT  -p udp --dport 5405 -j DROP
iptables -A OUTPUT -p udp --dport 5405 -j DROP

# 4. Within ~60 seconds: pve01 is detected down; VM 100 restarts on pve02 or pve03

# 5. Verify on surviving node
qm status 100

# 6. Restore pve01 and verify rejoin
pvecm status

# Remove iptables rules if used
iptables -D INPUT  -p udp --dport 5405 -j DROP
iptables -D OUTPUT -p udp --dport 5405 -j DROP
8.5PBS Backup & Restore Test
bash
# Trigger manual backup of VM 100 to PBS
vzdump 100 --storage PBS --mode snapshot --compress zstd

# List backups
proxmox-backup-client list

# Restore from PBS to a different VM ID (non-destructive)
qmrestore PBS:backup/vzdump-qemu-100-<timestamp>.vma.zst 999 \
    --storage VM-Disk

# Verify
qm start 999
qm status 999

# Clean up
qm destroy 999
8.6Post-Validation Checklist
pvecm status — 3 nodes, quorate, all votes present
ceph status — HEALTH_OK, 3 OSDs up and in
VM-Disk pool accessible as storage from all 3 nodes
Live migration completes in under 60 seconds for a 4 GB RAM VM
HA failover completes within 90 seconds of node isolation
VM resumes correctly after HA restart — no data corruption
PBS backup completes without errors
VM restored from PBS backup boots and operates correctly
PDM shows all nodes, VMs, and backup status
Bond traffic confirmed using iperf3 across migration network
09 Troubleshooting Reference
Cluster Issues
Error: "This host already contains virtual guests"

Cause: the node being joined has existing VMs/containers.

bash
qm list
pct list
ls /etc/pve/qemu-server/
ls /etc/pve/lxc/

# Backup configs
mkdir -p /root/vm-config-backup
cp /etc/pve/qemu-server/*.conf /root/vm-config-backup/ 2>/dev/null
cp /etc/pve/lxc/*.conf /root/vm-config-backup/ 2>/dev/null

# Remove to allow join
rm -f /etc/pve/qemu-server/*.conf
rm -f /etc/pve/lxc/*.conf

# Retry join, then restore configs
cp /root/vm-config-backup/*.conf /etc/pve/qemu-server/
Cluster Not Quorate After Node Failure
bash · EMERGENCY USE ONLY
# Temporarily allow cluster operation with 1 node (split-brain risk)
pvecm expected 1
corosync-quorumtool -s
Corosync Ring Down
bash
corosync-cfgtool -s
systemctl restart corosync       # caution in production
journalctl -u corosync -n 100
Ceph Issues
HEALTH_WARN: pgs degraded
bash
ceph health detail
ceph pg stat
ceph osd tree | grep -i down
systemctl status ceph-osd@<OSD_ID>
systemctl start ceph-osd@<OSD_ID>
OSD Disk Full Warning
bash
ceph df
ceph osd df

# Emergency only — temporarily raise full ratio
ceph osd set-nearfull-ratio 0.90
ceph osd set-full-ratio 0.95
HA & Migration Issues
VM Not Failing Over
bash
ha-manager status
journalctl -u pve-ha-crm -n 50
journalctl -u pve-ha-lrm -n 50

# CRITICAL: verify VM disk is on shared Ceph storage
qm config <VMID> | grep scsi
# Must show VM-Disk: prefix, NOT local-lvm:
Live Migration is Slow
bash
# Check bond status — all 4 slaves should be active
cat /proc/net/bonding/bond0

# Test migration bandwidth with iperf3
# On pve02 (receiver)
iperf3 -s -B 192.168.30.12

# On pve01 (sender)
iperf3 -c 192.168.30.12 -P 4 -t 30

# Confirm migration is using the right network
cat /etc/pve/datacenter.cfg | grep migration
10 Appendix
A. Key Configuration File Locations
File / PathPurpose
/etc/pve/corosync.confCorosync cluster config — ring addresses, quorum
/etc/network/interfacesNetwork interface config including bond and bridges
/etc/pve/datacenter.cfgDatacenter-wide settings including migration network
/etc/pve/ha/resources.cfgHA resource definitions (VMs registered for HA)
/etc/pve/ha/groups.cfgHA group definitions and node priorities
/etc/pve/qemu-server/<ID>.confIndividual VM configuration files
/etc/pve/storage.cfgStorage definitions (PBS, Ceph, local-lvm)
/etc/ceph/ceph.confCeph cluster configuration
B. Essential Commands Reference
CommandDescription
pvecm statusShow cluster status, quorum, and node list
pvecm nodesList all nodes in the cluster
ha-manager statusShow HA resource status and which node each runs on
ha-manager resourcesList all registered HA resources
ceph statusFull Ceph cluster health and statistics
ceph osd treeOSD topology and status
qm listList all VMs on the current node
qm migrate <ID> <NODE> --online 1Live migrate VM to another node
pct listList all LXC containers on the current node
pvesm statusShow status of all configured storage
C. Glossary
TermDefinition
CorosyncOpen-source cluster messaging layer used by Proxmox for heartbeat and quorum
QuorumMinimum votes for the cluster to operate — with 3 nodes, quorum requires 2
CephDistributed storage system providing replicated block (RBD), object, and file storage
OSDObject Storage Daemon — the Ceph process that manages a single disk
RBDRADOS Block Device — Ceph block storage format used for VM disks
LACPLink Aggregation Control Protocol (IEEE 802.3ad) — bonds NICs for bandwidth + redundancy
CRMCluster Resource Manager — decides where HA VMs run
LRMLocal Resource Manager — runs on each node, executes HA commands locally
PBSProxmox Backup Server — dedicated backup solution for Proxmox VE
PDMProxmox Datacenter Manager — multi-cluster management interface
You Have Production HA

You now have a production-ready Proxmox VE High Availability cluster: three nodes sharing replicated Ceph storage, LACP-bonded live migration, centralized PBS backups, and PDM oversight — with verified automatic failover under simulated node loss. Bump component versions periodically and re-run Phase 8 validation to keep the cluster healthy.

Related Documentation
Proxmox VE HA Cluster Implementation Guide  ·  Corosync · Ceph · PBS · PDM · LACP