Change or Add a Corosync Ring on a Proxmox Cluster

The setup: 2 OVH nodes, ring over the vRack

The starting architecture is a classic OVH one: two Proxmox servers interconnected by a vRack (OVH's private L2 network between servers). Corosync uses that vRack as its single ring (link 0), and ZFS replication between the two nodes runs over those same private IPs. The public interface carries no ring: it serves the VMs' traffic, not the cluster.

Two files, two readers: the basics

This is what wastes the most time. Corosync on Proxmox handles two distinct files, read by different components:

Step 1 — Edit the configuration

Edit /etc/pve/corosync.conf if you are quorate, otherwise /etc/corosync/corosync.conf locally (see degraded mode below). Principles:

• ring0_addr = primary link (the one replication will follow).
• ring1_addr = backup link.
• Declare one interface block per linknumber used (0 and 1).
• Increment config_version on every edit.

Before picking the new version, check the one actually loaded by the daemon:

corosync-cmapctl -g totem.config_version

In our case, we go from a single ring (vRack) to two rings by adding the public IP. To move replication onto the public network, we set the public IP as ring0_addr and the vRack (still alive on the other node) as backup:

For reference, here is the starting configuration (single ring over the vRack), handy to compare:

Step 2 — Restart Corosync

The live reload is finicky; we prefer a full restart which reloads the file regardless of version. Do it on both nodes:

systemctl restart corosync          # on BOTH nodes
corosync-cfgtool -s                 # LINK 0 = primary, status: connected
pvecm status                        # Quorate: Yes, without 'expected 1'

Step 3 — Refresh the pmxcfs nodelist

Essential after changing ring0_addr: otherwise PVE tools keep the old IP cached and replication keeps targeting the dead vRack.

systemctl restart pve-cluster       # on BOTH nodes
cat /etc/pve/.members               # the "ip" fields must show the new primary

Then restart the other PVE services so they reload the topology:

systemctl restart pvestatd pvedaemon pveproxy
# if HA is enabled:
systemctl restart pve-ha-lrm pve-ha-crm

Step 4 — ZFS replication switches to the public IP

If the node IPs changed, refresh the cluster SSH host keys, then force a job to validate:

pvecm updatecerts                       # refreshes the cluster ssh_known_hosts
pvesr run --id <vmid-job> --verbose     # ssh must target the new public IP

Degraded case: no quorum at all

If the primary link is dead on both sides (or the failure already dropped the quorum before you intervened),/etc/pve is read-only and cluster propagation no longer works. You must push the config by hand:

Final verification

One point of scope, because it comes up every time: a quorate cluster does not make your services highly available. Corosync protects the hypervisor — if a node dies, the VM restarts elsewhere, with an outage. For a service to survive without an outage you have to cluster the service itself, with Keepalived and Pacemaker: a floating VIP, application-level quorum and failover in seconds, sitting on top of the hypervisor's quorum.

Network / firewall prerequisites

This scenario — an OVH node suddenly losing its vRack link — is exactly the kind of incident we handle on-call for our clients. We operate Proxmox clusters hosted on OVHcloud under management : ring failover, ZFS replication, follow-up on the hardware repair with the datacenter, and the return to nominal.

Frequently asked questions

Official documentation

Related articles