[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [RFC PATCH 0/3] Point-in-time snapshot exporting with drive
From: |
Fam Zheng |
Subject: |
[Qemu-devel] [RFC PATCH 0/3] Point-in-time snapshot exporting with drive-backup |
Date: |
Wed, 26 Jun 2013 11:59:18 +0800 |
This series adds partial support 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 and 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
nbd-server-add device=pit0 writable=no
Lifecycle
=========
The block job originally had total control over target bs: when the job
completes, the target is deleted. Now it's shared with NBD, so we should make
sure the job completion or canceling wouldn't crash NBD server. This patch
doesn't handle this case: if the block job is ended before NBD exporting,
there'll be problem.
To avoid this, we either add more delicate condition checks as we do with
bs->in_use, or introduce reference count to BlockDriverState, which seems much
better in long term but needs more work. I have done some work on it, but it's
not ready yet. As we don't depend on it that heavily, let's do the things one
by one.
Any comments?
Fam Zheng (3):
block: add target-id option to drive-backup QMP command
block: assign backing relationship in drive-backup
nbd: don't get ref if bs has no drive
blockdev-nbd.c | 6 +++++-
blockdev.c | 8 +++++++-
qapi-schema.json | 7 +++++--
qmp-commands.hx | 3 ++-
4 files changed, 19 insertions(+), 5 deletions(-)
--
1.8.3.1
- [Qemu-devel] [RFC PATCH 0/3] Point-in-time snapshot exporting with drive-backup,
Fam Zheng <=
- [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command, Fam Zheng, 2013/06/26
- Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command, Stefan Hajnoczi, 2013/06/27
- Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command, Fam Zheng, 2013/06/27
- Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command, Paolo Bonzini, 2013/06/27
- Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command, Fam Zheng, 2013/06/27
- Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command, Paolo Bonzini, 2013/06/27
- Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command, Fam Zheng, 2013/06/27
[Qemu-devel] [RFC PATCH 2/3] block: assign backing relationship in drive-backup, Fam Zheng, 2013/06/26
[Qemu-devel] [RFC PATCH 3/3] nbd: don't get ref if bs has no drive, Fam Zheng, 2013/06/26