Re: [Qemu-devel] [PATCH v4 0/8] block: drive-backup live backup command
Am 16.05.2013 um 10:36 hat Stefan Hajnoczi geschrieben: Note: These patches apply to my block-next tree. You can also grab the code from git here: git://github.com/stefanha/qemu.git block-backup-core This series adds a new QMP command, drive-backup, which takes a point-in-time snapshot of a block device. The snapshot is copied out to a target block device. A simple example is: drive-backup device=virtio0 format=qcow2 target=backup-20130401.qcow2 Dietmar Maurer (1): block: add basic backup support to block driver Stefan Hajnoczi (7): block: add bdrv_add_before_write_notifier() block: add drive-backup QMP command qemu-iotests: add 055 drive-backup test case blockdev: rename BlkTransactionStates to singular blockdev: add DriveBackup transaction blockdev: add Abort transaction qemu-iotests: test 'drive-backup' transaction in 055 block.c| 18 ++- block/Makefile.objs| 1 + block/backup.c | 283 blockdev.c | 264 +++--- include/block/block_int.h | 38 - qapi-schema.json | 69 - qmp-commands.hx| 37 + tests/qemu-iotests/055 | 348 + tests/qemu-iotests/055.out | 5 + tests/qemu-iotests/group | 1 + 10 files changed, 1000 insertions(+), 64 deletions(-) create mode 100644 block/backup.c create mode 100755 tests/qemu-iotests/055 create mode 100644 tests/qemu-iotests/055.out Commented on patches 2, 3 and 4. The others are: Reviewed-by: Kevin Wolf kw...@redhat.com
Re: [Qemu-devel] [PATCH v4 0/8] block: drive-backup live backup command
On Thu, May 16, 2013 at 10:36:11AM +0200, Stefan Hajnoczi wrote: [...] How can drive-backup be used? - The simplest use-case is to copy a point-in-time snapshot to a local file. More advanced users may wish to make the target an NBD URL. The NBD server listening on the other side can process the backup writes any way it wishes. I previously posted an RFC series with a backup server that streamed Dietmar's VMA backup archive format. I'm guessing the answer is no, but thought I would ask: Is there any way to use this to do point-in-time inspection of guests? AFAICT the only way to do it would be to make a complete copy of a guest disk in another file. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
Re: [Qemu-devel] [PATCH v4 0/8] block: drive-backup live backup command
Il 19/05/2013 18:47, Richard W.M. Jones ha scritto: More advanced users may wish to make the target an NBD URL. The NBD server listening on the other side can process the backup writes any way it wishes. I previously posted an RFC series with a backup server that streamed Dietmar's VMA backup archive format. I'm guessing the answer is no, but thought I would ask: Is there any way to use this to do point-in-time inspection of guests? Almost, and even for an atomic copy of multiple disks. All that is left is to create the copy with the disk as a backing file, and switch the backing file at the end of the copy. It is a very simple change on top of these patches. Paolo AFAICT the only way to do it would be to make a complete copy of a guest disk in another file.
Re: [Qemu-devel] [PATCH v4 0/8] block: drive-backup live backup command
On Sun, May 19, 2013 at 09:30:46PM +0200, Paolo Bonzini wrote: Il 19/05/2013 18:47, Richard W.M. Jones ha scritto: More advanced users may wish to make the target an NBD URL. The NBD server listening on the other side can process the backup writes any way it wishes. I previously posted an RFC series with a backup server that streamed Dietmar's VMA backup archive format. I'm guessing the answer is no, but thought I would ask: Is there any way to use this to do point-in-time inspection of guests? Almost, and even for an atomic copy of multiple disks. All that is left is to create the copy with the disk as a backing file, and switch the backing file at the end of the copy. It is a very simple change on top of these patches. Cool news. I look forward to this :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
[Qemu-devel] [PATCH v4 0/8] block: drive-backup live backup command
Note: These patches apply to my block-next tree. You can also grab the code from git here: git://github.com/stefanha/qemu.git block-backup-core This series adds a new QMP command, drive-backup, which takes a point-in-time snapshot of a block device. The snapshot is copied out to a target block device. A simple example is: drive-backup device=virtio0 format=qcow2 target=backup-20130401.qcow2 The original drive-backup blockjob was written by Dietmar Maurer diet...@proxmox.com. He is currently busy but I feel the feature is worth pushing into QEMU since there has been interest. This is my version of his patch, plus the QMP command and qemu-iotests test case. QMP 'transaction' support is included since v3. It adds support for atomic snapshots of multiple block devices. I also added an 'abort' transaction to allow testing of the .abort()/.cleanup() code path. Thanks to Wenchao for making qmp_transaction() extensible. How is this different from block-stream and drive-mirror? - Both block-stream and drive-mirror do not provide immediate point-in-time snapshots. Instead they copy data into a new file and then switch to it. In other words, the point at which the snapshot is taken cannot be controlled directly. drive-backup intercepts guest writes and saves data into the target block device before it is overwritten. The target block device can be a raw image file, backing files are not used to implement this feature. How can drive-backup be used? - The simplest use-case is to copy a point-in-time snapshot to a local file. More advanced users may wish to make the target an NBD URL. The NBD server listening on the other side can process the backup writes any way it wishes. I previously posted an RFC series with a backup server that streamed Dietmar's VMA backup archive format. What's next for drive-backup? - 1. Sync modes like drive-mirror (top, full, none). This makes it possible to preserve the backing file chain. v4: * Use notifier lists and BdrvTrackedRequest instead of custom callbacks [bonzini] * Add drive-backup QMP example JSON [eblake] * Add Since: 1.6 to QMP schema changes [eblake] v3: * Rename to drive-backup for consistency with drive-mirror [kwolf] * Add QMP transaction support [kwolf] * Introduce bdrv_add_before_write_cb() to hook writes * Mention 'query-block-jobs' lists job of type 'backup' [eblake] * Rename rwlock to flush_rwlock [kwolf] * Fix space in block/backup.c comment [kwolf] v2: * s/block_backup/block-backup/ in commit message [eblake] * Avoid funny spacing in QMP docs [eblake] * Document query-block-jobs and block-job-cancel usage [eblake] Dietmar Maurer (1): block: add basic backup support to block driver Stefan Hajnoczi (7): block: add bdrv_add_before_write_notifier() block: add drive-backup QMP command qemu-iotests: add 055 drive-backup test case blockdev: rename BlkTransactionStates to singular blockdev: add DriveBackup transaction blockdev: add Abort transaction qemu-iotests: test 'drive-backup' transaction in 055 block.c| 18 ++- block/Makefile.objs| 1 + block/backup.c | 283 blockdev.c | 264 +++--- include/block/block_int.h | 38 - qapi-schema.json | 69 - qmp-commands.hx| 37 + tests/qemu-iotests/055 | 348 + tests/qemu-iotests/055.out | 5 + tests/qemu-iotests/group | 1 + 10 files changed, 1000 insertions(+), 64 deletions(-) create mode 100644 block/backup.c create mode 100755 tests/qemu-iotests/055 create mode 100644 tests/qemu-iotests/055.out -- 1.8.1.4
