From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43723 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OR6m7-0001Rw-0o for qemu-devel@nongnu.org; Tue, 22 Jun 2010 12:56:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OR6m5-000258-Jp for qemu-devel@nongnu.org; Tue, 22 Jun 2010 12:56:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22781) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OR6m5-00024t-D7 for qemu-devel@nongnu.org; Tue, 22 Jun 2010 12:56:37 -0400 Date: Tue, 22 Jun 2010 17:56:33 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack Message-ID: <20100622165633.GK21175@redhat.com> References: <4C1DF2C1.5040505@redhat.com> <4C1F2093.3060807@redhat.com> <4C1F6482.7020406@codemonkey.ws> <4C1F6973.5020003@redhat.com> <4C1F6B36.8070508@codemonkey.ws> <4C1F70AF.8030108@redhat.com> <4C2072CA.6080703@redhat.com> <20100622164002.GD4371@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100622164002.GD4371@shareable.org> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Kevin Wolf , Christoph Hellwig , Markus Armbruster , qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , Gerd Hoffmann On Tue, Jun 22, 2010 at 05:40:02PM +0100, Jamie Lokier wrote: > Kevin Wolf wrote: > > > The "protocol" parlance breaks down when we move away from the simple > > > stuff. For instance, qcow2 needs two children: the block driver > > > providing the delta bits (in qcow2 format), and the block driver > > > providing the base bits (whose configuration happens to be stored in the > > > delta bits). > > > > Backing files are different. When talking about opening images (which is > > what we do here) the main difference is that they can be opened only > > after the image itself has been opened. I don't think we should include > > them in this discussion. > > Imho, being unable to override the qcow2 backing file from the command > line / monitor is very annoying, if you've moved files from another > machine or just renamed them for tidiness. It's especially bad if the > supplied qcow2 file has an absolute path in it, quite bad if it has > subdirectories or ".." components, annoying if you've been given > several qcow2 files all of which have the name "backing-file" stored > in them which are different images because they were originally on > different machines, and awful if it has the name of a block device in it. FYI, in the scenario where you've moved backing files around, you can use qemu-img to update the location qemu-img rebase -u -b /path/to/newbackingfile.img demo.img Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|