From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfP7k-0002cK-Au for qemu-devel@nongnu.org; Tue, 07 Apr 2015 04:44:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfP7j-0005gq-90 for qemu-devel@nongnu.org; Tue, 07 Apr 2015 04:44:44 -0400 Date: Tue, 7 Apr 2015 10:44:32 +0200 From: Kevin Wolf Message-ID: <20150407084432.GC4635@noname.str.redhat.com> References: <551C19F9.3020409@redhat.com> <20150402093849.GE6541@noname.str.redhat.com> <5523257D.7060706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5523257D.7060706@redhat.com> Subject: Re: [Qemu-devel] qemu-img behavior for locating backing files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: qemu-devel , qemu-block 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