Re: [Qemu-devel] qemu-img behavior for locating backing files

[John Snow <jsnow@redhat.com>]

On 04/07/2015 04:44 AM, Kevin Wolf wrote:
> Am 07.04.2015 um 02:31 hat John Snow geschrieben:
>>
>>
>> On 04/02/2015 05:38 AM, Kevin Wolf wrote:
>>> Am 01.04.2015 um 18:16 hat John Snow geschrieben:
>>>> Kevin, what's the correct behavior for qemu-img and relative paths
>>>> when creating a new qcow2 file?
>>>>
>>>> Example:
>>>>
>>>> (in e.g. /home/qemu/build/ or anywhere not /home: )
>>>> qemu-img create -f qcow2 base.qcow2 32G
>>>> qemu-img create -f qcow2 -F qcow2 -b base.qcow2 /home/overlay.qcow2
>>>>
>>>> In 1.7.0., this produces a warning that the base object cannot be
>>>> found (because it does not exist at that location relative to
>>>> overlay.qcow2), but qemu-img will create the qcow2 for you
>>>> regardless.
>>>>
>>>> 2.0, 2.1 and 2.2 all will create the image successfully, with no warnings.
>>>>
>>>> 2.3-rc1/master as they exist now will emit an error message and
>>>> create no image.
>>>>
Are you going to take care of that, or should I write one?


>>>> Since this is a change in behavior for the pending release, is this
>>>> the correct/desired behavior?
>>>
>>> Part one of the answer is easy: qemu-img create should succeed if, and
>>> only if, a usable image is created. This requires that the backing file
>>> exists.
>>>
>>
>> So far so good.
>>
>>> Part two is a bit harder: Should base.qcow2 be found in the current
>>> directory even if the new image is somewhere else? We must give
>>> preference to an existing base.qcow2 relative to the new image path, but
>>> if it doesn't exist, we could in theory try to find it relative to the
>>> working directory.
>>>
>>
>> Nack. This seems like inviting heartbreak unnecessarily.
>>
>>> If we then find it, we have two options: Either we use that image
>>> (probably with an absolute path then?) or we print a useful error
>>> message that instructs the user how relative paths work with images.
>>> I think the latter is better because the other option feels like too
>>> much magic.
>>>
>>
>> Too much magic indeed. I think where ambiguity of paths is
>> concerned, it is best to stick to one particular path and make it
>> very explicit.
>>
>> In this case, if we cannot find some relative path offered by the
>> user, an error message such as:
>>
>> "Hey! We can't find /absolute/path/to/../your/relative/file.qcow2"
>>
>> should be sufficient to clue the user in to where qemu-img is
>> looking for this backing file.
>
> Yes, printing the combined path sounds like a good option.
>
>> A usability bonus might be when we go to whine at the user, if the
>> file exists relative to the PWD:
>>
>> "Qemu noticed a file at /your/pwd/.../your/relative/file.qcow2, but
>> Qemu expects relative paths for backing files to be relative to the
>> image referencing them, not your current PWD"
>>
>> but this is just a Deluxe Niceness.
>
> If we touch it anyway, why not have Deluxe Niceness?
>

Your wish is my command!

>>> In any case, the behaviour you describe for 2.3-rc1 seems to be the best
>>> that we've had until now; 1.7.0 looks like the second best. We should
>>> probably "document" the 2.3-rc1 behaviour with a qemu-iotests case.
>>>
>>
>> Absolutely.
>
> Are you going to take care of that, or should I write one?
>
>>> Oh, and we still have a bug: If you specify an image size, qemu-img
>>> doesn't check at all whether the backing file exists.
>
> Same question here.
>
> Kevin
>

I meant to imply I'd do it, thanks!

--js