|
From: | John Snow |
Subject: | Re: [Qemu-block] [Qemu-devel] qemu-img behavior for locating backing files |
Date: | Tue, 07 Apr 2015 11:55:18 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |