Users

Download

users@lists.libvirt.org

August 2026

3 participants
2 discussions

Libvirt/sanlock doesn't lock after a migration then trashes my disk.
by Matthew Schumacher 20 Aug '26

20 Aug '26

Hello All, Trying to figure out how this is supposed to work. I’m using pacemaker with the ocf:heartbeat:VirtualDomain to manage my virtual machines. If I start a vm on hyper-1 I get locks: > 2026-08-20 02:11:14.835+0000: 27626: debug : virLockManagerPluginGetDriver:275 : plugin=0x7f9b6003b080 > 2026-08-20 02:11:14.835+0000: 27626: debug : virLockManagerNew:298 : driver=0x7f9ba717d020 type=0 nparams=5 params=0x7f9bb00776c0 flags=0x0 > 2026-08-20 02:11:14.835+0000: 27626: debug : virLockManagerLogParams:96 : key=uuid type=uuid value=a5318b9d-48ea-4e06-8591-4f7826b3d0fa > 2026-08-20 02:11:14.835+0000: 27626: debug : virLockManagerLogParams:89 : key=name type=string value=testvm1 > 2026-08-20 02:11:14.835+0000: 27626: debug : virLockManagerLogParams:77 : key=id type=uint value=12 > 2026-08-20 02:11:14.835+0000: 27626: debug : virLockManagerLogParams:77 : key=pid type=uint value=7258 > 2026-08-20 02:11:14.835+0000: 27626: debug : virLockManagerLogParams:92 : key=uri type=cstring value=qemu:///system > 2026-08-20 02:11:14.835+0000: 27626: debug : virLockManagerAddResource:324 : lock=0x7f9ba8011280 type=0 name=/datastore/vm/testvm1/testvm1.raw nparams=0 params=(nil) flags=0x0 > 2026-08-20 02:11:14.835+0000: 27626: debug : virLockManagerAcquire:342 : lock=0x7f9ba8011280 state='<null>' flags=0x0 action=0 fd=(nil) > 2026-08-20 02:11:14.835+0000: 27626: debug : virLockManagerSanlockAcquire:1007 : Acquiring object 1 > 2026-08-20 02:11:14.845+0000: 27626: debug : virLockManagerSanlockAcquire:1057 : Acquire completed fd=-1 > 2026-08-20 02:11:14.845+0000: 27626: debug : virLockManagerFree:380 : lock=0x7f9ba8011280 If I move that VM to hyper-2 using (virsh --connect=qemu:///system --quiet migrate --live testvm1 qemu+ssh://hyper-2/system) it frees the lock on hyper-1: > 2026-08-20 02:11:32.485+0000: 27630: debug : virLockManagerPluginGetDriver:275 : plugin=0x7f9b6003b080 > 2026-08-20 02:11:32.485+0000: 27630: debug : virLockManagerNew:298 : driver=0x7f9ba717d020 type=0 nparams=5 params=0x7f9bae8744d0 flags=0x0 > 2026-08-20 02:11:32.485+0000: 27630: debug : virLockManagerLogParams:96 : key=uuid type=uuid value=a5318b9d-48ea-4e06-8591-4f7826b3d0fa > 2026-08-20 02:11:32.485+0000: 27630: debug : virLockManagerLogParams:89 : key=name type=string value=testvm1 > 2026-08-20 02:11:32.485+0000: 27630: debug : virLockManagerLogParams:77 : key=id type=uint value=12 > 2026-08-20 02:11:32.485+0000: 27630: debug : virLockManagerLogParams:77 : key=pid type=uint value=7258 > 2026-08-20 02:11:32.485+0000: 27630: debug : virLockManagerLogParams:92 : key=uri type=cstring value=(null) > 2026-08-20 02:11:32.486+0000: 27630: debug : virLockManagerAddResource:324 : lock=0x7f9b94069210 type=0 name=/datastore/vm/testvm1/testvm1.raw nparams=0 params=(nil) flags=0x0 > 2026-08-20 02:11:32.486+0000: 27630: debug : virLockManagerInquire:370 : lock=0x7f9b94069210 state=0x7f9b940656b0 flags=0x0 > 2026-08-20 02:11:32.486+0000: 27630: debug : virLockManagerSanlockInquire:1148 : pid=7258 > 2026-08-20 02:11:32.486+0000: 27630: debug : virLockManagerFree:380 : lock=0x7f9b94069210 > 2026-08-20 02:11:32.486+0000: 27630: debug : virLockManagerPluginGetName:259 : plugin=0x7f9b6003b080 > 2026-08-20 02:11:32.774+0000: 27628: debug : virLockManagerPluginUsesState:267 : plugin=0x7f9b6003b080 > 2026-08-20 02:11:33.028+0000: 7260: debug : virLockManagerPluginGetDriver:275 : plugin=0x7f9b6003b080 > 2026-08-20 02:11:33.028+0000: 7260: debug : virLockManagerNew:298 : driver=0x7f9ba717d020 type=0 nparams=5 params=0x7f9b9effc790 flags=0x0 > 2026-08-20 02:11:33.028+0000: 7260: debug : virLockManagerLogParams:96 : key=uuid type=uuid value=a5318b9d-48ea-4e06-8591-4f7826b3d0fa > 2026-08-20 02:11:33.028+0000: 7260: debug : virLockManagerLogParams:89 : key=name type=string value=testvm1 > 2026-08-20 02:11:33.028+0000: 7260: debug : virLockManagerLogParams:77 : key=id type=uint value=12 > 2026-08-20 02:11:33.028+0000: 7260: debug : virLockManagerLogParams:77 : key=pid type=uint value=7258 > 2026-08-20 02:11:33.028+0000: 7260: debug : virLockManagerLogParams:92 : key=uri type=cstring value=(null) > 2026-08-20 02:11:33.028+0000: 7260: debug : virLockManagerAddResource:324 : lock=0x7f9b60001590 type=0 name=/datastore/vm/testvm1/testvm1.raw nparams=0 params=(nil) flags=0x0 > 2026-08-20 02:11:33.028+0000: 7260: debug : virLockManagerRelease:358 : lock=0x7f9b60001590 state=0x7f9ba83df8d8 flags=0x0 > 2026-08-20 02:11:33.030+0000: 7260: debug : virLockManagerFree:380 : lock=0x7f9b60001590 Then on hyper-2 I get the lock: > 2026-08-20 02:11:33.057+0000: 3357: debug : virLockManagerPluginGetDriver:275 : plugin=0x7f4694043cd0 > 2026-08-20 02:11:33.057+0000: 3357: debug : virLockManagerNew:298 : driver=0x7f46be7e1020 type=0 nparams=5 params=0x7f46db6dc5f0 flags=0x0 > 2026-08-20 02:11:33.057+0000: 3357: debug : virLockManagerLogParams:96 : key=uuid type=uuid value=a5318b9d-48ea-4e06-8591-4f7826b3d0fa > 2026-08-20 02:11:33.057+0000: 3357: debug : virLockManagerLogParams:89 : key=name type=string value=testvm1 > 2026-08-20 02:11:33.057+0000: 3357: debug : virLockManagerLogParams:77 : key=id type=uint value=3 > 2026-08-20 02:11:33.057+0000: 3357: debug : virLockManagerLogParams:77 : key=pid type=uint value=17070 > 2026-08-20 02:11:33.057+0000: 3357: debug : virLockManagerLogParams:92 : key=uri type=cstring value=qemu:///system > 2026-08-20 02:11:33.057+0000: 3357: debug : virLockManagerAddResource:324 : lock=0x7f46cc006fb0 type=0 name=/datastore/vm/testvm1/testvm1.raw nparams=0 params=(nil) flags=0x0 > 2026-08-20 02:11:33.057+0000: 3357: debug : virLockManagerAcquire:342 : lock=0x7f46cc006fb0 state='__LIBVIRT__DISKS__:9ac7be7343fc02b995dcdfe541d0bcbc:/datastore/sanlock/9ac7be7343fc02b995dcdfe541d0bcbc:0:5' flags=0x0 action=0 fd=(nil) > 2026-08-20 02:11:33.057+0000: 3357: debug : virLockManagerSanlockAcquire:1007 : Acquiring object 1 > 2026-08-20 02:11:33.063+0000: 3357: debug : virLockManagerSanlockAcquire:1057 : Acquire completed fd=-1 > 2026-08-20 02:11:33.063+0000: 3357: debug : virLockManagerFree:380 : lock=0x7f46cc006fb0 All is well, but then I call on hyper-1 virsh create /datastore/vm/testvm1/testvm1.xml I get: error: internal error: QEMU unexpectedly closed the monitor (vm='testvm1'): 2026-08-20T02:12:28.413165Z qemu-system-x86_64: -device {"driver":"scsi-hd","bus":"scsi0.0","channel":0,"scsi-id":0,"lun":0,"device_id":"drive-scsi0-0-0-0","drive":"libvirt-2-storage","id":"scsi0-0-0-0","bootindex":2,"write-cache":"on"}: Failed to get "write” lock But in the logs I never see it checking the lock and while the NFS4.2 file system didn’t give it a lock and blocked, it still trashes the VM disk and the VM shows disk errors and mounts read-only. Shouldn’t libvirt/sanlock block this before starting qemu? I’m running libvirt 12.6.0 and qemu 10.2.4 on kernel 6.18.44. I would think these settings would work: # grep lock_ /etc/libvirt/qemu.conf lock_manager = "sanlock" # grep "^[^#]" /etc/libvirt/qemu-sanlock.conf auto_disk_leases = 1 disk_lease_dir = "/datastore/sanlock" host_id = 1 require_lease_for_disks = 1 Thanks!

