From: Fam Zheng <famz@redhat.com>
To: qemu-devel@nongnu.org
Cc: kwolf@redhat.com, famz@redhat.com, obarenbo@redhat.com,
roliveri@redhat.com, hbrock@redhat.com, rjones@redhat.com,
armbru@redhat.com, pmyers@redhat.com, imain@redhat.com,
stefanha@redhat.com, pbonzini@redhat.com
Subject: [Qemu-devel] [PATCH 0/7] Point-in-time snapshot exporting over NBD
Date: Tue, 2 Jul 2013 13:59:42 +0800 [thread overview]
Message-ID: <1372744789-997-1-git-send-email-famz@redhat.com> (raw)
This series adds for point-in-time snapshot NBD exporting based on
drive-backup. The ideas is described below and patches followed (the missing
part is item 3, which work is in progress by Ian Main who will have another
patch on it). As the work does not overlap, these series should be quite
reviewable by itself.
Background
==========
The goal of image fleecing is to provide a interface to inspect a point-in-time
snapshot of guest image data, not being interfered with guest overwrites after
it's created. With drive-backup we already have the point-in-time snapshot
image (the target image), we only need three modifications to realize this:
1. Give backup target an id, so we can add it to NBD server.
2. Assign source device as backing of target, so reading the unallocated will
be passed to source.
As there's copy-on-write mechanism with drive-backup job, all the modified
data after snapshot created is copied to target, the unallocated data is
guaranteed to be unchanged, so reading from the source is correct. Note
that this requires target format supports backing file.
3. Adding sync mode 'none' to drive-backup, so the block job only copy changed
data from source, which has minimal IO overhead.
Usage
=====
With above three, we can simply export a point-in-time snapshot with two QMP commands:
drive-backup device=virtio0 format=qcow2 target=point-in-time.qcow2 target-id=pit0 sync=none
(sync=none is not implemented for now but we can simulate with speed=1)
nbd-server-add device=pit0 writable=no
Lifecycle
=========
Reference count for BlockDriverState is implemented to manage their lifecycles.
Device attachment, block job, backing hd, bs->file NBD and others are current
referred points of a BDS, they each call bdrv_get_ref when starting to use a
BDS and bdrv_put_ref when releasing, e.g. on hot plug/unplug, nbd_server_add,
drive-backup, etc.
I.e., when a drive-backup target bs is being exported through NBD and the backup
job finishes (or cancelled), the device is not deleted, the client can continue
to access the NBD target until nbd_server_stop. It is automatically deleted
when the last reference is released.
The target image file is not removed automatically, since we can't assume that
it's temporary. It's up to the user to remove it manually, or we need to add a
command or option to mark the target bs temporary.
Fam Zheng (7):
block: Convert BlockDriverState.in_use to refcount
block: use refcount to manage BlockDriverState lifecycle
nbd: use BDS refcount
block: simplify bdrv_drop_intermediate
block: rename bdrv_in_use to bdrv_is_shared
block: add target-id option to drive-backup QMP command
block: assign backing relationship in drive-backup
block-migration.c | 5 +-
block.c | 123 +++++++++++++++-------------------------
block/backup.c | 16 +++++-
block/blkdebug.c | 1 +
block/blkverify.c | 2 +
block/mirror.c | 4 +-
block/snapshot.c | 3 +-
block/stream.c | 2 +-
block/vvfat.c | 4 +-
blockdev-nbd.c | 9 +--
blockdev.c | 19 ++++---
blockjob.c | 8 +--
hw/block/dataplane/virtio-blk.c | 4 +-
hw/block/xen_disk.c | 7 +--
include/block/block.h | 5 +-
include/block/block_int.h | 18 +++++-
nbd.c | 5 ++
qapi-schema.json | 7 ++-
qmp-commands.hx | 3 +-
19 files changed, 126 insertions(+), 119 deletions(-)
--
1.8.3.1
next reply other threads:[~2013-07-02 6:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-02 5:59 Fam Zheng [this message]
2013-07-02 5:59 ` [Qemu-devel] [PATCH 1/7] block: Convert BlockDriverState.in_use to refcount Fam Zheng
2013-07-02 10:21 ` Paolo Bonzini
2013-07-08 8:37 ` Fam Zheng
2013-07-02 19:41 ` Eric Blake
2013-07-03 0:59 ` Fam Zheng
2013-07-02 5:59 ` [Qemu-devel] [PATCH 2/7] block: use refcount to manage BlockDriverState lifecycle Fam Zheng
2013-07-02 5:59 ` [Qemu-devel] [PATCH 3/7] nbd: use BDS refcount Fam Zheng
2013-07-02 10:16 ` Paolo Bonzini
2013-07-03 1:10 ` Fam Zheng
2013-07-03 5:58 ` Paolo Bonzini
2013-07-03 6:30 ` Fam Zheng
2013-07-03 7:28 ` Paolo Bonzini
2013-07-02 5:59 ` [Qemu-devel] [PATCH 4/7] block: simplify bdrv_drop_intermediate Fam Zheng
2013-07-04 14:02 ` Stefan Hajnoczi
2013-07-05 1:00 ` Fam Zheng
2013-07-02 5:59 ` [Qemu-devel] [PATCH 5/7] block: rename bdrv_in_use to bdrv_is_shared Fam Zheng
2013-07-02 5:59 ` [Qemu-devel] [PATCH 6/7] block: add target-id option to drive-backup QMP command Fam Zheng
2013-07-02 19:59 ` Eric Blake
2013-07-02 5:59 ` [Qemu-devel] [PATCH 7/7] block: assign backing relationship in drive-backup Fam Zheng
2013-07-04 14:32 ` Stefan Hajnoczi
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=1372744789-997-1-git-send-email-famz@redhat.com \
--to=famz@redhat.com \
--cc=armbru@redhat.com \
--cc=hbrock@redhat.com \
--cc=imain@redhat.com \
--cc=kwolf@redhat.com \
--cc=obarenbo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pmyers@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=roliveri@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).