[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]