On Tue, Jan 9, 2018 at 10:11 PM, Eric Blake <ebl...@redhat.com> 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 > >