On Wed, Sep 20, 2017 at 11:26:11AM +0200, Christian Ehrhardt wrote: > Hi, > this might have been discussed in the wake of the lock changes that took > place in 2.10 but I can't find anything clear enough to follow in the > current case. > There was an old submission [1] by Fam to make it possible to no-lock > qemu-img and others if needed. But it seems nothing like it made it along > to the locking we have in 2.10. > > One (maybe more) case where missing this causes pain is e.g. running an > info check on a running guest. > In general info shouldn't need a write lock anyway, but without --no-lock > that use case is broken.
It's still an invalid use case. There is no guarantee that qemu-img will see a consistent version of the image file. Metadata could change underneath qemu-img because QEMU may still write to it. QEMU may also have some metadata cached so there's no guarantee that qemu-img sees an up-to-date image. Why do you need to run qemu-img on a disk image that is in use? > Repro of the case is rather simple: > $ qemu-img create -f qcow2 /tmp/test.qcow2 1M > $ qemu-system-x86_64 -hda /tmp/test.qcow2 -enable-kvm -nodefaults > -nographic & > $ qemu-img info /tmp/test.qcow2 > qemu-img: Could not open '/tmp/test.qcow2': Failed to get shared "write" > lock > Is another process using the image? > > [1]: https://lists.gnu.org/archive/html/qemu-block/2016-04/msg00349.html > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd
