[libvirt] [RFC]: Snapshot API v3

Matthias Bolte matthias.bolte at googlemail.com
Tue Mar 30 20:52:55 UTC 2010


2010/3/30 Jiri Denemark <jdenemar at redhat.com>:
> Hi.
>
> ...
>> /* NOTE: struct _virDomainSnapshot is a private structure, ala
>>  * struct _virDomain.
>>  */
>> typedef struct _virDomainSnapshot virDomainSnapshot;
>>
>> /* Take a snapshot of the current VM state.  Throws an error if
>>  * the VM is not currently running */
>> virDomainSnapshotPtr virDomainSnapshotCreateXML(virDomainPtr domain,
>>                                                 const char *xmlDesc,
>>                                                 unsigned int flags);
>
> This is probably a leftover from previous versions, but... why do we restrict
> this API only for running VMs?
>

Yep, if a domain it not running you'll just get a disk snapshot
without a memory snapshot.

> ...
>> Possible issues:
>> 1)  I don't see a way to support "managed" save/restore and snapshotting with
>> this API.  I think we'll have to have a separate API for managed save/restore.
>> 2)  What is the semantic for deleting snapshots from a running domain?
>> Virtualbox seems to not allow you to manipulate snapshots while the domain is
>> running.  Qemu does allow this, but it's currently unclear what the exact
>> semantics are.  VMware seems to allow manipulation of snapshots while the
>> domain is running.
>> 3)  Do we need a snapshot UUID?  Virtualbox allows you to have multiple snapshots
>> with the same name, differentiated by UUID.  Confusingly, they also have a
>> "FindByName" method that returns the first depth-first search snapshot that matches
>> a given name.  For qemu, if you specify the same name twice it overwrites the previous
>> one with the new one.  I don't know what ESX does here.
>
> Libvirt uses/generates UUIDs for almost everything (networks, vms, ...) so it
> might be more consistent to have UUID in snapshot as well.

ESX snapshots don't have a UUID, and there is no easy way to store an
UUID-to-snapshot mapping.

Matthias




More information about the libvir-list mailing list