[libvirt] RFC: API additions for enhanced snapshot support

[Stefan Hajnoczi]

On Tue, Jul 5, 2011 at 2:53 AM, Jagane Sundar <jagane at sundar.org> wrote:
>> /* Create a snapshot of a storage volume.  XML is optional, if non-NULL,
>>  * it would be a new top-level element<volsnapshot>  which is similar to
>>  * the top-level<domainsnapshot>  for virDomainSnapshotCreateXML, to
>>  * specify name and description. Flags is 0 for now.
>>  */
>> virStorageVolSnapshotPtr virDomainSnapshotCreateXML(
>>     virStorageVolPtr vol, const char *xml, unsigned int flags);
>>
> There are two types of snapshots that I am aware of:
> - Base file is left unmodified after snapshot, snapshot file is created and
> modified. e.g. qcow2 (I think)

More detail on this approach as implemented by QEMU's snapshot_blkdev:

Create snapshot.qcow2 with base.img as backing file.  base.img is now
read-only and can be accessed as a "snapshot".  All writes go to
snapshot.qcow2.

When the snapshot is no longer needed it is necessary to merge the COW
data back into base.img before deleting snapshot.qcow2.  This merge
has not been implemented in QEMU yet.

> - Base file continues to be modified. The snapshot file gets COW blocks
> copied into it. e.g. LVM, Livebackup, etc.
>
> Can we enhance the libvirt API to indicate what type of snapshot is desired.
> Also, when a snapshot is listed, can we try and describe it as one kind or
> the other?

I think the snapshot mechanism will depend on your storage backend.
If the disk image is an LVM volume, then it is natural for the
snapshot to be an LVM snapshot.  If the disk image is a qcow2 file,
then it is natural for the snapshot be a QEMU snapshot_blkdev
snapshot.

Also, it is often not possible to mix these snapshot mechanisms.  For
example, LVM snapshots don't work on qcow2 image files.

Does the application have to be aware of which snapshotting approach
is used by the backend?  Perhaps there are a few cases where it is
technically possible to mix-and-match but it just seems to expose
complexity without much gain.

Put another way: "If a storage backend fundamentally doesn't support
snapshotting the you like, use a different backend".

> There is no facility in the API to track dirty bitmaps. Suppose a disk
> format or qemu proper has the ability to maintain a dirty bitmap of
> blocks(or clusters) modified since some event (time in ms, perhaps). I would
> like libvirt to provide a function such as:
>
> /*
> * returns NULL if the underlying block driver does not support
> * maintaining a dirty bitmap. If it does support a dirty bitmap,
> * the driver returns an opaque object that represents the time
> * since which this dirty bitmap is valid.
> *
> * Used by incremental backup programs to determine if qemu
> * has a bitmap of blocks that were dirtied since the last time
> * a backup was taken.
> */
> virStorageDirtyBitmapTimeOpaquePtr
> virStorageVolDirtyBitmapPresent(virStorageVolPtr vol)

Yes, dirty bitmap support is important.  This will make backup much
more efficient on storage backends that support it.

For QEMU image files it will be possible to provide dirty block
information in the future.  btrfs and a SAN appliance that I have
looked both have mechanisms that could be used to provide dirty block
tracking.

Stefan