[Top][All Lists]

[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.


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.


With above three, we can simply export a point-in-time snapshot with two QMP 

    drive-backup device=virtio0 format=qcow2 target=point-in-time.qcow2 
target-id=pit0 sync=none

    nbd-server-add device=pit0 writable=no


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(-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]