{"id":28011,"date":"2026-02-14T08:00:00","date_gmt":"2026-02-14T07:00:00","guid":{"rendered":"https:\/\/www.credativ.de\/blog\/credativ-inside\/proxmox-cluster-network-properly-configure-corosync\/"},"modified":"2026-02-14T08:00:00","modified_gmt":"2026-02-14T07:00:00","slug":"proxmox-cluster-network-properly-configure-corosync","status":"publish","type":"post","link":"https:\/\/www.credativ.de\/en\/blog\/credativ-inside\/proxmox-cluster-network-properly-configure-corosync\/","title":{"rendered":"Proxmox Cluster Network: Properly Configure Corosync"},"content":{"rendered":"

A stable Proxmox\u00ae cluster requires precise Corosync configuration for reliable cluster communication. This guide shows you how to optimally set up your Proxmox\u00ae cluster network and correctly configure Corosync. The usual process for system administrators with basic Proxmox\u00ae VE knowledge is correctly set up by the automatic installer or in the Proxmox VE frontend, requiring no manual work. <\/p>\n

We explicitly advise against working on the configuration without deep knowledge of Corosync’s intricacies and the consequences of custom settings. This should be left to specialists with expertise. However, this overview may be helpful for experimentation and further education. <\/p>\n

You need at least two Proxmox\u00ae nodes and a Q-Device, or three Proxmox nodes, administrative access to all cluster nodes, redundant network connections, and basic Linux\u00ae command-line knowledge. After successful configuration, you will have a highly available Proxmox\u00ae cluster with optimal failover functionality. <\/p>\n

Why Corosync is Critical for Proxmox\u00ae Clusters<\/h2>\n

Corosync forms the core of cluster communication in Proxmox\u00ae VE environments. This software ensures that all nodes in the cluster continuously communicate with each other and are aware of the current status of the entire infrastructure. <\/p>\n

Split-brain prevention<\/strong> is one of Corosync’s most important functions. Without functioning cluster communication, individual nodes could mistakenly assume they are the only active systems. This leads to data inconsistencies and failures of critical services. In the worst case, data loss is imminent. <\/p>\n

Corosync continuously monitors the accessibility of all cluster members. In the event of network problems or node failures, the system initiates automatic failover processes. Virtual machines and containers are seamlessly migrated to functioning nodes. <\/p>\n

The reliability of your entire Proxmox\u00ae cluster directly depends on the Corosync configuration. Incorrect settings can lead to unstable clusters, unpredictable failovers, or complete system failures.<\/strong><\/p>\n

Check Proxmox\u00ae Cluster Network Requirements<\/h2>\n

First, check your hardware requirements for stable cluster communication. Each node requires at least two physical network interfaces for redundant connections. <\/p>\n

Validate network infrastructure:<\/strong><\/p>\n

    \n
  1. Test latency between all nodes using the ping<\/code> command.<\/li>\n
  2. Check available bandwidth with iperf3<\/code>.<\/li>\n
  3. Verify switch configurations for VLAN settings.<\/li>\n
  4. Document all IP addresses for cluster communication.<\/li>\n<\/ol>\n

    IP addressing must be carefully planned. Use separate subnets for primary and secondary Corosync communication, for example, 10.1.1.0\/24 for Ring 0 and 10.1.2.0\/24 for Ring 1. <\/p>\n

    Bandwidth requirements vary depending on cluster size. For small clusters with 3\u20135 nodes, 100 Mbit\/s per ring is sufficient. Larger installations with frequent VM migrations require Gigabit connections. <\/p>\n

    Warning:<\/strong> Never use the same network segments for Corosync and productive VM communication. This can lead to performance problems and cluster instability. Corosync should always have its own network segment and interfaces. <\/p>\n

    Set Up Corosync Ring Configuration<\/h2>\n

    The Corosync rings are configured via the file \/etc\/pve\/corosync.conf<\/code>. Normally, this file is created and maintained by the frontend or the installer. As already mentioned, manual editing is not necessary. First, create a backup copy of the existing configuration. <\/p>\n

    Configure Primary Ring (Ring 0):<\/strong><\/p>\n

      \n
    1. Open the Corosync configuration: vi \/etc\/pve\/corosync.conf<\/code><\/li>\n
    2. Define the nodelist with all cluster members.<\/li>\n
    3. Assign a unique ID to each node.<\/li>\n
    4. Configure the IP addresses for Ring 0.<\/li>\n<\/ol>\n

      Add a secondary ring (Ring 1) for redundancy. Edit the nodelist and add ring1_addr<\/code> parameters for each node. These addresses must be in a separate network segment. <\/p>\n

      The Totem section controls the behavior of cluster communication. Adjust the token timeout values to your network latency. Low values improve failover speed but can lead to false alarms with slow connections. <\/p>\n

      Success Check:<\/strong> After configuration, restart the Corosync service: systemctl restart corosync<\/code>. Check the status with corosync-cmapctl<\/code> and review the logs for error messages. <\/p>\n

      Multicast vs. Unicast: Making the Right Choice<\/h2>\n

      The choice between Multicast and Unicast used to significantly influence the performance and compatibility of your Corosync cluster. Meanwhile, with Corosync 3, KNET has become prevalent, and both UDPU as a Unicast connection and Multicast with UDP are classified as “Deprecated.” Multicast is now explicitly discouraged. <\/p>\n

      Test and Validate Cluster Communication<\/h2>\n

      Comprehensive testing of Corosync functionality is crucial for cluster stability. Start with basic connectivity checks between all nodes. <\/p>\n

      Systematically use diagnostic tools:<\/strong><\/p>\n

        \n
      1. Check cluster status: pvecm status<\/code><\/li>\n
      2. Analyze Corosync membership: corosync-quorumtool -l<\/code><\/li>\n
      3. Check ring status: corosync-cfgtool -s<\/code><\/li>\n
      4. Check cluster logs: journalctl -u corosync<\/code><\/li>\n<\/ol>\n

        Failover tests simulate real failure scenarios. Disconnect individual nodes from the network one by one and observe cluster behavior. Virtual machines should automatically migrate to functioning nodes. <\/p>\n

        Test split-brain scenarios by simultaneously disconnecting multiple nodes. The cluster must correctly decide which partition remains active. Nodes without quorum must not perform critical operations. <\/p>\n

        Performance monitoring over longer periods reveals intermittent problems. Monitor latency spikes, packet loss, and timeout events. These metrics indicate potential weaknesses in the network infrastructure. <\/p>\n

        How credativ\u00ae Helps with Proxmox\u00ae Cluster Configuration<\/h2>\n

        credativ\u00ae offers comprehensive support for the professional implementation and optimization of Proxmox\u00ae clusters. Our specialists have many years of experience with complex high-availability infrastructures. <\/p>\n

        Our Proxmox services<\/a> include:<\/strong><\/p>\n