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

Gionatan Danti g.danti at assyoma.it
Sat Dec 28 13:36:27 UTC 2019


Il 28-12-2019 01:39 Gionatan Danti ha scritto:
> Hi list,
> I would like to ask a clarification about how locking works. My test
> system is CentOS 7.7 with libvirt-4.5.0-23.el7_7.1.x86_64
> 
> Is was understanding that, by default, libvirt does not use any locks.
> From here [1]: "The out of the box configuration, however, currently
> uses the nop lock manager plugin". As "lock_manager" is commented in
> my qemu.conf file, I was expecting that no locks were used to protect
> my virtual disk from guest double-start or misassignement to other
> vms.
> 
> However, "cat /proc/locks" shows the following (17532905 being the 
> vdisk inode):
> [root at localhost tmp]# cat /proc/locks | grep 17532905
> 42: OFDLCK ADVISORY  READ  -1 fd:00:17532905 201 201
> 43: OFDLCK ADVISORY  READ  -1 fd:00:17532905 100 101
> Indeed, try to associate and booting the disk to another machines give
> me an error (stating that the disk is alredy in use).
> 
> Enabling the "lockd" plugin and starting the same machine, "cat
> /proc/locks" looks different:
> [root at localhost tmp]# cat /proc/locks | grep 17532905
> 31: POSIX  ADVISORY  WRITE 19266 fd:00:17532905 0 0
> 32: OFDLCK ADVISORY  READ  -1 fd:00:17532905 201 201
> 33: OFDLCK ADVISORY  READ  -1 fd:00:17532905 100 101
> As you can see, an *additional* write lock was granted. Again,
> assigning the disk to another vms and booting it up ends with the same
> error.
> 
> So, may I ask:
> - why does libvirtd requests READ locks even commenting the
> "lock_manager" option?
> - does it means that I can avoid modifying anything, relying on
> libvirtd to correctly locks image files?
> - if so, I should use virtlockd for what use cases?
> 
> Thanks.
> 
> [1] https://libvirt.org/locking-lockd.html

Ok, maybe I found some answers: from what I read here [1] and here [2], 
Qemu started to automatically lock disk image files to prevent 
corruption from processes outside libvirt scope (ie: manually issues 
"qemu-img" commands).

Do you suggest relying on Qemu own locks or using virtlockd (in addition 
to Qemu locks)? Whatever the answer is, can you explain why?

Thanks.

[1] 
https://qemu.weilnetz.de/doc/2.12/qemu-doc.html#disk_005fimage_005flocking

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1378241

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





More information about the libvirt-users mailing list