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 :|