On Wed, Jan 10, 2018 at 4:04 PM Kashyap Chamarthy <kcham...@redhat.com> 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 > used. > > > 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? Nir