From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vo9ca-0005jm-QQ for qemu-devel@nongnu.org; Wed, 04 Dec 2013 05:24:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vo9cR-0007Fg-FF for qemu-devel@nongnu.org; Wed, 04 Dec 2013 05:23:56 -0500 Received: from mail-ea0-x22f.google.com ([2a00:1450:4013:c01::22f]:53571) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vo9cR-0007Fb-6p for qemu-devel@nongnu.org; Wed, 04 Dec 2013 05:23:47 -0500 Received: by mail-ea0-f175.google.com with SMTP id z10so10563602ead.34 for ; Wed, 04 Dec 2013 02:23:46 -0800 (PST) Date: Wed, 4 Dec 2013 11:23:43 +0100 From: Stefan Hajnoczi Message-ID: <20131204102343.GD19096@stefanha-thinkpad.redhat.com> References: <20131203152228.11970.2938.malonedeb@soybean.canonical.com> <20131203152228.11970.2938.malonedeb@soybean.canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131203152228.11970.2938.malonedeb@soybean.canonical.com> Subject: Re: [Qemu-devel] [Bug 1257334] [NEW] diffuse handling of image creation from another path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bug 1257334 <1257334@bugs.launchpad.net> Cc: Kevin Wolf , qemu-devel@nongnu.org On Tue, Dec 03, 2013 at 03:22:28PM -0000, Florian Miksch wrote: Hi, This does not look like a bug. Please see the explanation below... Inlining Florian's reproducer script so we can discuss it via email: > #!/bin/bash > # This script does create a backing image and overlay to > # reproduce the reported bug. > #... > > mkdir a > # Create an image from another path e.g. in the directory 'a' > qemu-img create -f qcow2 a/blob.img 10G > > # Create an overlay image from another path in the same directory > qemu-img create -f qcow2 -b a/blob.img a/ovl.img > > # Get Info in the new directory > cd a > qemu-img info ovl.img > # Output: > # image: ovl.img > # file format: qcow2 > # virtual size: 10G (10737418240 bytes) > # disk size: 196K > # cluster_size: 65536 > # backing file: a/blob.img > > # Get the Info from another directory > cd .. > qemu-img info a/ovl.img > # Output: > # image: a/ovl.img > # file format: qcow2 > # virtual size: 10G (10737418240 bytes) > # disk size: 196K > # cluster_size: 65536 > # backing file: a/blob.img (actual path: a/a/blob.img) > > # Bug: > # Compare 'image' > # Compare 'backing file' > # Look at 'actual path' The behavior you are showing here is explained as follows: Backing file paths can be relative or absolute and are stored inside the image file. In this case you are providing a relative backing file path. Relative backing file paths are interpreted against the image filename. In other words: join_path(dirname('a/ovl.img'), 'a/blob.img') -> 'a/a/blob.img' > > # 'qemu-img info' takes the recommended path as name of the image > # and the actual path is then: a/a/blob.img > > qemu-img commit a/ovl.img > # Now commit fails > # --> ERROR "No such file or directory The problem was: > qemu-img create -f qcow2 -b a/blob.img a/ovl.img If you want to use a relative backing file path, remember that it is relative to the image file: cd a && qemu-img create -f qcow2 -b blob.img ovl.img Then 'qemu-img commit a/ovl.img' will work as expected. Stefan