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 :|
next prev parent 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).