[libvirt] RFC: API additions for enhanced snapshot support

[Stefan Hajnoczi]

On Wed, Jul 27, 2011 at 3:17 PM, Eric Blake <eblake at redhat.com> wrote:
> On 07/27/2011 04:04 AM, Stefan Hajnoczi wrote:
>>
>> On Thu, Jun 16, 2011 at 6:41 AM, Eric Blake<eblake at redhat.com>  wrote:
>>>
>>> Right now, libvirt has a snapshot API via virDomainSnapshotCreateXML,
>>> but for qemu domains, it only works if all the guest disk images are
>>> qcow2, and qemu rather than libvirt does all the work.  However, it has
>>> a couple of drawbacks: it is inherently tied to domains (there is no way
>>> to manage snapshots of storage volumes not tied to a domain, even though
>>> libvirt does that for qcow2 images associated with offline qemu domains
>>> by using the qemu-img application).  And it necessarily operates on all
>>> of the images associated with a domain in parallel - if any disk image
>>> is not qcow2, the snapshot fails, and there is no way to select a subset
>>> of disks to save.  However, it works on both active (disk and memory
>>> state) and inactive domains (just disk state).
>>
>> Hi Eric,
>> Any updates on your proposed snapshot API enhancements?
>
> I still need to post a v2 RFC that gives the XML changes needed to support
> disk snapshots on top of virDomainSnapshotCreateXML.
>
> Meanwhile, I still want to add additional API to make it easier to manage
> offline storage volume snapshots (storage volumes that are not in use by a
> defined or running domain), although it obviously won't happen by 0.9.4.

Previous discussion has focussed on image files.  Is part of your plan
to extend virStorageBackend and let the LVM backend support the new
APIs?

>> The use case I am particularly interested in is a backup solution
>> using libvirt snapshot APIs to take consistent backups of guests.  The
>> two workflows are reading out full snapshots of disk images (full
>> backup) and reading only those blocks that have changed since the last
>> backup (incremental backup).
>
> Full backup should be supported via virDomainSnapshotCreateXML, once I have
> the new XML in place, by using the new qemu snapshot_blkdev monitor
> commands.

Excellent :)

>> Incremental backups can be done just like full backups except with an
>> API call to get a dirty blocks list.  The client only reads out those
>> dirty blocks from the snapshot.
>
> Incremental backups will need more work - qemu does not yet have the monitor
> commands for exposing which blocks are dirty.  Of course, as code is written
> for qemu, it would be nice to also be thinking about how to support that in
> libvirt, so once I do propose my XML changes for full snapshots, it would be
> nice to remember in your review to think about whether it remains extensible
> to the incremental case.

Robert Wang and I would like to help make the incremental use case
possible.  Like you say, QEMU does not have this feature yet but it
makes sense to plan together with libvirt.  Will keep you CCed on QEMU
discussions about adding this feature.

Stefan