qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Ian Main <imain@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: kwolf@redhat.com, hbrock@redhat.com, qemu-devel@nongnu.org,
	rjones@redhat.com, stefanha@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH v3 0/2] Point-in-time snapshot exporting over NBD
Date: Fri, 22 Nov 2013 12:11:36 -0800	[thread overview]
Message-ID: <20131122201136.GB9591@gate.mains.priv> (raw)
In-Reply-To: <528EEFEE.2060708@redhat.com>

On Fri, Nov 22, 2013 at 01:47:26PM +0800, Fam Zheng wrote:
> On 2013年11月20日 10:32, Ian Main wrote:
> >On Thu, Oct 17, 2013 at 01:36:41PM +0800, Fam Zheng wrote:
> >>This series adds for point-in-time snapshot NBD exporting based on
> >>blockdev-backup (variant of drive-backup with existing device as target).
> >
> >In general this seems to work great.  I did a bunch of testing and was
> >able to mount filesystems over NBD, do many writes (on backed up
> >image)/reads (on target), intense IO etc and all held up fine.
> >
> >There are definitely some issues with some of the commands allowing you
> >to blow things up.  I'm interested to hear opinions on whether this is a
> >showstopper at this time or not.
> >
> 
> Thanks very much for your testing, Ian. QEMU should report error
> instead of crashing with invalid operations. I added an "operation
> blocker" and incorporated into the next version.
> 
> In the future, we still want to review more on those commands and
> try to enable safe ones, and possibly also allow multiple block jobs
> on a BDS. For now it is good enough to only allow blockdev-backup on
> the source and NBD export on the target (which is safe, and all what
> we need for image fleecing, as this version shows). With that being
> a working implementation, I've posted v4. Please test and free to
> make comments.

That's great.  Interesting solution you have come up with.  I will give
it a try and let you know how it goes.
 
> >>We get a thin point-in-time snapshot by COW mechanism of drive-backup, and
> >>export it through built in NBD server. The steps are as below:
> >>
> >>  1. (SHELL) qemu-img create -f qcow2 BACKUP.qcow2 <source size here>
> >>
> >>     (Alternatively we can use -o backing_file=RUNNING-VM.img to omit explicitly
> >>     providing the size by ourselves, but it's risky because RUNNING-VM.qcow2 is
> >>     used r/w by guest. Whether or not setting backing file in the image file
> >>     doesn't matter, as we are going to override the backing hd in the next
> >>     step)
> >>
> >>  2. (QMP) blockdev-add backing=source-drive file.driver=file file.filename=BACKUP.qcow2 id=target0 if=none driver=qcow2
> >
> >I had to create a custom python script to make these commands work as
> >they require nested dicts.  Is that normal or did I miss something
> >entirely?
> >
> 
> Yes, I use a python script locally to test it too.

I like your notation.. I might try to make a patch for qmp/qmp-shell to
allow it to create nested dicts using the dot notation.

	Ian

      reply	other threads:[~2013-11-22 20:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-17  5:36 [Qemu-devel] [RFC PATCH v3 0/2] Point-in-time snapshot exporting over NBD Fam Zheng
2013-10-17  5:36 ` [Qemu-devel] [RFC PATCH v3 1/2] block: parse "backing" option to reference existing BDS Fam Zheng
2013-10-18 10:04   ` Fam Zheng
2013-10-17  5:36 ` [Qemu-devel] [RFC PATCH v3 2/2] qmp: add command 'blockdev-backup' Fam Zheng
2013-10-18  9:54   ` Paolo Bonzini
2013-11-20  2:32 ` [Qemu-devel] [RFC PATCH v3 0/2] Point-in-time snapshot exporting over NBD Ian Main
2013-11-22  5:47   ` Fam Zheng
2013-11-22 20:11     ` Ian Main [this message]

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=20131122201136.GB9591@gate.mains.priv \
    --to=imain@redhat.com \
    --cc=famz@redhat.com \
    --cc=hbrock@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=stefanha@redhat.com \
    /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).