Corosync in Proxmox: What It Is and Why It’s Essential for a Cluster

Corosync is one of the components that let multiple Proxmox VE servers work together as a coordinated cluster. Its job isn’t to run virtual machines or store their disks, but to maintain communication between nodes, manage membership, and provide the information needed to determine whether quorum exists. It’s a largely invisible piece during normal operation, but a decisive one when a server or a network connection fails.

The key points about Corosync in Proxmox, in 20 seconds

• Corosync keeps the nodes that make up a Proxmox cluster coordinated with each other.
• Membership determines which servers are still part of the cluster, and quorum establishes whether there’s a sufficient majority.
• Proxmox uses Corosync alongside pmxcfs, Kronosnet, and its high-availability system.
• Its timers help detect failures and reorganize membership.
• A stable, redundant, low-latency network matters more than having a lot of bandwidth.

When a cluster is created with pvecm, Proxmox sets up this communication infrastructure without the administrator having to deal directly with all of its components. That’s why it’s possible to run Proxmox for years without digging too deep into Corosync.

Understanding it is useful because concepts like cluster, quorum, Corosync, fencing, watchdog, QDevice, HA, and Ceph are related but solve different problems. Mixing them up can lead to treating an infrastructure as highly available when it’s really just several servers grouped together.

What Corosync Is and What It Does Inside Proxmox

Corosync is a cluster communication engine used by various high-availability projects on Linux. Proxmox VE uses it as part of its clustering architecture so that servers can maintain a consistent view of who belongs to the cluster.

An installation might consist of, for example:

• PVE01
• PVE02
• PVE03

All three servers need to know they belong to the same cluster and keep up-to-date information about each other’s presence.

If PVE03 stops responding, simply marking it as disconnected isn’t enough. PVE01 and PVE02 need to agree on a new membership in which PVE03 no longer takes part.

That’s where one of Corosync’s main functions comes in.

Membership

Membership describes which nodes are part of the cluster at any given moment.

It can change because a server shuts down, reboots, loses connectivity, or rejoins the cluster.

This concept matters because a server that appears to have vanished could still be running, just isolated by a network problem.

Quorum

The second concept is quorum.

Proxmox uses a vote-based model to determine whether part of the cluster has enough authority to keep operating.

In a basic three-node example:

If PVE03 disappears, two votes out of three remain. That’s a majority, so quorum holds.

If PVE01 becomes completely isolated from the other two, it holds only one vote. It has no way of knowing whether PVE02 and PVE03 are actually down or simply still running on the other side of a network outage.

Quorum helps prevent both sides from acting on the same resources at the same time.

This is one of the safeguards against split brain, a situation that’s especially dangerous in distributed systems because different groups of servers can each believe they’re the valid part of the cluster.

That’s why Proxmox is so often discussed in terms of three nodes. It’s not that three servers virtualize better than two. Three votes let you keep a majority of two after losing one member.

Corosync, Kronosnet, pmxcfs, and QDevice: How the Pieces Fit Together

Corosync doesn’t work in isolation. Several components surround it, and it’s worth telling them apart.

Separating these functions helps clarify what happens when something fails.

Kronosnet: The Transport Layer

Current versions of Corosync use Kronosnet, usually called knet, as their transport layer.

It’s the part responsible for carrying communications between members, and it allows multiple links between nodes.

That has a practical consequence: a cluster can have redundancy for Corosync’s communications.

But that redundancy has to actually exist in the infrastructure.

Two links configured on different VLANs that still run through the same NIC, switch, or physical path can still share a single point of failure.

pmxcfs: Proxmox’s Distributed Configuration

Proxmox adds another important component: the Proxmox Cluster File System (pmxcfs).

It’s the filesystem mounted at /etc/pve, and it distributes the cluster’s configuration across its nodes.

That’s where you’ll find configuration for virtual machines, storage, users, and other Proxmox elements.

