[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 0/2] qemu-img: Let "info" warn and

From: Nir Soffer
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U
Date: Wed, 10 Jan 2018 16:43:22 +0000

On Wed, Jan 10, 2018 at 4:04 PM Kashyap Chamarthy <address@hidden> wrote:
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.

Yes, Nova does use 'qemu-img info' in a few places (haven't audited them
all) for a running guest.  From a quick look at the code, at-least
during Nova's live snaphot (as part of libvirt's "shallow rebase") it is

> If no, NACK. Automatically disabling locking because it can be
> inconvenient defeats the purpose of locking.
> If yes, clearly indicate that this usage is deprecated and we'll turn
> this into an error again with 2.13. Then management tools can be fixed
> in time.

Yes, for completness' sake, Nova upstream is already patched to use the
`qemu-img` '--force-share' flag that comes with QEMU >= 2.10.

What abut users running released Nova, upgrading to 2.10?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]