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

[Ala Hino]

On Tue, Jan 9, 2018 at 10:11 PM, Eric Blake <address@hidden> wrote:

On 01/09/2018 01:58 PM, Ala Hino wrote:

>>> 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

Which is a downgrade in qemu behavior, since we've already had releases
where it was an error (and if you have to worry about THOSE qemu
releases, then the warning doesn't buy you anything).

We test our code on RHEL, and currently require qemu-kvm-rhev >= 2.6.0.

On RHEL 7.4 qemu-kvm-rhev version is 2.9.0 - and everything works good.

However, on RHEL 7.5 the version is 2.10.0, which breaks RHV 4.1.

If we got qemu-kvm-rhev 2.10.0 in RHEL 7.4 repositories, we could detect the

failure earlier and maybe we would be able to adapt the code before releasing 4.1.

> 2. Conflict qemu with vdsm < 4.2

If I'm understanding this option correctly, you are proposing that the
distribution is set up so that you have to upgrade vdsm prior to being
able to upgrade to newer qemu that enables locking (so you can use old
vdsm, old qemu; new vdsm, old qemu; new vdsm, new qemu; but you get
rejected on attempts to use old vdsm, new qemu).  That's outside the
scope of qemu proper and falls instead into the distro's packaging
scheme, but sounds like a better alternative than trying to fix new qemu
to work around an issue that released qemu already has, all on behalf of
vdsm where old vdsm plays nice with old qemu, and where new vdsm already
knows how to play nice with both flavors of qemu.

I agree that this might be the better option.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org