From: "Richard W.M. Jones" <rjones@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, armbru@redhat.com, famz@redhat.com,
qemu-trivial@nongnu.org, mjt@tls.msk.ru, berrange@redhat.com
Subject: Re: [Qemu-devel] [PATCH for-2.10] qemu-options: Document the -drive locking parameter.
Date: Tue, 12 Sep 2017 12:43:44 +0100 [thread overview]
Message-ID: <20170912114344.GQ20914@redhat.com> (raw)
In-Reply-To: <20170912113205.GG29136@localhost.localdomain>
On Tue, Sep 12, 2017 at 01:32:05PM +0200, Kevin Wolf wrote:
> Am 12.09.2017 um 11:45 hat Richard W.M. Jones geschrieben:
> > On Wed, Sep 06, 2017 at 01:38:45PM +0200, Kevin Wolf wrote:
> > > This command line fragment looks correct to me. For me, it seems to
> > > work. I'm starting a first qemu in the background with default locking
> > > options:
> > >
> > > $ x86_64-softmmu/qemu-system-x86_64 -hda /tmp/test.qcow2
> > >
> > > And then starting a second one with a command line resembling yours:
> > >
> > > $ x86_64-softmmu/qemu-system-x86_64 -device virtio-scsi \
> > > -drive file=/tmp/test.qcow2,cache=unsafe,format=qcow2,file.locking=off,id=hd0,if=none \
> > > -device scsi-hd,drive=hd0
> >
> > The problem is with overlays, where file.locking doesn't propagate to
> > the backing file. Thus:
> >
> > $ qemu-system-x86_64 -drive file=backing,format=raw
> >
> > while in another terminal:
> >
> > $ qemu-img create -b backing -f qcow2 overlay
> > $ qemu-system-x86_64 -drive file=overlay,format=qcow2,file.locking=off
> > qemu-system-x86_64: Failed to get shared "write" lock
> > Is another process using the image?
>
> locking=off isn't the right tool for the case. Try this:
>
> $ qemu-system-x86_64 -drive file=overlay,if=none -device virtio-blk-pci,drive=none0,share-rw=on
>
> Unless you're doing really evil things, just telling qemu that your
> guest can cope with concurrent writers to the same image is enough. This
> propagates through the whole chain as appropriate.
Our guest certainly *cannot* cope with multiple writers to the backing
disk (file "raw" in my example). In fact that would be a disaster.
The overlay protects the backing disk from ever seeing any writes.
In our case because the initial qemu instance (which we don't control)
opened the disk ("raw") with an exclusive lock, our only choice for
monitoring that disk is to turn off locking.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
next prev parent reply other threads:[~2017-09-12 11:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-06 8:50 [Qemu-devel] [PATCH for-2.10] qemu-options: Document the -drive locking parameter Richard W.M. Jones
2017-09-06 8:59 ` Daniel P. Berrange
2017-09-06 9:04 ` Richard W.M. Jones
2017-09-06 9:31 ` Richard W.M. Jones
2017-09-06 10:19 ` Kevin Wolf
2017-09-06 10:44 ` Richard W.M. Jones
2017-09-06 11:38 ` Kevin Wolf
2017-09-12 9:45 ` Richard W.M. Jones
2017-09-12 11:32 ` Kevin Wolf
2017-09-12 11:43 ` Richard W.M. Jones [this message]
2017-09-12 12:20 ` 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=20170912114344.GQ20914@redhat.com \
--to=rjones@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).