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

[Ala Hino]

On Tue, Jan 9, 2018 at 11:58 AM, Kevin Wolf <address@hidden> wrote:

> Am 09.01.2018 um 07:24 hat Fam Zheng geschrieben:
> > On Mon, 01/08 18:57, Kevin Wolf wrote:
> > > I'm not sure if going back to the old behaviour for a while now would
> be
> > > helpful, you'd just end up with an even more confusing set of qemu
> > > versions, for example:
> > >
> > >     <= 2.9          - works without a warning
> > >     2.10 and 2.11   - errors out
> > >     2.12            - prints a warning, but works
> > >     >= 2.13         - errors out again
> >
> > What I had in mind is settle on warning for good. QEMU (including
> qemu-img) is a
> > low level tool that can be used in many ways that it isn't supposed to,
> this one
> > is not more harmful than others (e.g. "qemu-img snapshot ..." on
> iscsi:// qcow2
> > image) we allow siliently.
> >
> > I know this is debatable but I think the #1 purpose of image locking is
> to
> > prevent data corruption;
>
> Isn't potentially wrong output of 'qemu-img info' a form of data
> corruption? Not data as in disk content, but metadata is data, too.
>
> > #2 IMO is to reduce confusion and misinformation.
> > While inconsistent output of "qemu-img info" is misinformation, it not
> working
> > as before is actually confusion. Though the current behavior is indeed
> ideal,
> > the proposed patch is a bit more pragmatical.
>
> To be clear: If we want to minimise confusing by change, we have to
> disable locking by default, not only here but everywhere else. And
> therefore make it completely useless.
>
> The whole point of locking is to change something in order to make
> things safer. Yes, this may inconvenience users who want to do something
> unsafe. Tough luck. The only other option is not making things safer.
>

Safer is better for sure.
It is not about doing something unsafe, it is about breaking a released
version -
RHV 4.1 is already out and when customers upgrade to RHEL 7.5, they will not
be able to create snapshots.
I see two options:
1. As mentioned by Fam, settle on warning for good
2. Conflict qemu with vdsm < 4.2

>
> We already successfully made a point that tools (libvirt with shared
> images, or libguestfs) need to update their qemu invocation for qemu
> proper. They didn't like it, but they could see the point, and it has
> been this way for two releases already. So I don't see a compelling
> reason why now we should give up again some of the safety we achieved
> long-term.
>
> If we were designing qemu-img from scratch, it would be an error. So
> that's what it should be in the long term. Tools should preferably use
> 'query-block' and friends rather 'qemu-img info' if the image is in use.
>
> Kevin
>