On Tue, Jan 9, 2018 at 11:58 AM, Kevin Wolf <kw...@redhat.com> 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 >