Re: [Qemu-devel] [PATCH v5 00/27] block: Lock images when opening

["Richard W.M. Jones" <rjones@redhat.com>]

On Tue, May 24, 2016 at 02:46:15PM +0200, Kevin Wolf wrote:
> Am 24.05.2016 um 13:48 hat Richard W.M. Jones geschrieben:
> > On Tue, May 17, 2016 at 03:35:09PM +0800, Fam Zheng wrote:
> > > v5: - Change "lock-image=on/off" to "lock-mode=exclusive/shared/off".
> > >       Default is "lock-mode=exclusive" to exclusively lock RW images and shared
> > >       lock RO images; with lock-mode="shared", RW images are shared locked too;
> > >       lock-mode=off turns off image locking completely.
> > >     - Use F_OFD_SETLK fcntl so that close/dup on different fds are not a
> > >       problem.
> > >     - Update test cases.
> > 
> > My comments after testing this patch set:
> > 
> > * It's not possible to tell from the `qemu -help' output that this
> >   binary supports the lock-mode option.  Please add this to the -help
> >   output (under `-drive') so we can detect it in qemu.
> > 
> > * I patched libguestfs to add the `lock-image=off' flag when the drive
> >   is added readonly.  This permits libguestfs to read live guests.  I
> >   also checked that writing to live guests is now forbidden, and it
> >   is, which is good.  In the write-to-live-guest case libguestfs will
> >   now fail with:
> > 
> >   qemu-system-x86_64: -drive file=/var/tmp/centos-6.img,cache=writeback,id=hd0,if=none: Failed to lock image
> > 
> > So definitely we need this option to be reflected in the -help output.
> 
> While you are right that maybe we should mentioned the new options in
> -help for human users, help texts are not meant to be parsed. If you do
> parse them and a changed help text breaks your code in the future,
> that's your problem.
> 
> Consider using query-qmp-schema instead, that one is actually meant to
> be processed by machines.

Yeah it's probably about time to do this now.  Previously it wasn't
done because opening a monitor port is slow (adds 60ms just to open
it, plus the time taken doing round trips to get the data).  However
we are now memoizing the results of querying qemu so this is no longer
critical.  I will have a look at how difficult it will be to query
this.

Anyway doesn't change the fact we need to be able to automatically
detect if the lock-mode flag is needed, given a random qemu binary.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top