[libvirt-users] Locking without virtlockd (nor sanlock)?

[Peter Krempa]

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.