qemu-devel
[Top][All Lists]
Advanced

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

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


From: Ala Hino
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U
Date: Tue, 9 Jan 2018 22:29:04 +0200

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


reply via email to

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