[ClusterLabs] qdevice network redundancy

Paul B. Henson henson at acm.org
Wed Oct 1 00:09:53 UTC 2025


I recently deployed a corosync cluster for the first time in the context 
of proxmox. We only had two nodes and needed a qdevice for quorum purposes.

The nodes themselves have two fully redundant network connections; 
Different subnets for each network, physically different ports for each 
network, physically different switches for the ports.

I set up the system running the qdevice similarly, and was surprised 
that when I went to add it to the cluster it appears to only support a 
single IP address for communicating with it?

While certainly having the qdevice makes the cluster more reliable than 
not, the lack of multiple network support makes it less reliable than 
having a true third node which could provide quorum in more failure 
scenarios.

I was curious why this is the case; is there some underlying design 
reason that would prevent a qdevice from communicating over multiple 
subnets with the other cluster members? Or is it just something that has 
never been implemented? I understand the qdevice doesn't use the 
corosync protocol, but just a TCP connection. It looks like 
corosync-qnetd listens on the wildcard address and hence accepts 
connections on any interface or any IP address associated with the 
system it is running on. Is it just a matter of updating the 
corosync-qnetd plug-in to accept multiple IP addresses and failover 
between them while communicating?

Thanks…


More information about the Users mailing list