1 0

File permissions in CIFS network filesystem pool
by Thomas Pircher 19 Aug '26

19 Aug '26

Hi, I'm trying to use a network filesystem pool on a Samba/CIFS share. Libvirt is configured with this pool: <pool type='netfs'> <name>netfs-default</name> <source> <host name='samba.lan.internal'/> <dir path='libvirt/default'/> <format type='cifs'/> </source> <target> <path>/var/lib/libvirt/images/netfs/default</path> <permissions> <mode>0755</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> The Samba share is configured with: [libvirt] comment = VM storage pool browseable = yes path = /srv/datastore/samba/libvirt/ writeable = yes public = no guest ok = yes create mask = 0644 directory mask = 0755 force user = shared force group = +shared I can create the pool in virsh. The mounted files are owned by root on the libvirt machine. I can create and edit files as root if I access them via shell. However, libvirt can't start VMs. It fails to open the qcow2 file in the network filesystem pool with "permission denied". The libvirt host is Debian 14 (testing). I can't see any Selinux or Apparmor messages when the failure happens. So I believe the permissions problem is that libvirt tries to access the files as libvirt-qemu user, and this fails. I have tried adding the following snippet to the network fs pool definition, but after saving the pool, these options simply vanish from the network fs pool definition: <fs:mount_opts> <fs:option name='uid=libvirt-qemu'/> <fs:option name='gid=libvirt-qemu'/> </fs:mount_opts> So my question: how can I make this work? I have previously tried using NFSv4, but ran into similar issues. I guess I could make this work by mounting the share outside of libvirt and then point the filesystem pool at the mounted directory. Is there a more elegant way? Thanks, Thomas

2 2