From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfVqZ-0008DF-J5 for qemu-devel@nongnu.org; Tue, 07 Apr 2015 11:55:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfVqV-0001m2-JL for qemu-devel@nongnu.org; Tue, 07 Apr 2015 11:55:27 -0400 Message-ID: <5523FDE6.30301@redhat.com> Date: Tue, 07 Apr 2015 11:55:18 -0400 From: John Snow MIME-Version: 1.0 References: <551C19F9.3020409@redhat.com> <20150402093849.GE6541@noname.str.redhat.com> <5523257D.7060706@redhat.com> <20150407084432.GC4635@noname.str.redhat.com> In-Reply-To: <20150407084432.GC4635@noname.str.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-img behavior for locating backing files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel , qemu-block 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