qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Fam Zheng <famz@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U
Date: Wed, 10 Jan 2018 14:13:15 +0000	[thread overview]
Message-ID: <20180110141315.GW3205@redhat.com> (raw)
In-Reply-To: <20180110140712.GB3638@localhost.localdomain>

On Wed, Jan 10, 2018 at 03:07:12PM +0100, Kevin Wolf wrote:
> Am 10.01.2018 um 13:49 hat Daniel P. Berrange geschrieben:
> > On Mon, Jan 08, 2018 at 03:41:36PM +0100, Kevin Wolf wrote:
> > > Am 05.01.2018 um 07:55 hat Fam Zheng geschrieben:
> > > > Management and users are accustomed to "qemu-img info" to query status of
> > > > images even when they are used by guests. Since image locking was added, the -U
> > > > (--force-share) option is needed for that to work. The reason has been that due
> > > > to possible race with image header update, the output can be misleading.
> > > > 
> > > > But what are likely to happen after we emit the error are that, for interactive
> > > > users, '-U' will be used and the command retried; for management (nova, RHV,
> > > > etc.), the operation is broken with no knob to workaround this.
> > > > 
> > > > This series changes that error to a warning so that it doesn't get in the way.
> > > 
> > > Are management tools actually doing this? There is no good reason to
> > > call 'qemu-img info' for an image that is in use by a VM.
> > 
> > OpenStack will frequently call 'qemu-img info' for disks that are in use by
> > VMs. It is looking at the sizes to understand the relation between the current
> > size used by qcow2 vs the possible future usage. In this context, it does not
> > matter if the data is slightly outdated, as it will catch up next time it reads
> > it a few mins later.
> > 
> > It has been patched to just retry with -U to avoid this error on new
> > QEMU.
> 
> The proper, though somewhat more intrusive fix would be to use QMP
> commands for images of running VMs. You already need to do the same for
> anything modifying the image (to avoid corruption), so I think doing the
> same with 'query-block' instead of 'qemu-img info' for guaranteed
> consistent results on running VMs only makes sense.

The problem with 'query-block' is that you assume the code that is
processing this set of disk images knows which image is used where.

This code in question merely sees a directory full of images, and does
not directly know whether any of them are in use or not. So trying to
use query-block would make it significantly more complex for little
obvious benefit to OpenStack.

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

  reply	other threads:[~2018-01-10 14:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-05  6:55 [Qemu-devel] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U Fam Zheng
2018-01-05  6:55 ` [Qemu-devel] [PATCH 1/2] qemu-img: Move img_open error reporting to callers Fam Zheng
2018-01-05 16:03   ` Eric Blake
2018-01-05  6:55 ` [Qemu-devel] [PATCH 2/2] qemu-img: info: try -U automatically Fam Zheng
2018-01-05 16:08   ` Eric Blake
2018-01-08 14:41 ` [Qemu-devel] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U Kevin Wolf
2018-01-08 17:07   ` [Qemu-devel] [Qemu-block] " Nir Soffer
2018-01-08 17:57     ` Kevin Wolf
2018-01-09  6:24       ` Fam Zheng
2018-01-09  9:58         ` Kevin Wolf
2018-01-09 19:58           ` Ala Hino
2018-01-09 20:11             ` Eric Blake
2018-01-09 20:29               ` Ala Hino
2018-01-10 12:51       ` Daniel P. Berrange
2018-01-10 12:49   ` [Qemu-devel] " Daniel P. Berrange
2018-01-10 14:07     ` Kevin Wolf
2018-01-10 14:13       ` Daniel P. Berrange [this message]
2018-01-10 14:03   ` Kashyap Chamarthy
2018-01-10 16:43     ` [Qemu-devel] [Qemu-block] " Nir Soffer
2018-01-11  9:26       ` Kashyap Chamarthy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180110141315.GW3205@redhat.com \
    --to=berrange@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).