[ClusterLabs] Antw: [EXT] Qemu VM resources ‑ cannot acquire state change lock

[Ulrich Windl]

Hi!

Sorry I don't have a solution, but using "indirect locks" with libvirtd seems
to have no solution when the same cluster also provides the shared filesystem
through cluster means.
(I had reported on that before)
libvirtd cannot start before virtlockd, which annot start before the shared
filesystem is available (as otherwise the locks could not be shared across
nodes).
The problem are the probes that seemingly cannot have any dependencies (so
they runn all at once at node start), and the results of VirtualDomain probes
without a running libvirtd are questionable at least.

So maybe tell us more about your configuration and logs...

Regards,
Ulrich

>>> lejeczek via Users <users at clusterlabs.org> schrieb am 26.08.2021 um 11:13
in
Nachricht <3f0babf5-8426-34c4-5f21-4334369e408d at yahoo.co.uk>:
> Hi guys.
> 
> I sometimes ‑ I think I know when in terms of any pattern ‑ 
> get resources stuck on one node (two‑node cluster) with 
> these in libvirtd's logs:
> ...
> Cannot start job (query, none, none) for domain 
> c8kubermaster1; current job is (modify, none, none) owned by 
> (192261 qemuProcessReconnect, 0 <null>, 0 <null> 
> (flags=0x0)) for (1093s, 0s, 0s)
> Cannot start job (query, none, none) for domain ubuntu‑tor; 
> current job is (modify, none, none) owned by (192263 
> qemuProcessReconnect, 0 <null>, 0 <null> (flags=0x0)) for 
> (1093s, 0s, 0s)
> Timed out during operation: cannot acquire state change lock 
> (held by monitor=qemuProcessReconnect)
> Timed out during operation: cannot acquire state change lock 
> (held by monitor=qemuProcessReconnect)
> ...
> 
> when this happens, and if the resourec is meant to be the 
> other node, I have to to disable the resource first, then 
> the node on which resources are stuck will shutdown the VM 
> and then I have to re‑enable that resource so it would, only 
> then, start on that other, the second node.
> 
> I think this problem occurs if I restart 'libvirtd' via systemd.
> 
> Any thoughts on this guys?
> many thanks, L.
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users 
> 
> ClusterLabs home: https://www.clusterlabs.org/