Re: [libvirt] RFC: API additions for enhanced snapshot support

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'.

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).

> 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