[Top][All Lists]

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

Re: [Qemu-block] [PATCH v4] qemu-img: Check for backing image if specifi

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v4] qemu-img: Check for backing image if specified during create
Date: Wed, 12 Jul 2017 09:42:04 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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