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

[Kevin Wolf]

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

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