corosync update reboot

[Ashley]

Recently been trying out HA in Proxmox, just run an apt-get dist-upgrade on one node, this had an update for corosync causing the node to be fenced (rebooted).

1/ I have done some searching on the forum and have found a reply stating to stop two services on the node in question before updating (I guess just starting these two services after is then fine)

2/ Is there any plans to add something into the GUI to put a node into maintenance (or even something automatically during the apt-get dist-upgrade process) ?

3/ Is there any other / better method currently when doing upgrades that may contain an update for corosync?

Thanks

 

[robhost]

You could migrate VMs managed by HA to another node and then do the upgrade. Then no reboot will be applied.

Your 2) is a good point imho, would be nice to have kind of a maintenance mode in the GUI which disabled HA.

 

[fireon]

You could migrate VMs managed by HA to another node and then do the upgrade. Then no reboot will be applied.
Your 2) is a good point imho, would be nice to have kind of a maintenance mode in the GUI which disabled HA.

Do this here by set the "nofailback option" on the concerned HA-Groups.

 

[Ashley]

Do this here by set the "nofailback option" on the concerned HA-Groups.

I understood this was still a VM moving to another node, but this will also stop a node from powering off if corosync does not respond?

I know they may sound the same just wanted to make sure!

 

[robhost]

Do this here by set the "nofailback option" on the concerned HA-Groups.

We've always set "nofailback", but this still triggers fencing when updating a node with active HA resources afaik.

 

[fireon]

I understood this was still a VM moving to another node, but this will also stop a node from powering off if corosync does not respond?

Hmm, ok, if it corosync not responding i think this is another problem, never had this before, not turning an update. A test in laboratory will be interesting.

Maybe some a Staff Member can help us to give an answer to this question.

 

[fireon]

active HA resources afaik

You mean with VM's existing on this node? Or without VM's too?

 

[robhost]

You mean with VM's existing on this node? Or without VM's too?

With active VMs "managed by HA".

 

[fireon]

With active VMs "managed by HA".

Ok, i never did this in this way. On every maintenance i migrate all VM's to an other node. Then i do the update.

 

[robhost]

Thats the best solution, indeed. But we have some clusters with mixed "HA" and "non HA" VMs where it's not possible to migrate all VMs due to the lack of free RAM on the other node(s)

So we only do migrate the HA VMs before upgrading the PVE packages, which works just fine.

 

[Ashley]

Ok, i never did this in this way. On every maintenance i migrate all VM's to an other node. Then i do the update.

Fully understand about maintenance, and yes if I am doing anything more than a "apt-get dist-upgrade" then I would remove all VM's, but when applying updates that have no requirement for a reboot of the node so can be done live, if their is an update for the corosync package, this obviously causes the service to get restarted, causing the node to be fenced and rebooted.

 

[fireon]

Fully understand about maintenance, and yes if I am doing anything more than a "apt-get dist-upgrade" then I would remove all VM's, but when applying updates that have no requirement for a reboot of the node so can be done live, if their is an update for the corosync package, this obviously causes the service to get restarted, causing the node to be fenced and rebooted.

Yes! I'am agree with. Should work... hmm

 

[fireon]

Was a bug/feature:

corosync-pve (2.4.2-2~pve4+1) unstable; urgency=medium
  * also restart when switching from old to new upgrade behaviour
 -- Proxmox Support Team <support@proxmox.com>  Wed, 8 Mar 2017 11:25:48 +0100
corosync-pve (2.4.2-2~pve4) unstable; urgency=medium
  * restart corosync.service on upgrades instead of stop-wait-start
 -- Proxmox Support Team <support@proxmox.com>  Tue, 7 Mar 2017 15:22:47 +0100