From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB2JL-0004Gx-2b for qemu-devel@nongnu.org; Tue, 04 Oct 2011 06:33:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RB2JJ-0002Ch-W4 for qemu-devel@nongnu.org; Tue, 04 Oct 2011 06:33:19 -0400 Received: from mail-ww0-f41.google.com ([74.125.82.41]:50070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB2JJ-0002CS-NS for qemu-devel@nongnu.org; Tue, 04 Oct 2011 06:33:17 -0400 Received: by wwf10 with SMTP id 10so4557563wwf.4 for ; Tue, 04 Oct 2011 03:33:17 -0700 (PDT) Date: Tue, 4 Oct 2011 11:33:14 +0100 From: Stefan Hajnoczi Message-ID: <20111004103314.GB32199@stefanha-thinkpad.localdomain> References: <20111004073348.GB8149@stefanha-thinkpad.localdomain> <8a3164fe-9521-4fb6-84fb-069e398ebe39@zmail02.collab.prod.int.phx2.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a3164fe-9521-4fb6-84fb-069e398ebe39@zmail02.collab.prod.int.phx2.redhat.com> Subject: Re: [Qemu-devel] New option for snapshot_blkdev to avoid image creation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Federico Simoncelli Cc: abaron@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org On Tue, Oct 04, 2011 at 04:27:42AM -0400, Federico Simoncelli wrote: > ----- Original Message ----- > > From: "Stefan Hajnoczi" > > To: "Federico Simoncelli" > > Cc: qemu-devel@nongnu.org, abaron@redhat.com, dlaor@redhat.com > > Sent: Tuesday, October 4, 2011 9:33:48 AM > > Subject: Re: [Qemu-devel] New option for snapshot_blkdev to avoid image creation > > > > On Mon, Oct 03, 2011 at 04:09:01PM +0000, Federico Simoncelli wrote: > > > In some situations might be useful to let qemu use an image that > > > was > > > prepared for a live snapshot. > > > The advantage is that creating the snapshot file outside of the > > > qemu > > > process we can use the whole range of options provided by the > > > format > > > (eg for qcow2: encryption, cluster_size and preallocation). > > > It is also possible to pre-set a relative path to the backing file > > > (now it is created by default as absolute path). > > > In the long run it can also avoid the danger of reimplementing > > > qemu-img > > > inside qemu (if we wanted to expose such options when a snapshot is > > > requested). > > > > When the image file is created based on the backing file size: > > > > $ qemu-img create -f qcow2 -o backing_file=master.img vm001.qcow2 > > > > It turns out that bdrv_img_create() opens the backing file with > > read/write permissions. This is generally a bad idea but especially > > dangerous when the VM currently has the image file open already since > > image formats are not designed for multiple initiators (clustering). > > Hi Stefan, are you sure that bdrv_img_create opens the backing file > with read/write permissions? You are absolutely right. BDRV_O_FLAGS does not have BDRV_O_RDWR so it is opening read-only. I missed this when reading the code earlier today. Stefan