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

[Kevin Wolf]

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.

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.

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.

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.

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