Am 06.09.2017 um 12:44 hat Richard W.M. Jones geschrieben:
> On Wed, Sep 06, 2017 at 12:19:05PM +0200, Kevin Wolf wrote:
> > Am 06.09.2017 um 10:50 hat Richard W.M. Jones geschrieben:
> > > Commit 16b48d5d66d2 ("file-posix: Add 'locking' option") added this
> > > option, but as it was not documented in the -help output it was not
> > > easily possible to tell if a particular qemu binary supports it.
> > >
> > > Signed-off-by: Richard W.M. Jones <rjo...@redhat.com>
> > > ---
> > > qemu-options.hx | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/qemu-options.hx b/qemu-options.hx
> > > index 9f6e2adfff..f8f95eb498 100644
> > > --- a/qemu-options.hx
> > > +++ b/qemu-options.hx
> > > @@ -796,7 +796,7 @@ DEF("drive", HAS_ARG, QEMU_OPTION_drive,
> > > "
> > > [,cache=writethrough|writeback|none|directsync|unsafe][,format=f]\n"
> > > " [,serial=s][,addr=A][,rerror=ignore|stop|report]\n"
> > > "
> > > [,werror=ignore|stop|report|enospc][,id=name][,aio=threads|native]\n"
> > > - " [,readonly=on|off][,copy-on-read=on|off]\n"
> > > + "
> > > [,readonly=on|off][,copy-on-read=on|off][,locking=off|auto|on]\n"
> > > " [,discard=ignore|unmap][,detect-zeroes=on|off|unmap]\n"
> > > " [[,bps=b]|[[,bps_rd=r][,bps_wr=w]]]\n"
> > > " [[,iops=i]|[[,iops_rd=r][,iops_wr=w]]]\n"
> >
> > 'locking' is a driver-specific option and not universally available for
> > all images, so it shouldn't be included here.
>
> Indeed this patch is wrong, please ignore it.
>
> However I couldn't work out the incantation to disable locking for a
> qcow2 overlay backed by a file which is locked by another qemu
> process:
>
> ...
> -drive
> file=/home/rjones/d/libguestfs/tmp/libguestfsSOXEiU/overlay1,cache=unsafe,format=qcow2,file.locking=off,id=hd0,if=none
> \
> -device scsi-hd,drive=hd0 \
> ...
> qemu-system-x86_64: -device scsi-hd,drive=hd0: Failed to get shared "write"
> lock
> Is another process using the image?
> ...
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
This works for me. If I set file.locking=auto, it fails as expected, so
it's not that the locking isn't working for me at all.
> I'm guessing I need another level of indirection to get to the backing
> file, but file.file.locking=off did not work either.
No, that would be too much. Without a prefix you configure the qcow2
layer, with the 'file.' prefix you configure the file-posix one. There
is no further nested node.
> I think the error message there is wrong as well since it doesn't
> refer to the right command line option nor tell you which file is
> locked.
This is interesting, I do get -drive in my error message with
locking=auto.
I could see how your message makes sense with -blockdev because I think
then the image file is really only locked as soon as it is used (and
only with the permissions that that user requires), so -device would in
fact be where it happens and the error message would reflect that. But
with -drive, we already request some permissions while opening the
image, so I would definitely expect -drive in your error message.
Kevin
