Re: [Qemu-devel] need to resurrect no-lock option?

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Sep 21, 2017 at 01:43:17PM +0100, Daniel P. Berrange wrote:
> On Thu, Sep 21, 2017 at 01:33:20PM +0100, Stefan Hajnoczi wrote:
> > On Wed, Sep 20, 2017 at 11:26:11AM +0200, 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.
> > 
> > It's still an invalid use case.  There is no guarantee that qemu-img
> > will see a consistent version of the image file.  Metadata could change
> > underneath qemu-img because QEMU may still write to it.  QEMU may also
> > have some metadata cached so there's no guarantee that qemu-img sees an
> > up-to-date image.
> > 
> > Why do you need to run qemu-img on a disk image that is in use?
> 
> You have a directory full of images and you want to understand current usage
> vs potential future usage. For this you need to get the virtual size, which
> rquires 'qemu-img info' for non-raw files. Actually it would be even better
> served by the new 'measure' command recently added.
> 
> The job analyzing this directory of images may not have any context as to
> whether each file is in use by a running QEMU, so would just blindly call
> 'qemu-img info' on each file it finds.  There's of course potential that
> opening the image in 'qemu-img info' could hit problems if the running QEMU
> changed qcow2 metadata, but generally that would not have serious negative
> impact and would be self-correcting next time the job analysed the directory.

FYI this scenario has already hit OpenStack with breakage on new QMEU

  https://bugs.launchpad.net/nova/+bug/1718295

and thus they're just going to add '--force-shared' for all usage of
qemu-img info.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|