What about if you disable the <code class="literal">enable-startup-probes</code> at fencing (custom fencing  that sets it to false and fails, so the next fencing device in the topology kicks in)?<div><br><div>When the node joins , it will skip startup probes and later a systemd service or some script check if all nodes were up for at least 15-20 min and enable it back ?</div><div><br></div><div>Best Regards,</div><div>Strahil Nikolov<br> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Thu, Mar 31, 2022 at 14:02, Ulrich Windl</div><div><Ulrich.Windl@rz.uni-regensburg.de> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> >>> "Gao,Yan" <<a shape="rect" ymailto="mailto:ygao@suse.com" href="mailto:ygao@suse.com">ygao@suse.com</a>> schrieb am 31.03.2022 um 11:18 in Nachricht<br clear="none"><<a shape="rect" ymailto="mailto:67785c2f-f875-cb16-608b-77d63d9b02c4@suse.com" href="mailto:67785c2f-f875-cb16-608b-77d63d9b02c4@suse.com">67785c2f-f875-cb16-608b-77d63d9b02c4@suse.com</a>>:<br clear="none">> On 2022/3/31 9:03, Ulrich Windl wrote:<br clear="none">>> Hi!<br clear="none">>> <br clear="none">>> I just wanted to point out one thing that hit us with SLES15 SP3:<br clear="none">>> Some failed live VM migration causing node fencing resulted in a fencing <br clear="none">> loop, because of two reasons:<br clear="none">>> <br clear="none">>> 1) Pacemaker thinks that even _after_ fencing there is some migration to <br clear="none">> "clean up". Pacemaker treats the situation as if the VM is running on both <br clear="none">> nodes, thus (50% chance?) trying to stop the VM on the node that just booted <br clear="none">> after fencing. That's supid but shouldn't be fatal IF there weren't...<br clear="none">>> <br clear="none">>> 2) The stop operation of the VM (that atually isn't running) fails,<br clear="none">> <br clear="none">> AFAICT it could not connect to the hypervisor, but the logic in the RA <br clear="none">> is kind of arguable that the probe (monitor) of the VM returned "not <br clear="none">> running", but the stop right after that returned failure...<br clear="none">> <br clear="none">> OTOH, the point about pacemaker is the stop of the resource on the <br clear="none">> fenced and rejoined node is not really necessary. There has been <br clear="none">> discussions about this here and we are trying to figure out a solution <br clear="none">> for it:<br clear="none">> <br clear="none">> <a shape="rect" href="https://github.com/ClusterLabs/pacemaker/pull/2146#discussion_r828204919 " target="_blank">https://github.com/ClusterLabs/pacemaker/pull/2146#discussion_r828204919 </a><br clear="none">> <br clear="none">> For now it requires administrator's intervene if the situation happens:<br clear="none">> 1) Fix the access to hypervisor before the fenced node rejoins.<br clear="none"><br clear="none">Thanks for the explanation!<br clear="none"><br clear="none">Unfortunately this can be tricky if libvirtd is involved (as it is here):<br clear="none">libvird uses locking (virtlockd), which in turn needs a cluster-wird filesystem for locks across the nodes.<br clear="none">When that filesystem is provided by the cluster, it's hard to delay node joining until filesystem,  virtlockd and libvirtd are running.<br clear="none"><br clear="none">(The issue had been discussed before: It does not make sense to run some probes when those probes need other resources to detect the status.<br clear="none">With just a Boolean status return at best all those probes could say "not running". Ideally a third status like "please try again some later time"<br clear="none">would be needed, or probes should follow the dependencies of their resources (which may open another can of worms).<br clear="none"><br clear="none">Regards,<div class="yqt2628282069" id="yqtfd87421"><br clear="none">Ulrich<br clear="none"><br clear="none"><br clear="none">> 2) Manually cleanup the resource, which tells pacemaker it can safely <br clear="none">> forget the historical migrate_to failure.<br clear="none">> <br clear="none">> Regards,<br clear="none">>    Yan<br clear="none">> <br clear="none">>> causing a node fence. So the loop is complete.<br clear="none">>> <br clear="none">>> Some details (many unrelated messages left out):<br clear="none">>> <br clear="none">>> Mar 30 16:06:14 h16 libvirtd[13637]: internal error: libxenlight failed to <br clear="none">> restore domain 'v15'<br clear="none">>> <br clear="none">>> Mar 30 16:06:15 h19 pacemaker-schedulerd[7350]:  warning: Unexpected result <br clear="none">> (error: v15: live migration to h16 failed: 1) was recorded for migrate_to of <br clear="none">> prm_xen_v15 on h18 at Mar 30 16:06:13 2022<br clear="none">>> <br clear="none">>> Mar 30 16:13:37 h19 pacemaker-schedulerd[7350]:  warning: Unexpected result <br clear="none">> (OCF_TIMEOUT) was recorded for stop of prm_libvirtd:0 on h18 at Mar 30 <br clear="none">> 16:13:36 2022<br clear="none">>> Mar 30 16:13:37 h19 pacemaker-schedulerd[7350]:  warning: Unexpected result <br clear="none">> (OCF_TIMEOUT) was recorded for stop of prm_libvirtd:0 on h18 at Mar 30 <br clear="none">> 16:13:36 2022<br clear="none">>> Mar 30 16:13:37 h19 pacemaker-schedulerd[7350]:  warning: Cluster node h18 <br clear="none">> will be fenced: prm_libvirtd:0 failed there<br clear="none">>> <br clear="none">>> Mar 30 16:19:00 h19 pacemaker-schedulerd[7350]:  warning: Unexpected result <br clear="none">> (error: v15: live migration to h18 failed: 1) was recorded for migrate_to of <br clear="none">> prm_xen_v15 on h16 at Mar 29 23:58:40 2022<br clear="none">>> Mar 30 16:19:00 h19 pacemaker-schedulerd[7350]:  error: Resource prm_xen_v15 <br clear="none">> is active on 2 nodes (attempting recovery)<br clear="none">>> <br clear="none">>> Mar 30 16:19:00 h19 pacemaker-schedulerd[7350]:  notice:  * Restart    <br clear="none">> prm_xen_v15              (             h18 )<br clear="none">>> <br clear="none">>> Mar 30 16:19:04 h18 VirtualDomain(prm_xen_v15)[8768]: INFO: Virtual domain <br clear="none">> v15 currently has no state, retrying.<br clear="none">>> Mar 30 16:19:05 h18 VirtualDomain(prm_xen_v15)[8787]: INFO: Virtual domain <br clear="none">> v15 currently has no state, retrying.<br clear="none">>> Mar 30 16:19:07 h18 VirtualDomain(prm_xen_v15)[8822]: ERROR: Virtual domain <br clear="none">> v15 has no state during stop operation, bailing out.<br clear="none">>> Mar 30 16:19:07 h18 VirtualDomain(prm_xen_v15)[8836]: INFO: Issuing forced <br clear="none">> shutdown (destroy) request for domain v15.<br clear="none">>> Mar 30 16:19:07 h18 VirtualDomain(prm_xen_v15)[8860]: ERROR: forced stop <br clear="none">> failed<br clear="none">>> <br clear="none">>> Mar 30 16:19:07 h19 pacemaker-controld[7351]:  notice: Transition 124 action <br clear="none">> 115 (prm_xen_v15_stop_0 on h18): expected 'ok' but got 'error'<br clear="none">>> <br clear="none">>> Note: Our cluster nodes start pacemaker during boot. Yesterday I was there <br clear="none">> when the problem happened. But as we had another boot loop some time ago I <br clear="none">> wrote a systemd service that counts boots, and if too many happen within a <br clear="none">> short time, pacemaker will be disabled on that node. As it it set now, the <br clear="none">> counter is reset if the node is up for at least 15 minutes; if it fails more <br clear="none">> than 4 times to do so, pacemaker will be disabled. If someone wants to try <br clear="none">> that or give feedback, drop me a line, so I could provide the RPM <br clear="none">> (boot-loop-handler-0.0.5-0.0.noarch)...<br clear="none">>> <br clear="none">>> Regards,<br clear="none">>> Ulrich<br clear="none">>> <br clear="none">>> <br clear="none">>> <br clear="none">>> _______________________________________________<br clear="none">>> Manage your subscription:<br clear="none">>> <a shape="rect" href="https://lists.clusterlabs.org/mailman/listinfo/users " target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users </a><br clear="none">>> <br clear="none">>> ClusterLabs home: <a shape="rect" href="https://www.clusterlabs.org/ " target="_blank">https://www.clusterlabs.org/ </a><br clear="none">>> <br clear="none"><br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none">Manage your subscription:<br clear="none"><a shape="rect" href="https://lists.clusterlabs.org/mailman/listinfo/users" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br clear="none"><br clear="none">ClusterLabs home: <a shape="rect" href="https://www.clusterlabs.org/" target="_blank">https://www.clusterlabs.org/</a><br clear="none"></div> </div> </blockquote></div></div>