libvirt users - Jan 2020 - Re: Locking without virtlockd (nor sanlock)?

On Fri, Jan 03, 2020 at 02:56:50PM +0100, Gionatan Danti
wrote:
> Il 03-01-2020 11:26 Daniel P. Berrangé ha scritto:
> > virtlockd also uses fcntl(), however, it doesn't have to acquire
locks
> > on
> > the file/block device directly. It can use a look-aside file for
> > locking.
> > For example a path under /var/lib/libvirt/lock. This means that locks
on
> > block devices for /dev/sda1 would be held as
> > /var/lib/libvirt/lock/$HASH(/dev/sda1)
> > 
> > If you mount /var/lib/libvirt/lock on NFS, these locks now apply
across
> > all machines which use the same block devices. This is useful when
your
> > block device storage is network based (iSCSI, RBD, etc).
> 
> Hi Daniel,
> if I understand the docs correctly, this locking scheme is really useful
for
> raw block devices, right?
> 
> Now that Qemu automatically locks file-based vdisks, what is the main
> advantage of virtlockd locking?
QEMU's locking should be good enough for file based images. There isn't
a clear benefit to virtlockd in this case.
> 
> > 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...

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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.

Il 06-01-2020 10:06 Peter Krempa ha scritto:
> On Fri, Jan 03, 2020 at 14:08:03 +0000, Daniel Berrange wrote:
>> As above, QEMU's locking is good enough to rely on for file based
>> images.
Hi Daniel, thank you for the direct confirmation.
>> 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.
Hi Peter, can I ask what do you mean with "fixed with -blockdev"?

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8