On Sun, Jan 17, 2010 at 12:31:07PM -0500, Philip Jameson wrote:
> A little while ago I submitted a patch to add a snapshot API, but
> I was informed that it got somewhat lost in the list. I have attached
> a patch that implements this API at least for the qemu driver, and
> it also added another function for screenshots, just because it
> usually is nice to get a view of the screen with the snapshot.
Could you resubmit the virDomainTakeScreenshot() code as a separate
patch. That is quite a straightforward API addition, so we shouldn't
let snapshot discussions delay that.
> The snapshot functions just take names, as I figure it should be up
> to libvirt to figure out where the snapshots go. e.g. for qemu, they
> just get stored with the drive using qemu's built in facilities. If
> someone were using LVM, then that could be managed by libvirt, just
> like it does for qemu monitors and such. The 'list snapshots' just
> returns a list of names for now, as that's all I needed, but I think
> it would probably be best to add a struct that would be name/time.
I've been taking a look at what VMWare and VirtualBox expose in their
respective APIs for snapshotting
VMWare
- There is a tree of snapshots. ie a snapshot can be against a
previous snapshot, rather than the base image, and you can
chain them together to arbitrary depth
- Copy of the domain configuration
- Creation time
- Name
- Description
- Quiesced (ie whether the guest filesystem had been told to
flush buffers & temporarily suspend I/O to get consistent state)
- VM State (whether it was running, or off when snapshotted)
- Current snapshot - the snapshot used for current execution
VirtualBox
- There is a tree of snapshots. The current impl does not allow
full use of this, restricting to a single branch / chain.
- UUID
- Name
- Description
- Timestamp
- Online. Whether it was running or off when snapshotted
- Copy of domain configuration.
- Current snapshot - the snapshot used for current execution
So this is all alot more advanced than current capabilities in either
Xen or QEMU/KVM. To cope with the level of complexity there I think
we need to go beyond a simple 'name' in the APIs, and have a real
object + an XML schema to record the metadata.
> I don't know if it's of any use at the moment, but I needed these
> functions implemented, so I figured I'd at least submit my changes
> +int virDomainTakeSnapshot (virDomainPtr domain,
> + const char *name);
> +int virDomainRestoreSnapshot(virDomainPtr domain,
> + const char *name);
> +int virDomainDeleteSnapshot (virDomainPtr domain,
> + const char *name);
> +int virDomainListSnapshots (virDomainPtr domain,
> + char** sslist, int listsize);
So thinking about things in terms of VMWare/VirtualBox capabilities, we
probably need to expand these APIs a little further to
typedef struct _virDomainSnapshot virDomainSnapshot;
/* Take a snapshot of the current VM state */
virDomainSnapshotPtr virDomainTakeSnapshot(virDomainPtr domain,
const char *name,
unsigned int flags);
/* Query all snapshots know for a VM */
int virDomainListSnapshotNames(virDomainPtr domain,
char** names, int nameslen);
/* Get a handle to a named snapshot */
virDomainSnapshotPtr virDomainSnapshotLookupByName(virDomainPtr domain,
const char *name);
/* Set this snapshot as the current one for a domain, to be
used next time domain is started */
int virDomainSnapshotActivate(virDomainSnapshotPtr snapshot,
unsigned int flags);
/* Delete a snapshot */
enum {
VIR_DOMAIN_SNAPSHOT_DELETE_MERGE,
VIR_DOMAIN_SNAPSHOT_DELETE_DISCARD,
};
int virDomainSnapshotDelete(virDomainSnapshotPtr snapshot,
unsigned int flags);
For XML to describe the metadata, I think we want to try something
like
<domainsnapshot>
<name>XYZ</name>
<creationdate>...</creationdate>
<description>
....blah....
</description>
<state>RUNNING</state>
<domain>
<uuid>XXXXX-XXXX-XXXX-XXXX-XXXXXXXXX</uuid>
</domain>
<parent>
<name>ABC</name>
</parent>
</domainsnapshot>
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list