Re: [Qemu-devel] need to resurrect no-lock option?

[Christian Ehrhardt]

On Wed, Sep 20, 2017 at 11:51 AM, Fam Zheng <address@hidden> 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