From: Fam Zheng <famz@redhat.com>
To: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] need to resurrect no-lock option?
Date: Wed, 20 Sep 2017 17:51:14 +0800 [thread overview]
Message-ID: <20170920095114.GA9135@lemon.lan> (raw)
In-Reply-To: <CAATJJ0KLaR6VUrPZZSQxwb6niF5YY0UMB5sWDq9b=OeeC5=1Xw@mail.gmail.com>
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...
>
> 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
next prev parent reply other threads:[~2017-09-20 13:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 9:26 [Qemu-devel] need to resurrect no-lock option? Christian Ehrhardt
2017-09-20 9:51 ` Fam Zheng [this message]
2017-09-20 10:04 ` Christian Ehrhardt
2017-09-21 12:33 ` Stefan Hajnoczi
2017-09-21 12:43 ` Daniel P. Berrange
2017-09-21 12:55 ` Fam Zheng
2017-09-21 13:18 ` Daniel P. Berrange
2017-09-22 7:27 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170920095114.GA9135@lemon.lan \
--to=famz@redhat.com \
--cc=christian.ehrhardt@canonical.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.