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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list