Re: [Qemu-devel] [PATCH for-2.10] qemu-options: Document the -drive locking parameter.

[Kevin Wolf <kwolf@redhat.com>]

Am 12.09.2017 um 13:43 hat Richard W.M. Jones geschrieben:
> 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.

Your guest (the libguestfs one with the overlay) can cope with multiple
writers to its disk. Or probably it can't, but you treat it as if it
could and insist that this is correct enough. Otherwise you wouldn't be
able to use a raw image that another VM writes to as its backing file.

> The overlay protects the backing disk from ever seeing any writes.

This is why the backing file is opened read-only and therefore
compatible with the initial qemu instance that requires exclusive write
access.

This is all correctly represented in the locking. You wouldn't be able
to directly use "raw" even with share-rw=on because the initial qemu
instance doesn't support shared write access. But it works for a backing
file.

> 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.

No, you just need to make sure that the libguestfs instance doesn't
need write access to the image of an exclusive writer. Which you already
do.

The only locking problem that you need to solve is that your libguestfs
VM doesn't forbid other writers to its backing file. And this is exactly
what share-rw=on achieves.

Kevin