On Wed, Jul 12, 2017 at 8:00 PM Max Reitz <mre...@redhat.com> wrote: > On 2017-07-12 16:56, Kevin Wolf wrote: > > Am 12.07.2017 um 16:42 hat Eric Blake geschrieben: > >> On 05/17/2017 07:38 AM, Max Reitz wrote: > >> > >>>>>>>>>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786 > >>>>>>>>>> > >>>>>>>>>> Or, rather, force the open of a backing image if one was > specified > >>>>>>>>>> for creation. Using a similar -unsafe option as rebase, allow > qemu-img > >>>>>>>>>> to ignore the backing file validation if possible. > >>>>>>>>>> > >>>>>>>> > >> > >>>>> I suspect this is because the backing file is opened somewhere and > >>>>> trying to open it breaks now with the locking series applied. > >>>> > >>>> I think we can legitimately set force-shared=on for opening the > backing > >>>> file when testing whether the file exists. > >>> > >>> For testing whether the file exists, probably. I wouldn't call it > >>> legitimately because I don't like making that the default at all, but > it > >>> should work. > >>> > >>> But then we have to differentiate between testing whether the file > >>> exists and opening it to read its size; I'm even more wary regarding > the > >>> latter. > >>> > >>> All in all, I've stated my opinion on this matter on IRC: I don't know > >>> how much we need this patch. It's nice to have, it's convenient to know > >>> you have mistyped the backing filename before you try to use the image > >>> in qemu, but it's not critical. I don't consider the current behavior a > >>> bug per-se, it's just counterintuitive behavior (that will not cut your > >>> head off if you don't know it, though!). > >>> > >> > >> The fact that this topic came up on the mailing list again means we > >> should probably consider something along these lines for 2.10. > >> > >>> (Also, we have a lot of counterintuitive behavior. See this: > >>> > >>> $ qemu-img create -f qcow2 sub/backing.qcow2 64M > >>> Formatting 'sub/backing.qcow2', fmt=qcow2 size=67108864 encryption=off > >>> cluster_size=65536 lazy_refcounts=off refcount_bits=16 > >>> $ qemu-img create -f qcow2 -b sub/backing.qcow2 sub/top.qcow2 > >>> qemu-img: sub/top.qcow2: Could not open 'sub/sub/backing.qcow2': No > such > >>> file or directory > >>> > >>> Yeah, sure, you'll know after you've done the mistake once. But the > same > >>> applies here, too, doesn't it...?) > >>> > >>> So for me, it's a question of convenience: How much does the current > >>> behavior annoy users? How much annoyance will changing the behavior > >>> bring? I'm not (or rather, no longer) convinced the former outweighs > the > >>> latter, especially since it means having to change management tools > >>> (which create external snapshots with qemu-img create while the backing > >>> image is in use by qemu). > >>> > >>> If you think otherwise, well, you're the main maintainer. :-) > >>> > >>> Max > >>> > >>> > >>> PS: Can there be a middle ground? Like just printing a warning if the > >>> backing file cannot be opened and we don't absolutely have to? > >> > >> Middle ground may be harder, but may be nicer (especially since we are > >> talking about tightening behavior, making things that used to work now > >> fail is not nice if there is not a transition period where it first just > >> warns). > > > > We can do the nowadays usual thing: Add a -u option, print a deprecation > > warning if we don't have -u and can't open the backing file, and put > > it into the list of things to remove in 3.0. > > Works for me. >
Should work for oVirt. When we consume the -u/--unsafe option, should we use qemu-img version, or maybe we need an official api for detecting capabilities? qemu-img caps --format json { "unsafe-create": True, ... Nir