Problem adding new node to cluster

Conacious

New Member
Sep 17, 2019
24
0
1
32
Hi every1,
I've been running a proxmox cluster with 8 nodes without a problem.
I added last node about a month ago without any problem aswell. How ever
when I try to add a new node now ( dont't know if new corosync is the problem) I get the next error.

First I get prompted with the node password, and its added to the known hosts so I have free ssh access.

problemaproxmox.png

Here is the output of the cluster status from i1.

statuspvecm.png

I hope you guys can help me! It's been 2 days with the same error...

Thanks in advance!
 
do all nodes on the cluster have the latest updates installed?
(compare the outputs of `pveversion -v`)

I hope this helps!
 
Sorry you were right, the new node I'm trying to add is running on proxmox 6.0-2. So they are incompatible with proxmox 5.4 nodes?
 
hm - this should work with the latest packages on the 5.x nodes - please post `pveversion -v` from a 5.x node
 
I don't know if this can cause any problem but we do have a redundant "ring1" net for corosync (configured as a TINC network) in case "ring0" fails. That's because we are using vSwitchs to interconnect machines and we were having issues and loosing packages. So we added a second network using TINC interconnecting all the nodes, having ring0_addr and ring1_addr defined on corosync conf.

Thanks again.
 
Just checked the code again - with the change of the corosync version the parameter names changed (from ringX to linkX) - while the code can read both corosync.conf files, the REST-API makes no effort to be compatible.
Either set the new node up with PVE 5.4 or upgrade the whole cluster to PVE 6.0

I hope this helps!
 
Yes thank you! Last question, is there any easy way to downgrade our proxmox 6.0 on a debian buster to 5.4?
 
Not really - debian's package versioning logic (sensibly) makes it quite hard to downgrade packages - and most packages have a newer version in buster than stretch.
And even if you manage to get the older versions installed in a consistent manner - the downgrade path of all maintainer-scripts are not tested too well.

PVE releases are also tied tightly to the debian-release they're based on (you cannot run PVE 6.x on stretch and PVE 5.x on buster (or at least it's not tested at all, and quite a few binary packages are compiled against the respective shared libs in the fitting debian release))

I hope that helps!