qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Federico Simoncelli <fsimonce@redhat.com>
Cc: abaron@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] New option for snapshot_blkdev to avoid image creation
Date: Tue, 4 Oct 2011 11:33:14 +0100	[thread overview]
Message-ID: <20111004103314.GB32199@stefanha-thinkpad.localdomain> (raw)
In-Reply-To: <8a3164fe-9521-4fb6-84fb-069e398ebe39@zmail02.collab.prod.int.phx2.redhat.com>

On Tue, Oct 04, 2011 at 04:27:42AM -0400, Federico Simoncelli wrote:
> ----- Original Message -----
> > From: "Stefan Hajnoczi" <stefanha@gmail.com>
> > To: "Federico Simoncelli" <fsimonce@redhat.com>
> > 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

  reply	other threads:[~2011-10-04 10:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03 16:09 [Qemu-devel] New option for snapshot_blkdev to avoid image creation Federico Simoncelli
2011-10-03 16:09 ` [Qemu-devel] [PATCH] qemu: new " Federico Simoncelli
2011-10-06 22:45   ` Dor Laor
2011-10-11 11:56     ` Federico Simoncelli
2011-10-11 12:00       ` Dor Laor
2011-10-04  7:33 ` [Qemu-devel] New " Stefan Hajnoczi
2011-10-04  8:27   ` Federico Simoncelli
2011-10-04 10:33     ` Stefan Hajnoczi [this message]
2011-10-11 12:30 ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111004103314.GB32199@stefanha-thinkpad.localdomain \
    --to=stefanha@gmail.com \
    --cc=abaron@redhat.com \
    --cc=dlaor@redhat.com \
    --cc=fsimonce@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).