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.