Build a highly available Proxmox VE cluster consisting of:

• 2 hypervisor nodes
• 1 external QDevice (quorum server)
• shared storage (e.g. NFS)

The goal is a stable cluster with quorum and failover capability.

—

• Node A (PVE)
• Node B (PVE)
• QDevice (separate system, e.g. Raspberry Pi)
• Shared Storage (NFS or equivalent)

—

• Time synchronization (NTP)
• Consistent name resolution (DNS or /etc/hosts)
• Static IP addresses (no changing SLAAC addresses for cluster communication)
• Reliable network connectivity between all systems
• SSH access between nodes and QDevice (key-based)

—

• Mount shared storage on both nodes
• Configure storage in Proxmox
• Ensure access from both nodes

—

• Create cluster on Node A
• Join Node B to the cluster

—

• Set up the QDevice system
• Install and start corosync-qnetd

—

• Add QDevice from the cluster
• Initialize certificate-based communication

—

• Move or restore VMs to shared storage
• Verify functionality

—

• Define HA groups
• Assign VMs to groups
• Configure failover behavior

—

• Node already contains VMs or old cluster state
• Solution: clean node before joining

—

• Missing packages on nodes (e.g. corosync-qdevice)
• Incomplete initial setup

—

• QDevice logs:

SSL peer cannot verify your certificate

• Cause:

• inconsistent certificates
• repeated/failed setup attempts

• Solution:

• remove QDevice
• reset certificate database
• perform clean setup

—

• NSS DB not accessible

• Cause:

• wrong ownership (root instead of service user)

• Solution:

• assign correct ownership to service user

—

• Root login via password disabled

• Key-based authentication not working

• Solution:

• deploy SSH keys correctly
• verify access

—

• Asymmetric routing

• Wrong interface selection

• Solution:

• use dedicated network for cluster
• ensure consistent routing paths

—

• Inconsistent forward/reverse resolution

• Solution:

• ensure consistent name resolution
• avoid dynamic addresses

—

• Logs show repeated disconnects

• Cause:

• certificate or network issues

—

• Use static IP addresses for cluster communication
• Use dedicated network for Corosync and migration
• Validate shared storage before cluster setup
• Run QDevice on independent infrastructure
• Perform certificate setup cleanly and only once

—

• Cluster with quorum (2 nodes + QDevice)
• HA-capable environment
• VMs can restart on surviving node after failure

—

A 2-node cluster without QDevice is not quorum-capable. QDevice is mandatory for stable operation.

—