[libvirt] RFC: API additions for enhanced snapshot support

[Jagane Sundar]

Thanks for looping me in, Stefan.

> Does each volume have its own independent snapshot namespace?  It may
> be wise to document that snapshot namespaces are *not* independent
> because storage backends may not be able to provide these semantics.
>
There is a need for 'just-a-volume-snapshot', and for a 'whole-vm-snapshot'.
The 'whole-vm-snapshot' can possibly be collection of 
'just-a-volume-snapshot'.
>> /* 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);
>> [For qcow2, this would be implemented with 'qemu-img snapshot -c',
>> similar to what virDomainSnapshotXML already does on inactive domains.
>> Later, we can add LVM and btrfs support, or even allow full file copies
>> of any file type.  Also in the future, we could enhance XML to take a
>> new element that describes a relationship between the name of the
>> original and of the snapshot, in the case where a new filename has to be
>> created to complete the snapshot process.]
> I found this formatting quite hard to read.  Something along these
> lines would be easier to parse visually:
>
> /* 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)
- 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?

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)

Thanks,
Jagane