I wonder if your QEMU is using OFD locks or not, which might depend on a few things: -Are you using a distributed QEMU or one you've built yourself? -What glibc was it compiled against? -What version of Linux are you running under?
I would have thought that after the process that held the lock died that the lock would be released, but perhaps it's more complicated than that because of NFS, perhaps there's a very long timeout involved somewhere? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1819343 Title: Qcow2 image stuck as locked after host crash Status in QEMU: New Bug description: After a host crash, the qcow2 image of the VM, stored on a remote NFS share, has become inaccessible. Libvirt/QEMU reports that 'failed to get "write" lock\nIs another process using the image [/path/nfs/image.qcow2]?'. No process is accessing the image from either host or the network share side. There is no obvious way in qemu-img to force unlocking the file or repair the image (attempting a qemu-img check with -r all results in qemu-img complaining about the lock and being unable to do force-share=on on anything but readonly images). I'm currently attempting to fix this by converting the image via 'qemu-img convert -U -f qcow2 -O qcow2 image.qcow2 image_2.gcow2', though this will likely take some time. Using QEMU 3.1.0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1819343/+subscriptions