pmxcfs uses the information Corosync provides to keep the cluster consistent. When a node loses quorum, this system’s behavior changes specifically to prevent potentially conflicting changes.

That’s why an administrator can find /etc/pve in read-only mode after losing quorum. It isn’t simply a filesystem permissions issue.

pvecm: The Tool Administrators See

Proxmox provides pvecm as the cluster’s administration interface.

One of the basic commands is:

pvecm status

It lets you check information such as the number of nodes, votes, quorum, and overall status.

Also useful:

pvecm nodes

The Corosync configuration Proxmox uses can be found at:

/etc/pve/corosync.conf

This file is part of the cluster’s critical configuration and shouldn’t be edited without understanding the consequences.

QDevice, and Why It Shows Up in Two-Node Clusters

A two-node cluster raises an obvious problem.

If each server holds one vote and communication between them is lost, neither one can be sure whether the other is down or simply isolated.

One solution Proxmox offers for certain small clusters is adding a QDevice, typically backed by an external QNetd.

Think of it as adding an external vote to the quorum process.

That third element doesn’t need to be another Proxmox server capable of running virtual machines.

This allows for architectures such as:

The distinction matters: a QDevice helps with quorum, but it doesn’t add recovery capacity.

If PVE01 fails, PVE02 can retain the conditions it needs to keep operating thanks to the quorum mechanism, but every VM that needs to be recovered will have to fit on PVE02.

A third vote doesn’t provide RAM, CPU, or storage.

Token and Consensus: How Corosync Knows Something Has Changed

To keep the cluster coordinated, Corosync relies on several timers. Two of the best known are token and consensus.

token is part of the mechanism used to detect problems as the token circulates among members.

consensus comes into play while a new membership is being established.

These parameters explain why a server dropping out doesn’t trigger an instant reaction. In a distributed system, reacting too fast can be just as dangerous.

A single lost packet or a few milliseconds of congestion shouldn’t get a perfectly healthy server declared dead.

That’s why these timers exist.

It also explains why indiscriminately lowering Corosync’s values to chase a faster failover can backfire: an unstable network can trigger false detections and unnecessary membership changes.

Cluster size matters too. Corosync has a token_coefficient setting that increases the effective timeout as the number of nodes grows.

This parameter has drawn extra attention recently because Proxmox VE 9.2 uses an explicit coefficient of 125 ms when creating new clusters, compared with the historical default behavior associated with 650 ms when it isn’t set explicitly.

The change is most noticeable in large clusters, though an installation upgraded from earlier versions may keep its existing configuration. That’s why it’s more reliable to check the effective values directly than to infer them from the installed version.

You can do that with:

corosync-cmapctl | grep -Ew 'runtime.config.totem.token|runtime.config.totem.consensus'

These timers are worth reviewing in large infrastructures, but Corosync is much more than token and consensus. Focusing only on those numbers can obscure its main job: keeping a consistent view of the cluster.

How Corosync Relates to Proxmox HA

Corosync isn’t Proxmox’s high-availability system either.

It supplies part of the information HA needs to work.

When a virtual machine is set up as an HA resource, Proxmox HA Manager tracks where it should be running and can react to certain failures.

If a host disappears abruptly, the conceptual process runs through several stages:

1. The node or its connectivity is lost.
2. Corosync detects the change.
3. The surviving members establish a new membership.
4. Quorum is determined.
5. Fencing mechanisms make sure the problem node can’t cause conflicts.
6. HA Manager can recover the protected resources on other servers.

This explains why HA isn’t the same thing as live migration.

In a live migration, the source server keeps running and actively takes part in moving the virtual machine.

During an abrupt failure, the original host may be completely gone. The VM has to be recovered on another node and booted back up.

Watchdog and Fencing

Proxmox uses a watchdog as part of its HA architecture.

If a node loses quorum and can no longer properly service the watchdog, the watchdog can end up forcing a reboot. Proxmox documents roughly 60 seconds for this self-fencing mechanism.

