Hi, a colleague of mine has pointed out that this is a well-worn problem with nfs*v3*:
https://bugzilla.redhat.com/show_bug.cgi?id=1547095#c43 Workarounds seem to involve: - Use v4, or - Use the nolock option. Does this cover your use case? ** Bug watch added: Red Hat Bugzilla #1547095 https://bugzilla.redhat.com/show_bug.cgi?id=1547095 -- 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
