The QEMU process that has the disk image open may be doing I/O that causes qcow2 metadata to be changed. Such changes could confuse the 'qemu-img' process it is was reading the metadata at the same time it was being changed, causing bad data to be printed or worse. So requiring a write lock is the 'safe' thing to do for reliability in the worst case. You can override this by passing '--force-share' arg though.
-- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1721788 Title: Failed to get shared "write" lock with 'qemu-img info' Status in QEMU: New Bug description: When running 'qemu-img info test.qcow2' while test.qcow2 is currently used by a Qemu process, I get the error qemu-img: Could not open 'test.qcow2': Failed to get shared "write" lock. Why does displaying information about a disk image need a write lock for the file? Steps to reproduce: qemu-img create -f qcow2 test.qcow2 10M qemu-system-x86_64 -nographic -drive file=test.qcow2 qemu-img info test.qcow2 The above was tested with Qemu version 2.10.0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1721788/+subscriptions