The logic is conservative.

Before letting another server recover certain resources, it’s important to make sure the isolated node isn’t still using them.

Fencing exists specifically to prevent two hosts from acting as owners of the same resource at the same time.

This also explains the relationship between Corosync’s timers and the watchdog. Proxmox recommends leaving enough margin for a new membership to be established before the fencing limit is reached.

Corosync’s Network Deserves Its Own Design

One of Corosync’s quirks is that it doesn’t necessarily need much bandwidth, but it does need a stable, low-latency network.

That distinction matters.

A stable 1 Gbit/s interface can be perfectly adequate for some installations, while a 25 Gbit/s connection simultaneously saturated by Ceph, migrations, and backups can offer worse conditions for cluster traffic.

Proxmox’s documentation recommends paying special attention to this network, and it supports configuring multiple links through Kronosnet.

In an enterprise installation, it’s worth reviewing:

• latency between nodes;
• packet loss;
• jitter;
• interface redundancy;
• switching redundancy;
• consistent MTU;
• congestion;
• separation from heavy traffic;
• genuinely independent physical paths.

This becomes even more important when Proxmox shares infrastructure with Ceph.

Ceph can generate large volumes of traffic during recovery, rebalancing, or backfill. An incident can be exactly the moment when Corosync needs to communicate the most and, at the same time, storage is generating the most traffic.

Designing both networks without accounting for that degraded scenario is a potential source of problems.

Corosync Is Not Ceph

Having both components present in many Proxmox installations can cause another kind of confusion.

Corosync keeps the Proxmox cluster coordinated.

Ceph provides distributed storage.

An installation can use Corosync without Ceph. A Proxmox cluster, for example, can rely on shared storage over NFS, iSCSI, Fibre Channel, or other architectures.

It can also use Ceph, but then you have two separate distributed systems, each with its own mechanisms, networks, and timers.

Corosync having quorum doesn’t automatically mean Ceph is healthy. And Ceph keeping enough replicas doesn’t mean Proxmox retains quorum either.

What a Proxmox Administrator Should Know About Corosync

You don’t need to memorize every parameter in corosync.conf to run a Proxmox infrastructure correctly.

But it does help to have clear answers to a few questions.

That last question falls outside Corosync’s scope, but it’s probably one of the most important.

A cluster can have perfect quorum, a perfectly configured Corosync, and a fully redundant network, and still fail to deliver useful HA if the surviving nodes don’t have the CPU and RAM to recover the VMs from the lost server.

Backup isn’t part of Corosync either.

High availability aims to reduce the disruption caused by certain infrastructure failures. Backups let you recover data after corruption, ransomware, accidental deletion, and other, different scenarios.

Understanding these boundaries helps put Corosync in its proper place. It’s the layer that lets Proxmox’s members maintain a shared view of who’s still in the cluster and who gets to make decisions.

It usually stays quiet in the background. That’s exactly why it’s worth understanding before the day one of your servers stops responding.

Frequently Asked Questions

What Is Corosync in Proxmox?

Corosync is the system Proxmox VE uses to provide communication, membership, and quorum-related services among a cluster’s nodes. It keeps a consistent view of which servers are still part of the infrastructure.

Can Proxmox Run Without Corosync?

A standalone Proxmox VE server doesn’t need to form a cluster. When multiple nodes are joined through Proxmox’s clustering features, Corosync becomes part of that architecture.

Does Corosync Provide High Availability?

Not on its own. Corosync provides communication, membership, and quorum. Proxmox HA Manager, the watchdog, storage, and the available capacity on each node are all part of the design needed to recover workloads automatically.

Does Corosync Need a Dedicated Network?

Proxmox recommends paying close attention to this network and keeping Corosync’s sensitive traffic from competing with heavy workloads. More than huge bandwidth, it needs low latency, stability, and properly designed redundancy.