On Wed, Sep 20, 2017 at 11:51 AM, Fam Zheng <f...@redhat.com> wrote: > On Wed, 09/20 11:26, 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. > > The --no-lock option was later revised into --force-share, so... >
Thanks for the remapping of this old patch to what it ended up! Test works for me, need to check with other affected cases. > > > 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? > > ... you can do this: > > $ qemu-img info --force-share /tmp/test.qcow2 > image: /tmp/test.qcow2 > file format: qcow2 > virtual size: 1.0M (1048576 bytes) > disk size: 196K > cluster_size: 65536 > Format specific information: > compat: 1.1 > lazy refcounts: false > refcount bits: 16 > corrupt: false > > Fam > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
