On Fri, Jan 03, 2020 at 14:08:03 +0000, Daniel Berrange wrote:
On Fri, Jan 03, 2020 at 02:56:50PM +0100, Gionatan Danti wrote:
Il 03-01-2020 11:26 Daniel P. Berrangé ha scritto:
[...]
There are some issues with libvirt's locking though where we haven't always released/re-acquired locks at the correct time when dealing with block jobs. As long as your not using snapshots, block rebase, block mirror APIs, it'll be ok though.
While I am not an heavy user of external snapshot and other block-related operation, I occasionally use them (and, in these cases, I found them very useful).
Does it means that I should avoid relying on virtlockd for locking? Should I rely on Qemu locks only?
As above, QEMU's locking is good enough to rely on for file based images.
The flaws I mention with libvirt might actually finally be something we have fixed in 5.10.0 with QEMU 4.2.0, since we can finally use "blockdev" syntax for configuring disks. Copying Peter to confirm/deny this...
The main issue was that we were leaking locks on the backing chain. This should be now fixed with -blockdev as we call the appropriate apis to lock/unlock the images but I didn't try it with virtlockd. Certainly if there's still a problem now we have well defined places where we know what's happening to images so it should be easy to fix them.