[PVE-User] pve5to6 : FAIL: Corosync transport explicitly set to 'udpu' instead of implicit default!

Thomas Lamprecht t.lamprecht at proxmox.com
Fri Dec 6 07:35:07 CET 2019

On 12/6/19 7:27 AM, Lindsay Mathieson wrote:
> Thanks, that did the trick, with some sweaty moments :) cluster all updated
> to corosync 3.0 and healthy.

Great! Yeah, it's definitively slightly scary to do, but it was the
only way we found working for a upgrade way forward - i.e., avoiding
a cluster rebuild as it was necessary for the PVE 3.4 to 4.x upgrade.

Hopefully the "to 7.x" will be again a smooth-as-silk upgrade :)

> On Fri, 6 Dec 2019 at 15:51, Thomas Lamprecht <t.lamprecht at proxmox.com>
> wrote:
>> On 12/6/19 1:31 AM, Lindsay Mathieson wrote:
>>> As per the subject, I have the error : "FAIL: Corosync transport
>> explicitly set to 'udpu' instead of implicit default!"
>>> Can I ignore that for the upgrade? I had constant problems with
>> multicast, udpu is quite reliable.
>> FAILures from the checker script are (almost) *never* ignore-able. :)
>> In this case you will be glad to hear that with corosync 3, a new transport
>> technology was adoped, i.e., kronosnet. It currently is only capable of
>> unicast. The corosync internal multicast-udp and udpu stack was depreacated
>> and removed in favor of that. So having it set to udpu will fail the
>> upgrade.
>> See:
>> https://pve.proxmox.com/wiki/Upgrade_from_5.x_to_6.0#Cluster:_always_upgrade_to_Corosync_3_first
>> In your case, and a healthy cluster, I'd drop the transport while *not*
>> restarting corosync yet. That's a change which cannot be applied live, so
>> corosync will ignore it for now. Then you can continue with the upgrade
>> to corosync 3 - still on PVE 5/Stretch, see above.
>> cheers,
>> Thomas

More information about the pve-user mailing list