[libvirt] RFC: API additions for enhanced snapshot support

[Jagane Sundar]

On 7/5/2011 2:36 PM, Eric Blake wrote:
> On 07/04/2011 07:53 PM, Jagane Sundar wrote:
>> 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'.
> In the case of the current libvirt API, which makes use of the qemu
> 'savevm' monitor command (and thus is more of a checkpoint, rather than
> just disk snapshots):
>
> 'savevm' fails unless all disks associated with the guest are already
> qcow2 format.  Additionally, it creates a snapshot visible to 'qemu-img
> snapshot -l' in all associated disks, but where only the primary disk
> additionally has the state of RAM also in the image.
>
> As for the creating a snapshot commands - the proposal for
> virStorageVolSnapshotCreateXML is _solely_ for offline management of
> storage volumes.  If a storage volume is in use by a running qemu
> domain, then the only appropriate way to take an online snapshot of that
> disk (short of stopping the domain to get to the offline snapshot case)
> is to use the existing virDomainSnapshotCreateXML API instead.  And that
> API is already flexible enough to support 'whole-vm-snapshot' vs.
> 'just-a-volume-snapshot'.
>
OK. My use case is solved by virDomainSnapshotCreateXML, so long as this 
function
is enhanced to support disk-only snapshots.

> information to explicitly specify the filename to use on the created
> external snapshot file (rather than letting libvirt generate the
> snapshot name).  That is, provide at least one<disk>  element, and you
> now have fine-grained control over which volumes get a snapshot (or even
> how that snapshot is created).
>
>> 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.
> There's a third - the qcow2 internal snapshot:
>
> - Base file contains both the snapshot and the delta.
>
>> 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?
> Yes, there are already some read-only XML elements in the
> <domainsnapshot>  XML (that is, libvirt ignores or rejects them if you
> pass them to virDomainSnapshotCreateXML, but virDomainSnapshotGetXMLDesc
> will list those additional elements to give you more details about the
> snapshot); having a sub-element to state whether the snapshot is
> backing-file based (original is now treated as read-only, and
> modifications affect the snapshot) or COW based (original and backup
> share all blocks to begin with, but as original get modified, the
> read-only backup has more unique blocks).
>

Sounds fine.

>> 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, we already had a discussion about the utility of being able to
> expose how much of an image is directly contained within a file, vs.
> being pulled in from a backing file (which can also be read as how much
> of an image is dirty compared to the state of a snapshot).  See Daniel's
> earlier thoughts:
> https://www.redhat.com/archives/libvir-list/2011-April/msg00555.html
>
You are right. The thread that you point to is indeed more relevant to 
my use
case.

I missed that thread of conversation. However, I do not see a conclusion 
to the
discussion. My position is similar to Daniel's - I would find an API 
that exposes
'logical allocation information' (to quote Daniel) useful. His use case 
is for COR
image streaming. My use case is for making incremental backups. The backup
program wants to know which blocks were modified since the last backup
was taken.

Thanks,
Jagane