On Thu, 09/21 13:43, 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.
Probably it's helpful to add a hint about "--force-share" the in the error message of "qemu-img info" when hitting an image lock failure? Fam
