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

[Gionatan Danti]

Il 28-12-2019 14:36 Gionatan Danti ha scritto:
> 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

Hi all,
any suggestion on the matter?

Thanks.

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