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

[John Snow]

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

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.

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

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

Thanks,
--js