[libvirt] [PATCH v2 0/9] Incremental Backup API additions

The following is the latest version of my API proposal for incremental backups. I have even more work-in-progress patches on top of these: https://repo.or.cz/libvirt/ericb.git which I am slowly improving to be more in line with my thread on the overview of the API usage: https://www.redhat.com/archives/libvir-list/2018-October/msg00217.html But I am fairly satisfied that the API as presented is sufficient for everything I have still been implementing in the qemu driver, and that even when qemu is slightly tweaked (such as dropping the x- prefix on various commands, or maybe adding a new command to make it easier to compute the estimated size of the union of several bitmaps), those changes will be limited to the src/qemu directory rather than affecting the API. Since I will be demonstrating the use of this API at the KVM Forum, I would really like a decision on whether we can commit the API into libvirt now, even if we have to wait for the qemu implementation of the API until qemu stabilizes its interfaces (also, having the libvirt API in place gives qemu an incentive to drop the x- prefix sooner rather than later). That in turn implies that I need code reviews; John Ferlan started reviewing v1, but mostly focused on the documentation grammar: https://www.redhat.com/archives/libvir-list/2018-June/msg01066.html The following gives an idea of how this series has changed since June (in part due to rebases, in part due to documentation improvements): The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively 001/9:[0050] [FC] 'snapshots: Avoid term 'checkpoint' for full system snapshot' 002/9:[down] 'domain_conf: Expose virDomainStorageNetworkParseHost' 003/9:[0342] [FC] 'backup: Document nuances between different state capture APIs' 004/9:[0007] [FC] 'backup: Introduce virDomainCheckpointPtr' 005/9:[0100] [FC] 'backup: Document new XML for backups' 006/9:[0042] [FC] 'backup: Introduce virDomainCheckpoint APIs' 007/9:[0035] [FC] 'backup: Introduce virDomainBackup APIs' 008/9:[----] [--] 'backup: Add new domain:checkpoint access control' 009/9:[0039] [FC] 'backup: Implement backup APIs for remote driver' Eric Blake (9): snapshots: Avoid term 'checkpoint' for full system snapshot domain_conf: Expose virDomainStorageNetworkParseHost backup: Document nuances between different state capture APIs backup: Introduce virDomainCheckpointPtr backup: Document new XML for backups backup: Introduce virDomainCheckpoint APIs backup: Introduce virDomainBackup APIs backup: Add new domain:checkpoint access control backup: Implement backup APIs for remote driver include/libvirt/virterror.h | 6 +- src/util/virerror.c | 21 +- include/libvirt/libvirt-domain-checkpoint.h | 177 ++++ include/libvirt/libvirt-domain-snapshot.h | 2 +- include/libvirt/libvirt-domain.h | 14 +- include/libvirt/libvirt.h | 3 +- src/access/viraccessperm.h | 8 +- src/conf/domain_conf.h | 2 + src/datatypes.h | 31 +- src/driver-hypervisor.h | 74 +- docs/Makefile.am | 3 + docs/apibuild.py | 2 + docs/docs.html.in | 9 +- docs/domainstatecapture.html.in | 314 +++++++ docs/format.html.in | 1 + docs/formatcheckpoint.html.in | 285 ++++++ docs/formatsnapshot.html.in | 33 +- docs/index.html.in | 3 +- docs/schemas/domainbackup.rng | 185 ++++ docs/schemas/domaincheckpoint.rng | 94 ++ libvirt.spec.in | 3 + mingw-libvirt.spec.in | 6 + po/POTFILES | 1 + src/Makefile.am | 2 + src/access/viraccessperm.c | 5 +- src/conf/domain_conf.c | 43 +- src/conf/snapshot_conf.c | 4 +- src/datatypes.c | 62 +- src/libvirt-domain-checkpoint.c | 936 +++++++++++++++++++ src/libvirt-domain-snapshot.c | 7 +- src/libvirt-domain.c | 8 +- src/libvirt_private.syms | 3 + src/libvirt_public.syms | 23 + src/qemu/qemu_driver.c | 12 +- src/remote/remote_daemon_dispatch.c | 15 + src/remote/remote_driver.c | 33 +- src/remote/remote_protocol.x | 240 ++++- src/remote_protocol-structs | 129 +++ src/rpc/gendispatch.pl | 32 +- tests/Makefile.am | 6 +- tests/domainbackupxml2xmlin/backup-pull.xml | 9 + tests/domainbackupxml2xmlin/backup-push.xml | 9 + tests/domainbackupxml2xmlin/empty.xml | 1 + tests/domainbackupxml2xmlout/backup-pull.xml | 9 + tests/domainbackupxml2xmlout/backup-push.xml | 9 + tests/domainbackupxml2xmlout/empty.xml | 7 + tests/domaincheckpointxml2xmlin/empty.xml | 1 + tests/domaincheckpointxml2xmlin/sample.xml | 7 + tests/domaincheckpointxml2xmlout/empty.xml | 10 + tests/domaincheckpointxml2xmlout/sample.xml | 16 + tests/virschematest.c | 4 + tools/virsh-domain.c | 3 +- tools/virsh-snapshot.c | 2 +- tools/virsh.pod | 14 +- 54 files changed, 2846 insertions(+), 92 deletions(-) create mode 100644 include/libvirt/libvirt-domain-checkpoint.h create mode 100644 docs/domainstatecapture.html.in create mode 100644 docs/formatcheckpoint.html.in create mode 100644 docs/schemas/domainbackup.rng create mode 100644 docs/schemas/domaincheckpoint.rng create mode 100644 src/libvirt-domain-checkpoint.c create mode 100644 tests/domainbackupxml2xmlin/backup-pull.xml create mode 100644 tests/domainbackupxml2xmlin/backup-push.xml create mode 100644 tests/domainbackupxml2xmlin/empty.xml create mode 100644 tests/domainbackupxml2xmlout/backup-pull.xml create mode 100644 tests/domainbackupxml2xmlout/backup-push.xml create mode 100644 tests/domainbackupxml2xmlout/empty.xml create mode 100644 tests/domaincheckpointxml2xmlin/empty.xml create mode 100644 tests/domaincheckpointxml2xmlin/sample.xml create mode 100644 tests/domaincheckpointxml2xmlout/empty.xml create mode 100644 tests/domaincheckpointxml2xmlout/sample.xml -- 2.17.1

Upcoming patches plan to introduce virDomainCheckpointPtr as a new object for use in incremental backups, along with documentation on how incremental backups differ from snapshots. But first, we need to rename any existing mention of a 'system checkpoint' to instead be a 'full system snapshot', so that we aren't overloading the term checkpoint. Signed-off-by: Eric Blake <eblake@redhat.com> --- v2: wording improvements based on review --- include/libvirt/libvirt-domain-snapshot.h | 2 +- docs/formatsnapshot.html.in | 31 +++++++++++------------ src/conf/snapshot_conf.c | 4 +-- src/libvirt-domain-snapshot.c | 7 ++--- src/qemu/qemu_driver.c | 12 ++++----- tools/virsh-snapshot.c | 2 +- tools/virsh.pod | 14 +++++----- 7 files changed, 36 insertions(+), 36 deletions(-) diff --git a/include/libvirt/libvirt-domain-snapshot.h b/include/libvirt/libvirt-domain-snapshot.h index 20771f9b1e..00954a0d3a 100644 --- a/include/libvirt/libvirt-domain-snapshot.h +++ b/include/libvirt/libvirt-domain-snapshot.h @@ -60,7 +60,7 @@ typedef enum { VIR_DOMAIN_SNAPSHOT_CREATE_HALT = (1 << 3), /* Stop running guest after snapshot */ VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY = (1 << 4), /* disk snapshot, not - system checkpoint */ + full system */ VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT = (1 << 5), /* reuse any existing external files */ VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE = (1 << 6), /* use guest agent to diff --git a/docs/formatsnapshot.html.in b/docs/formatsnapshot.html.in index fbbecfd242..c60b4fb7c9 100644 --- a/docs/formatsnapshot.html.in +++ b/docs/formatsnapshot.html.in @@ -33,7 +33,7 @@ resume in a consistent state; but if the disks are modified externally in the meantime, this is likely to lead to data corruption.</dd> - <dt>system checkpoint</dt> + <dt>full system</dt> <dd>A combination of disk snapshots for all disks as well as VM memory state, which can be used to resume the guest from where it left off with symptoms similar to hibernation (that is, TCP @@ -55,11 +55,12 @@ as <code>virDomainSaveImageGetXMLDesc()</code> to work with those files. </p> - <p>System checkpoints are created - by <code>virDomainSnapshotCreateXML()</code> with no flags, and + <p>Full system snapshots are created + by <code>virDomainSnapshotCreateXML()</code> with no flags, while disk snapshots are created by the same function with - the <code>VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY</code> flag; in - both cases, they are restored by + the <code>VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY</code> + flag. Regardless of the flags provided, restoration of the + snapshot is handled by the <code>virDomainRevertToSnapshot()</code> function. For these types of snapshots, libvirt tracks each snapshot as a separate <code>virDomainSnapshotPtr</code> object, and maintains @@ -128,13 +129,10 @@ what file name is created in an external snapshot. On output, this is fully populated to show the state of each disk in the snapshot, including any properties that were generated by the - hypervisor defaults. For system checkpoints, this field is - ignored on input and omitted on output (a system checkpoint - implies that all disks participate in the snapshot process, - and since the current implementation only does internal system - checkpoints, there are no extra details to add); a future - release may allow the use of <code>disks</code> with a system - checkpoint. This element has a list of <code>disk</code> + hypervisor defaults. For full system snapshots, this field is + ignored on input and omitted on output (a full system snapshot + implies that all disks participate in the snapshot process). + This element has a list of <code>disk</code> sub-elements, describing anywhere from zero to all of the disks associated with the domain. <span class="since">Since 0.9.5</span> @@ -206,11 +204,12 @@ </dd> <dt><code>state</code></dt> <dd>The state of the domain at the time this snapshot was taken. - If the snapshot was created as a system checkpoint, then this - is the state of the domain at that time; when the domain is + If a full system snapshot was created, then this + is the state of the domain at that time. When the domain is reverted to this snapshot, the domain's state will default to - whatever is in this field unless additional flags are passed - to <code>virDomainRevertToSnapshot()</code>. Additionally, + this state, unless overridden + by <code>virDomainRevertToSnapshot()</code> flags to revert to + a running or paused state. Additionally, this field can be the value "disk-snapshot" (<span class="since">since 0.9.5</span>) when it represents only a disk snapshot (no VM memory state), and reverting to this diff --git a/src/conf/snapshot_conf.c b/src/conf/snapshot_conf.c index adba149241..f89048e3f1 100644 --- a/src/conf/snapshot_conf.c +++ b/src/conf/snapshot_conf.c @@ -1302,8 +1302,8 @@ virDomainSnapshotRedefinePrep(virDomainPtr domain, if ((other->def->state == VIR_DOMAIN_DISK_SNAPSHOT) != (def->state == VIR_DOMAIN_DISK_SNAPSHOT)) { virReportError(VIR_ERR_INVALID_ARG, - _("cannot change between disk snapshot and " - "system checkpoint in snapshot %s"), + _("cannot change between disk only and " + "full system in snapshot %s"), def->name); goto cleanup; } diff --git a/src/libvirt-domain-snapshot.c b/src/libvirt-domain-snapshot.c index 100326a5e7..1cc0188928 100644 --- a/src/libvirt-domain-snapshot.c +++ b/src/libvirt-domain-snapshot.c @@ -105,8 +105,9 @@ virDomainSnapshotGetConnect(virDomainSnapshotPtr snapshot) * contained in xmlDesc. * * If @flags is 0, the domain can be active, in which case the - * snapshot will be a system checkpoint (both disk state and runtime - * VM state such as RAM contents), where reverting to the snapshot is + * snapshot will be a full system snapshot (capturing both disk state, + * and runtime VM state such as RAM contents), where reverting to the + * snapshot is * the same as resuming from hibernation (TCP connections may have * timed out, but everything else picks up where it left off); or * the domain can be inactive, in which case the snapshot includes @@ -149,7 +150,7 @@ virDomainSnapshotGetConnect(virDomainSnapshotPtr snapshot) * is not paused while creating the snapshot. This increases the size * of the memory dump file, but reduces downtime of the guest while * taking the snapshot. Some hypervisors only support this flag during - * external checkpoints. + * external snapshots. * * If @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY, then the * snapshot will be limited to the disks described in @xmlDesc, and no diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index a52e2495d5..707773c1e3 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -2153,7 +2153,7 @@ qemuDomainReset(virDomainPtr dom, unsigned int flags) } -/* Count how many snapshots in a set are external snapshots or checkpoints. */ +/* Count how many snapshots in a set are external snapshots. */ static int qemuDomainSnapshotCountExternal(void *payload, const void *name ATTRIBUTE_UNUSED, @@ -14713,7 +14713,7 @@ qemuDomainSnapshotPrepare(virDomainObjPtr vm, if ((def->memory == VIR_DOMAIN_SNAPSHOT_LOCATION_INTERNAL && !found_internal) || (found_internal && forbid_internal)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("internal snapshots and checkpoints require all " + _("internal and full system snapshots require all " "disks to be selected for snapshot")); goto cleanup; } @@ -15163,7 +15163,7 @@ qemuDomainSnapshotCreateActiveExternal(virQEMUDriverPtr driver, if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_PMSUSPENDED) { pmsuspended = true; } else if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_RUNNING) { - /* For external checkpoints (those with memory), the guest + /* For full system external snapshots (those with memory), the guest * must pause (either by libvirt up front, or by qemu after * _LIVE converges). */ if (memory) @@ -15391,7 +15391,7 @@ qemuDomainSnapshotCreateXML(virDomainPtr domain, redefine)) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", _("live snapshot creation is supported only " - "with external checkpoints")); + "during full system snapshots")); goto cleanup; } @@ -15511,12 +15511,12 @@ qemuDomainSnapshotCreateXML(virDomainPtr domain, } else if (virDomainObjIsActive(vm)) { if (flags & VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY || snap->def->memory == VIR_DOMAIN_SNAPSHOT_LOCATION_EXTERNAL) { - /* external checkpoint or disk snapshot */ + /* external full system or disk snapshot */ if (qemuDomainSnapshotCreateActiveExternal(driver, vm, snap, flags) < 0) goto endjob; } else { - /* internal checkpoint */ + /* internal full system */ if (qemuDomainSnapshotCreateActiveInternal(driver, vm, snap, flags) < 0) goto endjob; diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c index 73861957ba..7b340162f3 100644 --- a/tools/virsh-snapshot.c +++ b/tools/virsh-snapshot.c @@ -1427,7 +1427,7 @@ static const vshCmdOptDef opts_snapshot_list[] = { }, {.name = "active", .type = VSH_OT_BOOL, - .help = N_("filter by snapshots taken while active (system checkpoints)") + .help = N_("filter by snapshots taken while active (full system snapshots)") }, {.name = "disk-only", .type = VSH_OT_BOOL, diff --git a/tools/virsh.pod b/tools/virsh.pod index 86c041d575..58ab9a090b 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -4490,8 +4490,8 @@ If I<--halt> is specified, the domain will be left in an inactive state after the snapshot is created. If I<--disk-only> is specified, the snapshot will only include disk -state rather than the usual system checkpoint with vm state. Disk -snapshots are faster than full system checkpoints, but reverting to a +content rather than the usual full system snapshot with vm state. Disk +snapshots are captured faster than full system snapshots, but reverting to a disk snapshot may require fsck or journal replays, since it is like the disk state at the point when the power cord is abruptly pulled; and mixing I<--halt> and I<--disk-only> loses any data that was not @@ -4530,10 +4530,10 @@ this. If this flag is not specified, then some hypervisors may fail after partially performing the action, and B<dumpxml> must be used to see whether any partial changes occurred. -If I<--live> is specified, libvirt takes the snapshot (checkpoint) while +If I<--live> is specified, libvirt takes the snapshot while the guest is running. Both disk snapshot and domain memory snapshot are taken. This increases the size of the memory image of the external -checkpoint. This is currently supported only for external checkpoints. +snapshot. This is currently supported only for full system external snapshots. Existence of snapshot metadata will prevent attempts to B<undefine> a persistent domain. However, for transient domains, snapshot @@ -4553,7 +4553,7 @@ Otherwise, if I<--halt> is specified, the domain will be left in an inactive state after the snapshot is created, and if I<--disk-only> is specified, the snapshot will not include vm state. -The I<--memspec> option can be used to control whether a checkpoint +The I<--memspec> option can be used to control whether a full system snapshot is internal or external. The I<--memspec> flag is mandatory, followed by a B<memspec> of the form B<[file=]name[,snapshot=type]>, where type can be B<no>, B<internal>, or B<external>. To include a literal @@ -4561,7 +4561,7 @@ comma in B<file=name>, escape it with a second comma. I<--memspec> cannot be used together with I<--disk-only>. The I<--diskspec> option can be used to control how I<--disk-only> and -external checkpoints create external files. This option can occur +external full system snapshots create external files. This option can occur multiple times, according to the number of <disk> elements in the domain xml. Each <diskspec> is in the form B<disk[,snapshot=type][,driver=type][,file=name]>. A I<diskspec> @@ -4601,7 +4601,7 @@ see whether any partial changes occurred. If I<--live> is specified, libvirt takes the snapshot while the guest is running. This increases the size of the memory image of the external -checkpoint. This is currently supported only for external checkpoints. +snapshot. This is currently supported only for external full system snapshots. =item B<snapshot-current> I<domain> {[I<--name>] | [I<--security-info>] | [I<snapshotname>]} -- 2.17.1

An upcoming patch wants to reuse XML parsing of both unix and tcp network host descriptions in the context of setting up a backup NBD server. Make that easier by refactoring the existing parser. Signed-off-by: Eric Blake <eblake@redhat.com> --- src/conf/domain_conf.h | 2 ++ src/conf/domain_conf.c | 43 ++++++++++++++++++++-------------------- src/libvirt_private.syms | 1 + 3 files changed, 25 insertions(+), 21 deletions(-) diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index e30a4b2fe7..785786c9b9 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -3143,6 +3143,8 @@ int virDomainDiskInsert(virDomainDefPtr def, ATTRIBUTE_RETURN_CHECK; void virDomainDiskInsertPreAlloced(virDomainDefPtr def, virDomainDiskDefPtr disk); +int virDomainStorageNetworkParseHost(xmlNodePtr hostnode, + virStorageNetHostDefPtr host); int virDomainDiskDefAssignAddress(virDomainXMLOptionPtr xmlopt, virDomainDiskDefPtr def, const virDomainDef *vmdef); diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 9911d56130..0fd6004c48 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -7122,23 +7122,21 @@ virDomainHostdevSubsysPCIDefParseXML(xmlNodePtr node, } -static int +int virDomainStorageNetworkParseHost(xmlNodePtr hostnode, - virStorageNetHostDefPtr *hosts, - size_t *nhosts) + virStorageNetHostDefPtr host) { int ret = -1; char *transport = NULL; char *port = NULL; - virStorageNetHostDef host; - memset(&host, 0, sizeof(host)); - host.transport = VIR_STORAGE_NET_HOST_TRANS_TCP; + memset(host, 0, sizeof(*host)); + host->transport = VIR_STORAGE_NET_HOST_TRANS_TCP; /* transport can be tcp (default), unix or rdma. */ if ((transport = virXMLPropString(hostnode, "transport"))) { - host.transport = virStorageNetHostTransportTypeFromString(transport); - if (host.transport < 0) { + host->transport = virStorageNetHostTransportTypeFromString(transport); + if (host->transport < 0) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("unknown protocol transport type '%s'"), transport); @@ -7146,17 +7144,17 @@ virDomainStorageNetworkParseHost(xmlNodePtr hostnode, } } - host.socket = virXMLPropString(hostnode, "socket"); + host->socket = virXMLPropString(hostnode, "socket"); - if (host.transport == VIR_STORAGE_NET_HOST_TRANS_UNIX && - host.socket == NULL) { + if (host->transport == VIR_STORAGE_NET_HOST_TRANS_UNIX && + host->socket == NULL) { virReportError(VIR_ERR_XML_ERROR, "%s", _("missing socket for unix transport")); goto cleanup; } - if (host.transport != VIR_STORAGE_NET_HOST_TRANS_UNIX && - host.socket != NULL) { + if (host->transport != VIR_STORAGE_NET_HOST_TRANS_UNIX && + host->socket != NULL) { virReportError(VIR_ERR_XML_ERROR, _("transport '%s' does not support " "socket attribute"), @@ -7164,26 +7162,24 @@ virDomainStorageNetworkParseHost(xmlNodePtr hostnode, goto cleanup; } - if (host.transport != VIR_STORAGE_NET_HOST_TRANS_UNIX) { - if (!(host.name = virXMLPropString(hostnode, "name"))) { + if (host->transport != VIR_STORAGE_NET_HOST_TRANS_UNIX) { + if (!(host->name = virXMLPropString(hostnode, "name"))) { virReportError(VIR_ERR_XML_ERROR, "%s", _("missing name for host")); goto cleanup; } if ((port = virXMLPropString(hostnode, "port"))) { - if (virStringParsePort(port, &host.port) < 0) + if (virStringParsePort(port, &host->port) < 0) goto cleanup; } } - if (VIR_APPEND_ELEMENT(*hosts, *nhosts, host) < 0) - goto cleanup; - ret = 0; cleanup: - virStorageNetHostDefClear(&host); + if (ret < 0) + virStorageNetHostDefClear(host); VIR_FREE(transport); VIR_FREE(port); return ret; @@ -7200,9 +7196,14 @@ virDomainStorageNetworkParseHosts(xmlNodePtr node, for (child = node->children; child; child = child->next) { if (child->type == XML_ELEMENT_NODE && virXMLNodeNameEqual(child, "host")) { + virStorageNetHostDef host; - if (virDomainStorageNetworkParseHost(child, hosts, nhosts) < 0) + if (virDomainStorageNetworkParseHost(child, &host) < 0) return -1; + if (VIR_APPEND_ELEMENT(*hosts, *nhosts, host) < 0) { + virStorageNetHostDefClear(&host); + return -1; + } } } diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 335210c31d..eb1ad579d9 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -545,6 +545,7 @@ virDomainStateReasonFromString; virDomainStateReasonToString; virDomainStateTypeFromString; virDomainStateTypeToString; +virDomainStorageNetworkParseHost; virDomainStorageSourceFormat; virDomainStorageSourceParse; virDomainTaintTypeFromString; -- 2.17.1

Upcoming patches will add support for incremental backups via a new API; but first, we need a landing page that gives an overview of capturing various pieces of guest state, and which APIs are best suited to which tasks. Signed-off-by: Eric Blake <eblake@redhat.com> --- v2: wording improvements based on review --- docs/docs.html.in | 5 + docs/domainstatecapture.html.in | 314 ++++++++++++++++++++++++++++++++ docs/formatsnapshot.html.in | 2 + 3 files changed, 321 insertions(+) create mode 100644 docs/domainstatecapture.html.in diff --git a/docs/docs.html.in b/docs/docs.html.in index 40e0e3b82e..4c46b74980 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -120,6 +120,11 @@ <dt><a href="secureusage.html">Secure usage</a></dt> <dd>Secure usage of the libvirt APIs</dd> + + <dt><a href="domainstatecapture.html">Domain state + capture</a></dt> + <dd>Comparison between different methods of capturing domain + state</dd> </dl> </div> diff --git a/docs/domainstatecapture.html.in b/docs/domainstatecapture.html.in new file mode 100644 index 0000000000..f7f2fe0b98 --- /dev/null +++ b/docs/domainstatecapture.html.in @@ -0,0 +1,314 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + + <h1>Domain state capture using Libvirt</h1> + + <ul id="toc"></ul> + + <p> + In order to aid application developers to choose which + operations best suit their needs, this page compares the + different means for capturing state related to a domain managed + by libvirt. + </p> + + <p> + The information here is primarily geared towards capturing the + state of an active domain. Capturing the state of an inactive + domain essentially amounts to copying the contents of guest + disks, followed by a fresh boot with disks restored to that + state. Some of the topics presented below may relate to inactive + state collection, but it is not the primary focus of this page. + </p> + + <h2><a id="definitions">State capture trade-offs</a></h2> + + <p>One of the features made possible with virtual machines is live + migration -- transferring all state related to the guest from + one host to another with minimal interruption to the guest's + activity. In this case, state includes domain memory (including + register and device contents), and domain storage (whether the + guest's view of the disks are backed by local storage on the + host, or by the hypervisor accessing shared storage over a + network). A clever observer will then note that if all state is + available for live migration, then there is nothing stopping a + user from saving some or all of that state at a given point of + time in order to be able to later rewind guest execution back to + the state it previously had. The astute reader will also realize + that state capture at any level requires that the data must be + stored and managed by some mechanism. This processing might fit + in a single file, or more likely require a chain of related + files, and may require synchronization with third-party tools + built around managing the amount of data resulting from + capturing the state of multiple guests that each use multiple + disks. + </p> + + <p> + There are several libvirt APIs associated with capturing the + state of a guest, which can later be used to rewind that guest + to the conditions it was in earlier. The following is a list of + trade-offs and differences between the various facets that + affect capturing domain state for active domains: + </p> + + <dl> + <dt>Duration</dt> + <dd>Capturing state can be a lengthy process, so while the + captured state ideally represents an atomic point in time + correpsonding to something the guest was actually executing, + capturing state tends to focus on minimizing guest downtime + while performing the rest of the state capture in parallel + with guest execution. Some interfaces require up-front + preparation (the state captured is not complete until the API + ends, which may be some time after the command was first + started), while other interfaces track the state when the + command was first issued, regardless of the time spent in + capturing the rest of the state. Also, time spent in state + capture may be longer than the time required for live + migration, when state must be duplicated rather than shared. + </dd> + + <dt>Amount of state</dt> + <dd>For an online guest, there is a choice between capturing the + guest's memory (all that is needed during live migration when + the storage is already shared between source and destination), + the guest's disk state (all that is needed if there are no + pending guest I/O transactions that would be lost without the + corresponding memory state), or both together. Reverting to + partial state may still be viable, but typically, booting from + captured disk state without corresponding memory is comparable + to rebooting a machine that had power cut before I/O could be + flushed. Guests may need to use proper journaling methods to + avoid problems when booting from partial state. + </dd> + + <dt>Quiescing of data</dt> + <dd>Even if a guest has no pending I/O, capturing disk state may + catch the guest at a time when the contents of the disk are + inconsistent. Cooperating with the guest to perform data + quiescing is an optional step to ensure that captured disk + state is fully consistent without requiring additional memory + state, rather than just crash-consistent. But guest + cooperation may also have time constraints, where the guest + can rightfully panic if there is too much downtime while I/O + is frozen. + </dd> + + <dt>Quantity of files</dt> + <dd>When capturing state, some approaches store all state within + the same file (internal), while others expand a chain of + related files that must be used together (external), for more + files that a management application must track. + </dd> + + <dt>Impact to guest definition</dt> + <dd>Capturing state may require temporary changes to the guest + definition, such as associating new files into the domain + definition. While state capture should never impact the + running guest, a change to the domain's active XML may have + impact on other host operations being performed on the domain. + </dd> + + <dt>Third-party integration</dt> + <dd>When capturing state, there are tradeoffs to how much of the + process must be done directly by the hypervisor, and how much + can be off-loaded to third-party software. Since capturing + state is not instantaneous, it is essential that any + third-party integration see consistent data even if the + running guest continues to modify that data after the point in + time of the capture.</dd> + + <dt>Full vs. incremental</dt> + <dd>When periodically repeating the action of state capture, it + is useful to minimize the amount of state that must be + captured by exploiting the relation to a previous capture, + such as focusing only on the portions of the disk that the + guest has modified in the meantime. Some approaches are able + to take advantage of checkpoints to provide an incremental + backup, while others are only capable of a full backup even if + that means re-capturing unchanged portions of the disk.</dd> + + <dt>Local vs. remote</dt> + <dd>Domains that completely use remote storage may only need + some mechanism to keep track of guest memory state while using + external means to manage storage. Still, hypervisor and guest + cooperation to ensure points in time when no I/O is in flight + across the network can be important for properly capturing + disk state.</dd> + + <dt>Network latency</dt> + <dd>Whether it's domain storage or saving domain state into + remote storage, network latency has an impact on snapshot + data. Having dedicated network capacity, bandwidth, or quality + of service levels may play a role, as well as planning for how + much of the backup process needs to be local.</dd> + </dl> + + <p> + An example of the various facets in action is migration of a + running guest. In order for the guest to be able to resume on + the destination at the same place it left off at the source, the + hypervisor has to get to a point where execution on the source + is stopped, the last remaining changes occurring since the + migration started are then transferred, and the guest is started + on the target. The management software thus must keep track of + the starting point and any changes since the starting + point. These last changes are often referred to as dirty page + tracking or dirty disk block bitmaps. At some point in time + during the migration, the management software must freeze the + source guest, transfer the dirty data, and then start the guest + on the target. This period of time must be minimal. To minimize + overall migration time, one is advised to use a dedicated + network connection with a high quality of service. Alternatively + saving the current state of the running guest can just be a + point in time type operation which doesn't require updating the + "last vestiges" of state prior to writing out the saved state + file. The state file is the point in time of whatever is current + and may contain incomplete data which if used to restart the + guest could cause confusion or problems because some operation + wasn't completed depending upon where in time the operation was + commenced. + </p> + + <h2><a id="apis">State capture APIs</a></h2> + <p>With those definitions, the following libvirt APIs related to + state capture have these properties:</p> + <dl> + <dt>virDomainManagedSave</dt> + <dd>This API saves guest memory, with libvirt managing all of + the saved state, then stops the guest. While stopped, the + disks can be copied by a third party. However, since any + subsequent restart of the guest by libvirt API will restore + the memory state (which typically only works if the disk state + is unchanged in the meantime), and since it is not possible to + get at the memory state that libvirt is managing, this is not + viable as a means for rolling back to earlier saved states, + but is rather more suited to situations such as suspending a + guest prior to rebooting the host in order to resume the guest + when the host is back up. This API also has a drawback of + potentially long guest downtime, and therefore does not lend + itself well to live backups.</dd> + + <dt>virDomainSave</dt> + <dd>This API is similar to virDomainManagedSave(), but moves the + burden on managing the stored memory state to the user. As + such, the user can now couple saved state with copies of the + disks to perform a revert to an arbitrary earlier saved state. + However, changing who manages the memory state does not change + the drawback of potentially long guest downtime when capturing + state.</dd> + + <dt>virDomainSnapshotCreateXML()</dt> + <dd>This API wraps several approaches for capturing guest state, + with a general premise of creating a snapshot (where the + current guest resources are frozen in time and a new wrapper + layer is opened for tracking subsequent guest changes). It + can operate on both offline and running guests, can choose + whether to capture the state of memory, disk, or both when + used on a running guest, and can choose between internal and + external storage for captured state. However, it is geared + towards post-event captures (when capturing both memory and + disk state, the disk state is not captured until all memory + state has been collected first). Using QEMU as the + hypervisor, internal snapshots currently have lengthy downtime + that is incompatible with freezing guest I/O, but external + snapshots are quick. Since creating an external snapshot + changes which disk image resource is in use by the guest, this + API can be coupled with <code>virDomainBlockCommit()</code> to + restore things back to the guest using its original disk + image, where a third-party tool can read the backing file + prior to the live commit. See also + the <a href="formatsnapshot.html">XML details</a> used with + this command.</dd> + + <dt>virDomainFSFreeze(), virDomainFSThaw()</dt> + <dd>This pair of APIs does not directly capture guest state, but + can be used to coordinate with a trusted live guest that state + capture is about to happen, and therefore guest I/O should be + quiesced so that the state capture is fully consistent, rather + than merely crash consistent. Some APIs are able to + automatically perform a freeze and thaw via a flags parameter, + rather than having to make separate calls to these + functions. Also, note that freezing guest I/O is only possible + with trusted guests running a guest agent, and that some + guests place maximum time limits on how long I/O can be + frozen.</dd> + + <dt>virDomainBlockCopy()</dt> + <dd>This API wraps approaches for capturing the disk state (but + not memory) of a running guest, but does not track + accompanying guest memory state, but can only operate on one + block device per job. To get a consistent copy of multiple + disks, multiple jobs just be run in parallel, then the domain + must be paused before ending all of the jobs. The capture is + consistent only at the end of the operation with a choice for + future guest changes to either pivot to the new file or to + resume to just using the original file. The resulting backup + file is thus the other file no longer in use by the + guest.</dd> + + <dt>virDomainCheckpointCreateXML()</dt> + <dd>This API does not actually capture guest state, rather it + makes it possible to track which portions of guest disks have + changed between a checkpoint and the current live execution of + the guest. However, while it is possible use this API to + create checkpoints in isolation, it is more typical to create + a checkpoint as a side-effect of starting a new incremental + backup with <code>virDomainBackupBegin()</code>, since a + second incremental backup is most useful when using the + checkpoint created during the first. <!--See also + the <a href="formatcheckpoint.html">XML details</a> used with + this command.--></dd> + + <dt>virDomainBackupBegin(), virDomainBackupEnd()</dt> + <dd>This API wraps approaches for capturing the state of disks + of a running guest, but does not track accompanying guest + memory state. The capture is consistent to the start of the + operation, where the captured state is stored independently + from the disk image in use with the guest and where it can be + easily integrated with a third-party for capturing the disk + state. Since the backup operation is stored externally from + the guest resources, there is no need to commit data back in + at the completion of the operation. When coupled with + checkpoints, this can be used to capture incremental backups + instead of full.</dd> + </dl> + + <h2><a id="examples">Examples</a></h2> + <p>The following two sequences both accomplish the task of + capturing the disk state of a running guest, then wrapping + things up so that the guest is still running with the same file + as its disk image as before the sequence of operations began. + The difference between the two sequences boils down to the + impact of an unexpected interruption made at any point in the + middle of the sequence: with such an interruption, the first + example leaves the guest tied to a temporary wrapper file rather + than the original disk, and requires manual clean up of the + domain definition; while the second example has no impact to the + domain definition.</p> + + <p>1. Backup via temporary snapshot + <pre> +virDomainFSFreeze() +virDomainSnapshotCreateXML(VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY) +virDomainFSThaw() +third-party copy the backing file to backup storage # most time spent here +virDomainBlockCommit(VIR_DOMAIN_BLOCK_COMMIT_ACTIVE) per disk +wait for commit ready event per disk +virDomainBlockJobAbort() per disk + </pre></p> + + <p>2. Direct backup + <pre> +virDomainFSFreeze() +virDomainBackupBegin() +virDomainFSThaw() +wait for push mode event, or pull data over NBD # most time spent here +virDomainBackeupEnd() + </pre></p> + + </body> +</html> diff --git a/docs/formatsnapshot.html.in b/docs/formatsnapshot.html.in index c60b4fb7c9..9ee355198f 100644 --- a/docs/formatsnapshot.html.in +++ b/docs/formatsnapshot.html.in @@ -9,6 +9,8 @@ <h2><a id="SnapshotAttributes">Snapshot XML</a></h2> <p> + Snapshots are one form + of <a href="domainstatecapture.html">domain state capture</a>. There are several types of snapshots: </p> <dl> -- 2.17.1

On Fri, Oct 12, 2018 at 00:10:05 -0500, Eric Blake wrote:
Upcoming patches will add support for incremental backups via a new API; but first, we need a landing page that gives an overview of capturing various pieces of guest state, and which APIs are best suited to which tasks.
Signed-off-by: Eric Blake <eblake@redhat.com>
--- v2: wording improvements based on review --- docs/docs.html.in | 5 + docs/domainstatecapture.html.in | 314 ++++++++++++++++++++++++++++++++ docs/formatsnapshot.html.in | 2 + 3 files changed, 321 insertions(+) create mode 100644 docs/domainstatecapture.html.in
[...]
diff --git a/docs/domainstatecapture.html.in b/docs/domainstatecapture.html.in new file mode 100644 index 0000000000..f7f2fe0b98 --- /dev/null +++ b/docs/domainstatecapture.html.in @@ -0,0 +1,314 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + + <h1>Domain state capture using Libvirt</h1> + + <ul id="toc"></ul> + + <p> + In order to aid application developers to choose which + operations best suit their needs, this page compares the + different means for capturing state related to a domain managed + by libvirt. + </p> + + <p> + The information here is primarily geared towards capturing the + state of an active domain. Capturing the state of an inactive + domain essentially amounts to copying the contents of guest + disks, followed by a fresh boot with disks restored to that + state. Some of the topics presented below may relate to inactive + state collection, but it is not the primary focus of this page. + </p> + + <h2><a id="definitions">State capture trade-offs</a></h2> + + <p>One of the features made possible with virtual machines is live + migration -- transferring all state related to the guest from + one host to another with minimal interruption to the guest's + activity. In this case, state includes domain memory (including + register and device contents), and domain storage (whether the + guest's view of the disks are backed by local storage on the + host, or by the hypervisor accessing shared storage over a + network). A clever observer will then note that if all state is + available for live migration, then there is nothing stopping a + user from saving some or all of that state at a given point of + time in order to be able to later rewind guest execution back to + the state it previously had. The astute reader will also realize + that state capture at any level requires that the data must be + stored and managed by some mechanism. This processing might fit + in a single file, or more likely require a chain of related + files, and may require synchronization with third-party tools + built around managing the amount of data resulting from + capturing the state of multiple guests that each use multiple + disks. + </p> + + <p> + There are several libvirt APIs associated with capturing the + state of a guest, which can later be used to rewind that guest + to the conditions it was in earlier. The following is a list of + trade-offs and differences between the various facets that + affect capturing domain state for active domains: + </p> + + <dl> + <dt>Duration</dt> + <dd>Capturing state can be a lengthy process, so while the + captured state ideally represents an atomic point in time + correpsonding to something the guest was actually executing, + capturing state tends to focus on minimizing guest downtime + while performing the rest of the state capture in parallel + with guest execution. Some interfaces require up-front + preparation (the state captured is not complete until the API + ends, which may be some time after the command was first + started), while other interfaces track the state when the + command was first issued, regardless of the time spent in + capturing the rest of the state. Also, time spent in state + capture may be longer than the time required for live + migration, when state must be duplicated rather than shared. + </dd> + + <dt>Amount of state</dt> + <dd>For an online guest, there is a choice between capturing the + guest's memory (all that is needed during live migration when + the storage is already shared between source and destination), + the guest's disk state (all that is needed if there are no + pending guest I/O transactions that would be lost without the + corresponding memory state), or both together. Reverting to + partial state may still be viable, but typically, booting from + captured disk state without corresponding memory is comparable + to rebooting a machine that had power cut before I/O could be + flushed. Guests may need to use proper journaling methods to + avoid problems when booting from partial state.
While reverting disks without memory is what most systems are somewhat designed to handle everting memory state without disk state is a receipe for disaster.
+ </dd> + + <dt>Quiescing of data</dt> + <dd>Even if a guest has no pending I/O, capturing disk state may + catch the guest at a time when the contents of the disk are + inconsistent. Cooperating with the guest to perform data + quiescing is an optional step to ensure that captured disk + state is fully consistent without requiring additional memory + state, rather than just crash-consistent. But guest + cooperation may also have time constraints, where the guest + can rightfully panic if there is too much downtime while I/O + is frozen.
Also that still does not guarantee that the filesystem is fully consistent.
+ </dd> + + <dt>Quantity of files</dt> + <dd>When capturing state, some approaches store all state within + the same file (internal), while others expand a chain of + related files that must be used together (external), for more
It's more an array of files. We use the term chain for the disk image chain mostly.
+ files that a management application must track. + </dd> + + <dt>Impact to guest definition</dt> + <dd>Capturing state may require temporary changes to the guest + definition, such as associating new files into the domain + definition. While state capture should never impact the + running guest, a change to the domain's active XML may have + impact on other host operations being performed on the domain.
External snapshots make permanent changes. Also I'm not quite sure what you mean by impacting other operations.
+ </dd> + + <dt>Third-party integration</dt> + <dd>When capturing state, there are tradeoffs to how much of the + process must be done directly by the hypervisor, and how much + can be off-loaded to third-party software. Since capturing + state is not instantaneous, it is essential that any + third-party integration see consistent data even if the + running guest continues to modify that data after the point in + time of the capture.</dd>
This is mostly related to the backup operation but the paragraph does not mention it.
+ <dt>Full vs. incremental</dt> + <dd>When periodically repeating the action of state capture, it + is useful to minimize the amount of state that must be + captured by exploiting the relation to a previous capture, + such as focusing only on the portions of the disk that the + guest has modified in the meantime. Some approaches are able + to take advantage of checkpoints to provide an incremental + backup, while others are only capable of a full backup even if + that means re-capturing unchanged portions of the disk.</dd>
Also there is currently no viable incremental memory state capture.
+ + <dt>Local vs. remote</dt> + <dd>Domains that completely use remote storage may only need + some mechanism to keep track of guest memory state while using + external means to manage storage. Still, hypervisor and guest + cooperation to ensure points in time when no I/O is in flight + across the network can be important for properly capturing + disk state.</dd> + + <dt>Network latency</dt> + <dd>Whether it's domain storage or saving domain state into + remote storage, network latency has an impact on snapshot + data. Having dedicated network capacity, bandwidth, or quality + of service levels may play a role, as well as planning for how + much of the backup process needs to be local.</dd> + </dl> + + <p> + An example of the various facets in action is migration of a + running guest. In order for the guest to be able to resume on + the destination at the same place it left off at the source, the + hypervisor has to get to a point where execution on the source + is stopped, the last remaining changes occurring since the + migration started are then transferred, and the guest is started + on the target. The management software thus must keep track of + the starting point and any changes since the starting + point. These last changes are often referred to as dirty page + tracking or dirty disk block bitmaps. At some point in time + during the migration, the management software must freeze the + source guest, transfer the dirty data, and then start the guest + on the target. This period of time must be minimal. To minimize + overall migration time, one is advised to use a dedicated + network connection with a high quality of service. Alternatively + saving the current state of the running guest can just be a + point in time type operation which doesn't require updating the + "last vestiges" of state prior to writing out the saved state + file. The state file is the point in time of whatever is current + and may contain incomplete data which if used to restart the + guest could cause confusion or problems because some operation + wasn't completed depending upon where in time the operation was + commenced.
The last sentence is not clear to me.
+ </p> + + <h2><a id="apis">State capture APIs</a></h2> + <p>With those definitions, the following libvirt APIs related to + state capture have these properties:</p> + <dl> + <dt>virDomainManagedSave</dt> + <dd>This API saves guest memory, with libvirt managing all of + the saved state, then stops the guest. While stopped, the + disks can be copied by a third party. However, since any + subsequent restart of the guest by libvirt API will restore + the memory state (which typically only works if the disk state + is unchanged in the meantime), and since it is not possible to + get at the memory state that libvirt is managing, this is not + viable as a means for rolling back to earlier saved states, + but is rather more suited to situations such as suspending a + guest prior to rebooting the host in order to resume the guest + when the host is back up. This API also has a drawback of + potentially long guest downtime, and therefore does not lend + itself well to live backups.</dd>
Well, it's purpose is completely different. Should we really mention backups here at all?
+ <dt>virDomainSave</dt> + <dd>This API is similar to virDomainManagedSave(), but moves the + burden on managing the stored memory state to the user. As + such, the user can now couple saved state with copies of the + disks to perform a revert to an arbitrary earlier saved state. + However, changing who manages the memory state does not change + the drawback of potentially long guest downtime when capturing + state.</dd>
Again I'd not hint to the possibility that this can be abused to do crappy snapshots.
+ <dt>virDomainSnapshotCreateXML()</dt> + <dd>This API wraps several approaches for capturing guest state, + with a general premise of creating a snapshot (where the + current guest resources are frozen in time and a new wrapper + layer is opened for tracking subsequent guest changes). It + can operate on both offline and running guests, can choose + whether to capture the state of memory, disk, or both when + used on a running guest, and can choose between internal and + external storage for captured state. However, it is geared + towards post-event captures (when capturing both memory and + disk state, the disk state is not captured until all memory + state has been collected first). Using QEMU as the + hypervisor, internal snapshots currently have lengthy downtime + that is incompatible with freezing guest I/O, but external
This might be subject to change. Also capturing memory state with external snapshots has "downtime" implications or needlesly expands the memory image if --live is used.
+ snapshots are quick. Since creating an external snapshot + changes which disk image resource is in use by the guest, this + API can be coupled with <code>virDomainBlockCommit()</code> to + restore things back to the guest using its original disk
Please don't mention this at all since the idea is to use libvirt APIs to delete external snapshots once implemented which will do the commit internally.
+ image, where a third-party tool can read the backing file + prior to the live commit. See also + the <a href="formatsnapshot.html">XML details</a> used with + this command.</dd> + + <dt>virDomainFSFreeze(), virDomainFSThaw()</dt> + <dd>This pair of APIs does not directly capture guest state, but + can be used to coordinate with a trusted live guest that state + capture is about to happen, and therefore guest I/O should be + quiesced so that the state capture is fully consistent, rather + than merely crash consistent. Some APIs are able to + automatically perform a freeze and thaw via a flags parameter, + rather than having to make separate calls to these + functions. Also, note that freezing guest I/O is only possible + with trusted guests running a guest agent, and that some + guests place maximum time limits on how long I/O can be + frozen.</dd> + + <dt>virDomainBlockCopy()</dt> + <dd>This API wraps approaches for capturing the disk state (but + not memory) of a running guest, but does not track + accompanying guest memory state, but can only operate on one
Memory state mentioned twice.
+ block device per job. To get a consistent copy of multiple + disks, multiple jobs just be run in parallel, then the domain + must be paused before ending all of the jobs. The capture is
Again, this is a side effect of this API. The original idea is meant to allow moving storage to a different place while the VM is running. Also the whole paragraph is heavily biased towards backup while the document is attempting to be neutral on the matter of state capture.
+ consistent only at the end of the operation with a choice for + future guest changes to either pivot to the new file or to + resume to just using the original file. The resulting backup + file is thus the other file no longer in use by the + guest.</dd> + + <dt>virDomainCheckpointCreateXML()</dt> + <dd>This API does not actually capture guest state, rather it + makes it possible to track which portions of guest disks have + changed between a checkpoint and the current live execution of + the guest. However, while it is possible use this API to + create checkpoints in isolation, it is more typical to create + a checkpoint as a side-effect of starting a new incremental + backup with <code>virDomainBackupBegin()</code>, since a + second incremental backup is most useful when using the + checkpoint created during the first. <!--See also
Well, it would not really be incremental if you don't create the checkpoint.
+ the <a href="formatcheckpoint.html">XML details</a> used with + this command.--></dd> + + <dt>virDomainBackupBegin(), virDomainBackupEnd()</dt> + <dd>This API wraps approaches for capturing the state of disks + of a running guest, but does not track accompanying guest + memory state. The capture is consistent to the start of the + operation, where the captured state is stored independently + from the disk image in use with the guest and where it can be + easily integrated with a third-party for capturing the disk + state. Since the backup operation is stored externally from + the guest resources, there is no need to commit data back in + at the completion of the operation. When coupled with + checkpoints, this can be used to capture incremental backups + instead of full.</dd> + </dl> + + <h2><a id="examples">Examples</a></h2> + <p>The following two sequences both accomplish the task of + capturing the disk state of a running guest, then wrapping + things up so that the guest is still running with the same file + as its disk image as before the sequence of operations began. + The difference between the two sequences boils down to the + impact of an unexpected interruption made at any point in the + middle of the sequence: with such an interruption, the first + example leaves the guest tied to a temporary wrapper file rather + than the original disk, and requires manual clean up of the + domain definition; while the second example has no impact to the + domain definition.</p> + + <p>1. Backup via temporary snapshot + <pre> +virDomainFSFreeze()
There is a flag for these for the snapshot API
+virDomainSnapshotCreateXML(VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY)
This creates snapshot metadata in libvirt ...
+virDomainFSThaw() +third-party copy the backing file to backup storage # most time spent here +virDomainBlockCommit(VIR_DOMAIN_BLOCK_COMMIT_ACTIVE) per disk
... which is invalidated here. (Yes the images stay in place but the snapshot is not consistent if not done properly.
+wait for commit ready event per disk +virDomainBlockJobAbort() per disk
As noted above, please don't document this hack.
+ </pre></p> + + <p>2. Direct backup + <pre> +virDomainFSFreeze() +virDomainBackupBegin() +virDomainFSThaw() +wait for push mode event, or pull data over NBD # most time spent here +virDomainBackeupEnd() + </pre></p> + + </body> +</html> diff --git a/docs/formatsnapshot.html.in b/docs/formatsnapshot.html.in index c60b4fb7c9..9ee355198f 100644 --- a/docs/formatsnapshot.html.in +++ b/docs/formatsnapshot.html.in @@ -9,6 +9,8 @@ <h2><a id="SnapshotAttributes">Snapshot XML</a></h2>
<p> + Snapshots are one form + of <a href="domainstatecapture.html">domain state capture</a>. There are several types of snapshots: </p> <dl>
Other than the above it seems like a worthy high level documentation. Since it attempts to cover all kinds of state I'd prefer if it does not bias towadrds backups.

On 10/12/18 3:45 AM, Peter Krempa wrote:
On Fri, Oct 12, 2018 at 00:10:05 -0500, Eric Blake wrote:
Upcoming patches will add support for incremental backups via a new API; but first, we need a landing page that gives an overview of capturing various pieces of guest state, and which APIs are best suited to which tasks.
Signed-off-by: Eric Blake <eblake@redhat.com>
+ + <h2><a id="definitions">State capture trade-offs</a></h2> + + <p>One of the features made possible with virtual machines is live + migration -- transferring all state related to the guest from + one host to another with minimal interruption to the guest's + activity. In this case, state includes domain memory (including + register and device contents), and domain storage (whether the + guest's view of the disks are backed by local storage on the + host, or by the hypervisor accessing shared storage over a + network). A clever observer will then note that if all state is + available for live migration, then there is nothing stopping a + user from saving some or all of that state at a given point of + time in order to be able to later rewind guest execution back to + the state it previously had. The astute reader will also realize + that state capture at any level requires that the data must be + stored and managed by some mechanism. This processing might fit + in a single file, or more likely require a chain of related + files, and may require synchronization with third-party tools
I'll update this wording to 'array of files', matching your later comment.
+ built around managing the amount of data resulting from + capturing the state of multiple guests that each use multiple + disks. + </p> + + <p> + There are several libvirt APIs associated with capturing the + state of a guest, which can later be used to rewind that guest + to the conditions it was in earlier. The following is a list of + trade-offs and differences between the various facets that + affect capturing domain state for active domains: + </p> + + <dl> + <dt>Duration</dt> + <dd>Capturing state can be a lengthy process, so while the + captured state ideally represents an atomic point in time + correpsonding to something the guest was actually executing, + capturing state tends to focus on minimizing guest downtime + while performing the rest of the state capture in parallel + with guest execution. Some interfaces require up-front + preparation (the state captured is not complete until the API + ends, which may be some time after the command was first + started), while other interfaces track the state when the + command was first issued, regardless of the time spent in + capturing the rest of the state. Also, time spent in state + capture may be longer than the time required for live + migration, when state must be duplicated rather than shared. + </dd> + + <dt>Amount of state</dt> + <dd>For an online guest, there is a choice between capturing the + guest's memory (all that is needed during live migration when + the storage is already shared between source and destination), + the guest's disk state (all that is needed if there are no + pending guest I/O transactions that would be lost without the + corresponding memory state), or both together. Reverting to + partial state may still be viable, but typically, booting from + captured disk state without corresponding memory is comparable + to rebooting a machine that had power cut before I/O could be + flushed. Guests may need to use proper journaling methods to + avoid problems when booting from partial state.
While reverting disks without memory is what most systems are somewhat designed to handle everting memory state without disk state is a receipe for disaster.
I'll try to word that in there.
+ </dd> + + <dt>Quiescing of data</dt> + <dd>Even if a guest has no pending I/O, capturing disk state may + catch the guest at a time when the contents of the disk are + inconsistent. Cooperating with the guest to perform data + quiescing is an optional step to ensure that captured disk + state is fully consistent without requiring additional memory + state, rather than just crash-consistent. But guest + cooperation may also have time constraints, where the guest + can rightfully panic if there is too much downtime while I/O + is frozen.
Also that still does not guarantee that the filesystem is fully consistent.
I guess your argument there is that depending on the guest's implementation of responding to the request to quiesce memory, it might still leave things inconsistent in the filesystem (but probably because in that case, the guest is prepared to deal with such inconsistency, because after all, the guest is already cooperating to advertise that it can get to a state of minimal pending I/O). Is it worth adding your sentence or any other explanation, or can this paragraph stand as is?
+ </dd> + + <dt>Quantity of files</dt> + <dd>When capturing state, some approaches store all state within + the same file (internal), while others expand a chain of + related files that must be used together (external), for more
It's more an array of files. We use the term chain for the disk image chain mostly.
Good wording improvement (here, and above).
+ files that a management application must track. + </dd> + + <dt>Impact to guest definition</dt> + <dd>Capturing state may require temporary changes to the guest + definition, such as associating new files into the domain + definition. While state capture should never impact the + running guest, a change to the domain's active XML may have + impact on other host operations being performed on the domain.
External snapshots make permanent changes.
Well, they are changes to the permanent XML, but temporary in the sense that you can later use block commit to get back to the pre-snapshot state.
Also I'm not quite sure what you mean by impacting other operations.
Maybe: Capturing state may require changes to the guest definition, such as associating new files into the domain definition. While such changes should never impact the running guest, the fact that the domain's active XML has changed may have implications to other operations on the domain, particularly for a management application that tracks things via transient domains.
+ </dd> + + <dt>Third-party integration</dt> + <dd>When capturing state, there are tradeoffs to how much of the + process must be done directly by the hypervisor, and how much + can be off-loaded to third-party software. Since capturing + state is not instantaneous, it is essential that any + third-party integration see consistent data even if the + running guest continues to modify that data after the point in + time of the capture.</dd>
This is mostly related to the backup operation but the paragraph does not mention it.
It's also possible with external snapshots (a third party can do whatever with the read-only backing file after the snapshot, and prior to any commit operation). I view the document as giving two lists: first, a list of tradeoffs; and second, a list of existing (including new) APIs and where they fit on the continuum of tradeoffs. So the first half does not have to call out which APIs provide which benefits.
+ <dt>Full vs. incremental</dt> + <dd>When periodically repeating the action of state capture, it + is useful to minimize the amount of state that must be + captured by exploiting the relation to a previous capture, + such as focusing only on the portions of the disk that the + guest has modified in the meantime. Some approaches are able + to take advantage of checkpoints to provide an incremental + backup, while others are only capable of a full backup even if + that means re-capturing unchanged portions of the disk.</dd>
Also there is currently no viable incremental memory state capture.
True - that limitation is probably worth listing. (Then again, memory is so much smaller than disk sizes that incremental memory snapshots make less sense in the first place).
+ + <dt>Local vs. remote</dt> + <dd>Domains that completely use remote storage may only need + some mechanism to keep track of guest memory state while using + external means to manage storage. Still, hypervisor and guest + cooperation to ensure points in time when no I/O is in flight + across the network can be important for properly capturing + disk state.</dd> + + <dt>Network latency</dt> + <dd>Whether it's domain storage or saving domain state into + remote storage, network latency has an impact on snapshot + data. Having dedicated network capacity, bandwidth, or quality + of service levels may play a role, as well as planning for how + much of the backup process needs to be local.</dd> + </dl> + + <p> + An example of the various facets in action is migration of a + running guest. In order for the guest to be able to resume on + the destination at the same place it left off at the source, the + hypervisor has to get to a point where execution on the source + is stopped, the last remaining changes occurring since the + migration started are then transferred, and the guest is started + on the target. The management software thus must keep track of + the starting point and any changes since the starting + point. These last changes are often referred to as dirty page + tracking or dirty disk block bitmaps. At some point in time + during the migration, the management software must freeze the + source guest, transfer the dirty data, and then start the guest + on the target. This period of time must be minimal. To minimize + overall migration time, one is advised to use a dedicated + network connection with a high quality of service. Alternatively + saving the current state of the running guest can just be a + point in time type operation which doesn't require updating the + "last vestiges" of state prior to writing out the saved state + file. The state file is the point in time of whatever is current + and may contain incomplete data which if used to restart the + guest could cause confusion or problems because some operation + wasn't completed depending upon where in time the operation was + commenced.
The last sentence is not clear to me.
Indeed, and now I can't even figure out what was meant - that text came from John: https://www.redhat.com/archives/libvir-list/2018-June/msg01614.html Maybe just drop everything beginning with "Alternatively".
+ </p> + + <h2><a id="apis">State capture APIs</a></h2> + <p>With those definitions, the following libvirt APIs related to + state capture have these properties:</p> + <dl> + <dt>virDomainManagedSave</dt> + <dd>This API saves guest memory, with libvirt managing all of + the saved state, then stops the guest. While stopped, the + disks can be copied by a third party. However, since any + subsequent restart of the guest by libvirt API will restore + the memory state (which typically only works if the disk state + is unchanged in the meantime), and since it is not possible to + get at the memory state that libvirt is managing, this is not + viable as a means for rolling back to earlier saved states, + but is rather more suited to situations such as suspending a + guest prior to rebooting the host in order to resume the guest + when the host is back up. This API also has a drawback of + potentially long guest downtime, and therefore does not lend + itself well to live backups.</dd>
Well, it's purpose is completely different. Should we really mention backups here at all?
Maybe reword that last phrase "and therefore does not lend itself well to a situation that requires live guest responsiveness".
+ <dt>virDomainSave</dt> + <dd>This API is similar to virDomainManagedSave(), but moves the + burden on managing the stored memory state to the user. As + such, the user can now couple saved state with copies of the + disks to perform a revert to an arbitrary earlier saved state. + However, changing who manages the memory state does not change + the drawback of potentially long guest downtime when capturing + state.</dd>
Again I'd not hint to the possibility that this can be abused to do crappy snapshots.
I'm trying to point out ALL the APIs that are related to saving state, even if they shouldn't be used as poor-man's snapshots. Maybe: The user can now combine saved state files with copies of disk contents made while the guest was offline in order to revert the guest back to that point in time, although it still suffers from potentially long guest downtime and is not very convenient as a form of state snapshots.
+ <dt>virDomainSnapshotCreateXML()</dt> + <dd>This API wraps several approaches for capturing guest state, + with a general premise of creating a snapshot (where the + current guest resources are frozen in time and a new wrapper + layer is opened for tracking subsequent guest changes). It + can operate on both offline and running guests, can choose + whether to capture the state of memory, disk, or both when + used on a running guest, and can choose between internal and + external storage for captured state. However, it is geared + towards post-event captures (when capturing both memory and + disk state, the disk state is not captured until all memory + state has been collected first). Using QEMU as the + hypervisor, internal snapshots currently have lengthy downtime + that is incompatible with freezing guest I/O, but external
This might be subject to change. Also capturing memory state with external snapshots has "downtime" implications or needlesly expands the memory image if --live is used.
Yes, the drawback of needless memory image expansion with --live should be mentioned (due to the migration stream being an append-only pipeline that allocates new bytes when the same memory is dirtied more than once during the migration phase, rather than a seekable stream that could overwrite existing bytes)
+ snapshots are quick. Since creating an external snapshot + changes which disk image resource is in use by the guest, this + API can be coupled with <code>virDomainBlockCommit()</code> to + restore things back to the guest using its original disk
Please don't mention this at all since the idea is to use libvirt APIs to delete external snapshots once implemented which will do the commit internally.
Why not? Can't we update the document at the time the libvirt APIs actually work? If someone is trying to choose between libvirt APIs that work now, knowing a (less-than-ideal) way to revert is more useful than "patches are still needed, sorry we've been several years at the task".
+ image, where a third-party tool can read the backing file + prior to the live commit. See also + the <a href="formatsnapshot.html">XML details</a> used with + this command.</dd> + + <dt>virDomainFSFreeze(), virDomainFSThaw()</dt> + <dd>This pair of APIs does not directly capture guest state, but + can be used to coordinate with a trusted live guest that state + capture is about to happen, and therefore guest I/O should be + quiesced so that the state capture is fully consistent, rather + than merely crash consistent. Some APIs are able to + automatically perform a freeze and thaw via a flags parameter, + rather than having to make separate calls to these + functions. Also, note that freezing guest I/O is only possible + with trusted guests running a guest agent, and that some + guests place maximum time limits on how long I/O can be + frozen.</dd> + + <dt>virDomainBlockCopy()</dt> + <dd>This API wraps approaches for capturing the disk state (but + not memory) of a running guest, but does not track + accompanying guest memory state, but can only operate on one
Memory state mentioned twice.
Will fix.
+ block device per job. To get a consistent copy of multiple + disks, multiple jobs just be run in parallel, then the domain + must be paused before ending all of the jobs. The capture is
Again, this is a side effect of this API. The original idea is meant to allow moving storage to a different place while the VM is running.
Also the whole paragraph is heavily biased towards backup while the document is attempting to be neutral on the matter of state capture.
Hmm. Any suggestions for better wording then?
+ consistent only at the end of the operation with a choice for + future guest changes to either pivot to the new file or to + resume to just using the original file. The resulting backup + file is thus the other file no longer in use by the + guest.</dd> + + <dt>virDomainCheckpointCreateXML()</dt> + <dd>This API does not actually capture guest state, rather it + makes it possible to track which portions of guest disks have + changed between a checkpoint and the current live execution of + the guest. However, while it is possible use this API to + create checkpoints in isolation, it is more typical to create + a checkpoint as a side-effect of starting a new incremental + backup with <code>virDomainBackupBegin()</code>, since a + second incremental backup is most useful when using the + checkpoint created during the first. <!--See also
Well, it would not really be incremental if you don't create the checkpoint.
Maybe this is better: This API does not actually capture guest state, but makes it possible to track which portions of guest disks have changed between the checkpoint and the current live execution of the guest. Using this API creates an isolated checkpoint, which can provide insights into storage access patterns the guest is making; but when it comes to saving guest state for later reverts, it is instead better to atomically create a checkpoint as a side-effect of capturing an incremental backup, using <code>virDomainBackupBegin()</code>
+ the <a href="formatcheckpoint.html">XML details</a> used with + this command.--></dd> + + <dt>virDomainBackupBegin(), virDomainBackupEnd()</dt> + <dd>This API wraps approaches for capturing the state of disks + of a running guest, but does not track accompanying guest + memory state. The capture is consistent to the start of the + operation, where the captured state is stored independently + from the disk image in use with the guest and where it can be + easily integrated with a third-party for capturing the disk + state. Since the backup operation is stored externally from + the guest resources, there is no need to commit data back in + at the completion of the operation. When coupled with + checkpoints, this can be used to capture incremental backups + instead of full.</dd> + </dl> + + <h2><a id="examples">Examples</a></h2> + <p>The following two sequences both accomplish the task of + capturing the disk state of a running guest, then wrapping + things up so that the guest is still running with the same file + as its disk image as before the sequence of operations began. + The difference between the two sequences boils down to the + impact of an unexpected interruption made at any point in the + middle of the sequence: with such an interruption, the first + example leaves the guest tied to a temporary wrapper file rather + than the original disk, and requires manual clean up of the + domain definition; while the second example has no impact to the + domain definition.</p> + + <p>1. Backup via temporary snapshot + <pre> +virDomainFSFreeze()
There is a flag for these for the snapshot API
+virDomainSnapshotCreateXML(VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY)
This creates snapshot metadata in libvirt ...
+virDomainFSThaw() +third-party copy the backing file to backup storage # most time spent here +virDomainBlockCommit(VIR_DOMAIN_BLOCK_COMMIT_ACTIVE) per disk
... which is invalidated here. (Yes the images stay in place but the snapshot is not consistent if not done properly.
Ah right. Either I should mention the NO_METADATA hack (libvirt isn't even tracking the snapshot) or else mention the virDomainSnapshotDelete(METADATA_ONLY) for getting rid of the snapshot chain that is no longer useful.
+wait for commit ready event per disk +virDomainBlockJobAbort() per disk
As noted above, please don't document this hack.
It's been documented elsewhere, and is at least a way to capture a backup image with existing libvirt, in spite of how hacky it is (and that is part of the reason why it has taken us so long to get to any better API - it's hard to justify new stuff when existing hacks work, even if they are hacky).
+ </pre></p> + + <p>2. Direct backup + <pre> +virDomainFSFreeze() +virDomainBackupBegin() +virDomainFSThaw() +wait for push mode event, or pull data over NBD # most time spent here +virDomainBackeupEnd() + </pre></p> + + </body> +</html> diff --git a/docs/formatsnapshot.html.in b/docs/formatsnapshot.html.in index c60b4fb7c9..9ee355198f 100644 --- a/docs/formatsnapshot.html.in +++ b/docs/formatsnapshot.html.in @@ -9,6 +9,8 @@ <h2><a id="SnapshotAttributes">Snapshot XML</a></h2>
<p> + Snapshots are one form + of <a href="domainstatecapture.html">domain state capture</a>. There are several types of snapshots: </p> <dl>
Other than the above it seems like a worthy high level documentation. Since it attempts to cover all kinds of state I'd prefer if it does not bias towadrds backups.
Hmm, I sort of see what you mean. I only gave two lists (tradeoffs, and then how existing APIs fare on those tradeoffs with a bias for using those APIs for backups), then an example (focused solely on backups). With more time, the document might be even better with even more separation (a list of tradeoffs, a list of existing APIs but without any bias towards backup, and then a more exhaustive list of examples showing not only backups, but also managed save, data analysis using checkpoints, and so on). But how much of that has to be done before this series can go in, vs. as incremental followup patches that further improve the document? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org

Prepare for introducing a bunch of new public APIs related to backup checkpoints by first introducing a new internal type and errors associated with that type. Checkpoints are modeled heavily after virDomainSnapshotPtr (both represent a point in time of the guest), although a snapshot exists with the intent of rolling back to that state, while a checkpoint exists to make it possible to create an incremental backup at a later time. Signed-off-by: Eric Blake <eblake@redhat.com> --- v2: fix copy-and-paste issue in virerror.c [John] --- include/libvirt/virterror.h | 6 +++- src/util/virerror.c | 21 ++++++++++++- include/libvirt/libvirt.h | 2 ++ src/datatypes.h | 31 ++++++++++++++++++- src/datatypes.c | 62 ++++++++++++++++++++++++++++++++++++- src/libvirt_private.syms | 2 ++ 6 files changed, 120 insertions(+), 4 deletions(-) diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h index 57aadb8d16..65efc458a5 100644 --- a/include/libvirt/virterror.h +++ b/include/libvirt/virterror.h @@ -4,7 +4,7 @@ * Description: Provides the interfaces of the libvirt library to handle * errors raised while using the library. * - * Copyright (C) 2006-2016 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -133,6 +133,7 @@ typedef enum { VIR_FROM_PERF = 65, /* Error from perf */ VIR_FROM_LIBSSH = 66, /* Error from libssh connection transport */ VIR_FROM_RESCTRL = 67, /* Error from resource control */ + VIR_FROM_DOMAIN_CHECKPOINT = 68,/* Error from domain checkpoint */ # ifdef VIR_ENUM_SENTINELS VIR_ERR_DOMAIN_LAST @@ -323,6 +324,9 @@ typedef enum { VIR_ERR_DEVICE_MISSING = 99, /* fail to find the desired device */ VIR_ERR_INVALID_NWFILTER_BINDING = 100, /* invalid nwfilter binding */ VIR_ERR_NO_NWFILTER_BINDING = 101, /* no nwfilter binding */ + VIR_ERR_INVALID_DOMAIN_CHECKPOINT = 102,/* invalid domain checkpoint */ + VIR_ERR_NO_DOMAIN_CHECKPOINT = 103, /* domain checkpoint not found */ + VIR_ERR_NO_DOMAIN_BACKUP = 104, /* domain backup job id not found */ } virErrorNumber; /** diff --git a/src/util/virerror.c b/src/util/virerror.c index 683e51aa19..34a4960a73 100644 --- a/src/util/virerror.c +++ b/src/util/virerror.c @@ -1,7 +1,7 @@ /* * virerror.c: error handling and reporting code for libvirt * - * Copyright (C) 2006, 2008-2016 Red Hat, Inc. + * Copyright (C) 2006, 2008-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -136,6 +136,7 @@ VIR_ENUM_IMPL(virErrorDomain, VIR_ERR_DOMAIN_LAST, "Perf", /* 65 */ "Libssh transport layer", "Resource control", + "Domain Checkpoint", ) @@ -1509,6 +1510,24 @@ virErrorMsg(virErrorNumber error, const char *info) else errmsg = _("Network filter binding not found: %s"); break; + case VIR_ERR_INVALID_DOMAIN_CHECKPOINT: + if (info == NULL) + errmsg = _("Invalid checkpoint"); + else + errmsg = _("Invalid checkpoint: %s"); + break; + case VIR_ERR_NO_DOMAIN_CHECKPOINT: + if (info == NULL) + errmsg = _("Domain checkpoint not found"); + else + errmsg = _("Domain checkpoint not found: %s"); + break; + case VIR_ERR_NO_DOMAIN_BACKUP: + if (info == NULL) + errmsg = _("Domain backup job id not found"); + else + errmsg = _("Domain backup job id not found: %s"); + break; } return errmsg; } diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h index 36f6d60775..26887a40e7 100644 --- a/include/libvirt/libvirt.h +++ b/include/libvirt/libvirt.h @@ -36,6 +36,8 @@ extern "C" { # include <libvirt/libvirt-common.h> # include <libvirt/libvirt-host.h> # include <libvirt/libvirt-domain.h> +typedef struct _virDomainCheckpoint virDomainCheckpoint; +typedef virDomainCheckpoint *virDomainCheckpointPtr; # include <libvirt/libvirt-domain-snapshot.h> # include <libvirt/libvirt-event.h> # include <libvirt/libvirt-interface.h> diff --git a/src/datatypes.h b/src/datatypes.h index e1b38706dc..c27ac98437 100644 --- a/src/datatypes.h +++ b/src/datatypes.h @@ -1,7 +1,7 @@ /* * datatypes.h: management of structs for public data types * - * Copyright (C) 2006-2015 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -31,6 +31,7 @@ extern virClassPtr virConnectClass; extern virClassPtr virDomainClass; +extern virClassPtr virDomainCheckpointClass; extern virClassPtr virDomainSnapshotClass; extern virClassPtr virInterfaceClass; extern virClassPtr virNetworkClass; @@ -307,6 +308,21 @@ extern virClassPtr virAdmClientClass; } \ } while (0) +# define virCheckDomainCheckpointReturn(obj, retval) \ + do { \ + virDomainCheckpointPtr _check = (obj); \ + if (!virObjectIsClass(_check, virDomainCheckpointClass) || \ + !virObjectIsClass(_check->domain, virDomainClass) || \ + !virObjectIsClass(_check->domain->conn, virConnectClass)) { \ + virReportErrorHelper(VIR_FROM_DOMAIN_CHECKPOINT, \ + VIR_ERR_INVALID_DOMAIN_CHECKPOINT, \ + __FILE__, __FUNCTION__, __LINE__, \ + __FUNCTION__); \ + virDispatchError(NULL); \ + return retval; \ + } \ + } while (0) + /* Helper macros to implement VIR_DOMAIN_DEBUG using just C99. This * assumes you pass fewer than 15 arguments to VIR_DOMAIN_DEBUG, but @@ -667,6 +683,17 @@ struct _virStream { void *privateData; }; +/** + * _virDomainCheckpoint + * + * Internal structure associated with a domain checkpoint + */ +struct _virDomainCheckpoint { + virObject parent; + char *name; + virDomainPtr domain; +}; + /** * _virDomainSnapshot * @@ -743,6 +770,8 @@ virNWFilterPtr virGetNWFilter(virConnectPtr conn, virNWFilterBindingPtr virGetNWFilterBinding(virConnectPtr conn, const char *portdev, const char *filtername); +virDomainCheckpointPtr virGetDomainCheckpoint(virDomainPtr domain, + const char *name); virDomainSnapshotPtr virGetDomainSnapshot(virDomainPtr domain, const char *name); diff --git a/src/datatypes.c b/src/datatypes.c index caf035f178..108de20b20 100644 --- a/src/datatypes.c +++ b/src/datatypes.c @@ -1,7 +1,7 @@ /* * datatypes.c: management of structs for public data types * - * Copyright (C) 2006-2015 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -36,6 +36,7 @@ VIR_LOG_INIT("datatypes"); virClassPtr virConnectClass; virClassPtr virConnectCloseCallbackDataClass; virClassPtr virDomainClass; +virClassPtr virDomainCheckpointClass; virClassPtr virDomainSnapshotClass; virClassPtr virInterfaceClass; virClassPtr virNetworkClass; @@ -50,6 +51,7 @@ virClassPtr virStoragePoolClass; static void virConnectDispose(void *obj); static void virConnectCloseCallbackDataDispose(void *obj); static void virDomainDispose(void *obj); +static void virDomainCheckpointDispose(void *obj); static void virDomainSnapshotDispose(void *obj); static void virInterfaceDispose(void *obj); static void virNetworkDispose(void *obj); @@ -86,6 +88,7 @@ virDataTypesOnceInit(void) DECLARE_CLASS_LOCKABLE(virConnect); DECLARE_CLASS_LOCKABLE(virConnectCloseCallbackData); DECLARE_CLASS(virDomain); + DECLARE_CLASS(virDomainCheckpoint); DECLARE_CLASS(virDomainSnapshot); DECLARE_CLASS(virInterface); DECLARE_CLASS(virNetwork); @@ -955,6 +958,63 @@ virDomainSnapshotDispose(void *obj) } +/** + * virGetDomainCheckpoint: + * @domain: the domain to checkpoint + * @name: pointer to the domain checkpoint name + * + * Allocates a new domain checkpoint object. When the object is no longer needed, + * virObjectUnref() must be called in order to not leak data. + * + * Returns a pointer to the domain checkpoint object, or NULL on error. + */ +virDomainCheckpointPtr +virGetDomainCheckpoint(virDomainPtr domain, const char *name) +{ + virDomainCheckpointPtr ret = NULL; + + if (virDataTypesInitialize() < 0) + return NULL; + + virCheckDomainGoto(domain, error); + virCheckNonNullArgGoto(name, error); + + if (!(ret = virObjectNew(virDomainCheckpointClass))) + goto error; + if (VIR_STRDUP(ret->name, name) < 0) + goto error; + + ret->domain = virObjectRef(domain); + + return ret; + + error: + virObjectUnref(ret); + return NULL; +} + + +/** + * virDomainCheckpointDispose: + * @obj: the domain checkpoint to release + * + * Unconditionally release all memory associated with a checkpoint. + * The checkpoint object must not be used once this method returns. + * + * It will also unreference the associated connection object, + * which may also be released if its ref count hits zero. + */ +static void +virDomainCheckpointDispose(void *obj) +{ + virDomainCheckpointPtr checkpoint = obj; + VIR_DEBUG("release checkpoint %p %s", checkpoint, checkpoint->name); + + VIR_FREE(checkpoint->name); + virObjectUnref(checkpoint->domain); +} + + virAdmConnectPtr virAdmConnectNew(void) { diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index eb1ad579d9..4d79ec7adb 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -1207,10 +1207,12 @@ virConnectCloseCallbackDataClass; virConnectCloseCallbackDataGetCallback; virConnectCloseCallbackDataRegister; virConnectCloseCallbackDataUnregister; +virDomainCheckpointClass; virDomainClass; virDomainSnapshotClass; virGetConnect; virGetDomain; +virGetDomainCheckpoint; virGetDomainSnapshot; virGetInterface; virGetNetwork; -- 2.17.1

On Fri, Oct 12, 2018 at 00:10:06 -0500, Eric Blake wrote:
Prepare for introducing a bunch of new public APIs related to backup checkpoints by first introducing a new internal type and errors associated with that type. Checkpoints are modeled heavily after virDomainSnapshotPtr (both represent a point in time of the guest), although a snapshot exists with the intent of rolling back to that state, while a checkpoint exists to make it possible to create an incremental backup at a later time.
Signed-off-by: Eric Blake <eblake@redhat.com>
--- v2: fix copy-and-paste issue in virerror.c [John] --- include/libvirt/virterror.h | 6 +++- src/util/virerror.c | 21 ++++++++++++- include/libvirt/libvirt.h | 2 ++ src/datatypes.h | 31 ++++++++++++++++++- src/datatypes.c | 62 ++++++++++++++++++++++++++++++++++++- src/libvirt_private.syms | 2 ++ 6 files changed, 120 insertions(+), 4 deletions(-)
diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h index 57aadb8d16..65efc458a5 100644 --- a/include/libvirt/virterror.h +++ b/include/libvirt/virterror.h @@ -4,7 +4,7 @@ * Description: Provides the interfaces of the libvirt library to handle * errors raised while using the library. * - * Copyright (C) 2006-2016 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -133,6 +133,7 @@ typedef enum { VIR_FROM_PERF = 65, /* Error from perf */ VIR_FROM_LIBSSH = 66, /* Error from libssh connection transport */ VIR_FROM_RESCTRL = 67, /* Error from resource control */ + VIR_FROM_DOMAIN_CHECKPOINT = 68,/* Error from domain checkpoint */
# ifdef VIR_ENUM_SENTINELS VIR_ERR_DOMAIN_LAST @@ -323,6 +324,9 @@ typedef enum { VIR_ERR_DEVICE_MISSING = 99, /* fail to find the desired device */ VIR_ERR_INVALID_NWFILTER_BINDING = 100, /* invalid nwfilter binding */ VIR_ERR_NO_NWFILTER_BINDING = 101, /* no nwfilter binding */ + VIR_ERR_INVALID_DOMAIN_CHECKPOINT = 102,/* invalid domain checkpoint */ + VIR_ERR_NO_DOMAIN_CHECKPOINT = 103, /* domain checkpoint not found */ + VIR_ERR_NO_DOMAIN_BACKUP = 104, /* domain backup job id not found */ } virErrorNumber;
/** diff --git a/src/util/virerror.c b/src/util/virerror.c index 683e51aa19..34a4960a73 100644 --- a/src/util/virerror.c +++ b/src/util/virerror.c @@ -1,7 +1,7 @@ /* * virerror.c: error handling and reporting code for libvirt * - * Copyright (C) 2006, 2008-2016 Red Hat, Inc. + * Copyright (C) 2006, 2008-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -136,6 +136,7 @@ VIR_ENUM_IMPL(virErrorDomain, VIR_ERR_DOMAIN_LAST, "Perf", /* 65 */ "Libssh transport layer", "Resource control", + "Domain Checkpoint", )
@@ -1509,6 +1510,24 @@ virErrorMsg(virErrorNumber error, const char *info) else errmsg = _("Network filter binding not found: %s"); break; + case VIR_ERR_INVALID_DOMAIN_CHECKPOINT: + if (info == NULL) + errmsg = _("Invalid checkpoint"); + else + errmsg = _("Invalid checkpoint: %s"); + break; + case VIR_ERR_NO_DOMAIN_CHECKPOINT: + if (info == NULL) + errmsg = _("Domain checkpoint not found"); + else + errmsg = _("Domain checkpoint not found: %s"); + break; + case VIR_ERR_NO_DOMAIN_BACKUP: + if (info == NULL) + errmsg = _("Domain backup job id not found"); + else + errmsg = _("Domain backup job id not found: %s"); + break; } return errmsg;
All the error stuff should be in a separate commit. You don't even mention it in the commit message.
} diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h index 36f6d60775..26887a40e7 100644 --- a/include/libvirt/libvirt.h +++ b/include/libvirt/libvirt.h @@ -36,6 +36,8 @@ extern "C" { # include <libvirt/libvirt-common.h> # include <libvirt/libvirt-host.h> # include <libvirt/libvirt-domain.h> +typedef struct _virDomainCheckpoint virDomainCheckpoint; +typedef virDomainCheckpoint *virDomainCheckpointPtr;
Ewwww. Don't mix includes with definitions.
# include <libvirt/libvirt-domain-snapshot.h> # include <libvirt/libvirt-event.h> # include <libvirt/libvirt-interface.h> diff --git a/src/datatypes.h b/src/datatypes.h index e1b38706dc..c27ac98437 100644 --- a/src/datatypes.h +++ b/src/datatypes.h
[...]
@@ -667,6 +683,17 @@ struct _virStream { void *privateData; };
+/** + * _virDomainCheckpoint + * + * Internal structure associated with a domain checkpoint + */ +struct _virDomainCheckpoint { + virObject parent; + char *name;
I was thinking whether an UUID should not be used as well. But on the other hand most management tools will stash an UUID into the name anyways so it should be fine.
+ virDomainPtr domain; +}; + /** * _virDomainSnapshot *
[...]
diff --git a/src/datatypes.c b/src/datatypes.c index caf035f178..108de20b20 100644 --- a/src/datatypes.c +++ b/src/datatypes.c @@ -1,7 +1,7 @@ /* * datatypes.c: management of structs for public data types * - * Copyright (C) 2006-2015 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc.
AFAIK we established that bumping these is pointless churn. The dates can be re-establised from git history.
* * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public

On 10/12/18 3:59 AM, Peter Krempa wrote:
On Fri, Oct 12, 2018 at 00:10:06 -0500, Eric Blake wrote:
Prepare for introducing a bunch of new public APIs related to backup checkpoints by first introducing a new internal type and errors associated with that type. Checkpoints are modeled heavily after virDomainSnapshotPtr (both represent a point in time of the guest), although a snapshot exists with the intent of rolling back to that state, while a checkpoint exists to make it possible to create an incremental backup at a later time.
Signed-off-by: Eric Blake <eblake@redhat.com>
All the error stuff should be in a separate commit. You don't even mention it in the commit message.
Will split.
} diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h index 36f6d60775..26887a40e7 100644 --- a/include/libvirt/libvirt.h +++ b/include/libvirt/libvirt.h @@ -36,6 +36,8 @@ extern "C" { # include <libvirt/libvirt-common.h> # include <libvirt/libvirt-host.h> # include <libvirt/libvirt-domain.h> +typedef struct _virDomainCheckpoint virDomainCheckpoint; +typedef virDomainCheckpoint *virDomainCheckpointPtr;
Ewwww. Don't mix includes with definitions.
Goes away in 6/9 when I create the public <libvirt/libvirt-domain-checkpoint.h>. I should clearly document this in the commit message and with a comment, if I can't find a way to reorder the patches so that the hack isn't even needed.
# include <libvirt/libvirt-domain-snapshot.h> # include <libvirt/libvirt-event.h> # include <libvirt/libvirt-interface.h> diff --git a/src/datatypes.h b/src/datatypes.h index e1b38706dc..c27ac98437 100644 --- a/src/datatypes.h +++ b/src/datatypes.h
[...]
@@ -667,6 +683,17 @@ struct _virStream { void *privateData; };
+/** + * _virDomainCheckpoint + * + * Internal structure associated with a domain checkpoint + */ +struct _virDomainCheckpoint { + virObject parent; + char *name;
I was thinking whether an UUID should not be used as well. But on the other hand most management tools will stash an UUID into the name anyways so it should be fine.
And, it matches that snapshots also use a name. In fact, I'm half-heartedly thinking of refactoring into: struct _virDomainAffiliate { virObject parent; char *name; }; struct _virDomainSnapshot { _virDomainAffiliate base; }; struct _virDomainCheckpoint { _virDomainAffliate base; }; because there were several places where I could reuse more code between snapshots and checkpoints if they had a common base type.
+++ b/src/datatypes.c @@ -1,7 +1,7 @@ /* * datatypes.c: management of structs for public data types * - * Copyright (C) 2006-2015 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc.
AFAIK we established that bumping these is pointless churn. The dates can be re-establised from git history.
My emacs has a hook that does it automatically. I can turn the hook off for libvirt, if you don't like the churn. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org

Prepare for new checkpoint and backup APIs by describing the XML that will represent a checkpoint and backup. The checkpoint XML is modeled heavily after virDomainSnapshotPtr, since both represent a point in time of the guest (however, a snapshot exists with the intent to roll back to that point, while a checkpoint exists to facilitate later incremental backups). Meanwhile, the backup XML has enough information to represent both push model (the hypervisor writes the backup file to a location of the user's choice) and the pull model (the hypervisor needs local temporary storage, and also creates an NBD server that the user can use to read the backup via a third-party client).. But while a snapshot exists with the intent of rolling back to that state, a checkpoint instead makes it possible to create an incremental backup at a later time. Add testsuite coverage for some minimal uses of both XML. Ultimately, I'd love for push model backups to target a network driver rather than just a local file or block device; but doing that got hairy (while <domain> uses <source> as the description of a host or network resource, I picked <target> as the description of a push model backup target [defaults to qcow2 but can also be raw or any other format], and <scratch> as the description of a pull model backup scratch space [must be qcow2]). The ideal refactoring would be a way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> --- v2: apply (some) wording changes from review --- docs/docs.html.in | 3 +- docs/domainstatecapture.html.in | 4 +- docs/format.html.in | 1 + docs/formatcheckpoint.html.in | 285 +++++++++++++++++++ docs/index.html.in | 3 +- docs/schemas/domainbackup.rng | 185 ++++++++++++ docs/schemas/domaincheckpoint.rng | 94 ++++++ libvirt.spec.in | 2 + mingw-libvirt.spec.in | 4 + tests/Makefile.am | 6 +- tests/domainbackupxml2xmlin/backup-pull.xml | 9 + tests/domainbackupxml2xmlin/backup-push.xml | 9 + tests/domainbackupxml2xmlin/empty.xml | 1 + tests/domainbackupxml2xmlout/backup-pull.xml | 9 + tests/domainbackupxml2xmlout/backup-push.xml | 9 + tests/domainbackupxml2xmlout/empty.xml | 7 + tests/domaincheckpointxml2xmlin/empty.xml | 1 + tests/domaincheckpointxml2xmlin/sample.xml | 7 + tests/domaincheckpointxml2xmlout/empty.xml | 10 + tests/domaincheckpointxml2xmlout/sample.xml | 16 ++ tests/virschematest.c | 4 + 21 files changed, 664 insertions(+), 5 deletions(-) create mode 100644 docs/formatcheckpoint.html.in create mode 100644 docs/schemas/domainbackup.rng create mode 100644 docs/schemas/domaincheckpoint.rng create mode 100644 tests/domainbackupxml2xmlin/backup-pull.xml create mode 100644 tests/domainbackupxml2xmlin/backup-push.xml create mode 100644 tests/domainbackupxml2xmlin/empty.xml create mode 100644 tests/domainbackupxml2xmlout/backup-pull.xml create mode 100644 tests/domainbackupxml2xmlout/backup-push.xml create mode 100644 tests/domainbackupxml2xmlout/empty.xml create mode 100644 tests/domaincheckpointxml2xmlin/empty.xml create mode 100644 tests/domaincheckpointxml2xmlin/sample.xml create mode 100644 tests/domaincheckpointxml2xmlout/empty.xml create mode 100644 tests/domaincheckpointxml2xmlout/sample.xml diff --git a/docs/docs.html.in b/docs/docs.html.in index 4c46b74980..4914e7dbed 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -79,7 +79,8 @@ <a href="formatdomaincaps.html">domain capabilities</a>, <a href="formatnode.html">node devices</a>, <a href="formatsecret.html">secrets</a>, - <a href="formatsnapshot.html">snapshots</a></dd> + <a href="formatsnapshot.html">snapshots</a>, + <a href="formatcheckpoint.html">backups and checkpoints</a></dd> <dt><a href="uri.html">URI format</a></dt> <dd>The URI formats used for connecting to libvirt</dd> diff --git a/docs/domainstatecapture.html.in b/docs/domainstatecapture.html.in index f7f2fe0b98..9b890b4c0c 100644 --- a/docs/domainstatecapture.html.in +++ b/docs/domainstatecapture.html.in @@ -259,9 +259,9 @@ a checkpoint as a side-effect of starting a new incremental backup with <code>virDomainBackupBegin()</code>, since a second incremental backup is most useful when using the - checkpoint created during the first. <!--See also + checkpoint created during the first. See also the <a href="formatcheckpoint.html">XML details</a> used with - this command.--></dd> + this command.</dd> <dt>virDomainBackupBegin(), virDomainBackupEnd()</dt> <dd>This API wraps approaches for capturing the state of disks diff --git a/docs/format.html.in b/docs/format.html.in index 22b23e3fc7..8c4e15e079 100644 --- a/docs/format.html.in +++ b/docs/format.html.in @@ -24,6 +24,7 @@ <li><a href="formatnode.html">Node devices</a></li> <li><a href="formatsecret.html">Secrets</a></li> <li><a href="formatsnapshot.html">Snapshots</a></li> + <li><a href="formatcheckpoint.html">Backups and checkpoints</a></li> </ul> <h2>Command line validation</h2> diff --git a/docs/formatcheckpoint.html.in b/docs/formatcheckpoint.html.in new file mode 100644 index 0000000000..f32516894f --- /dev/null +++ b/docs/formatcheckpoint.html.in @@ -0,0 +1,285 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Checkpoint and Backup XML format</h1> + + <ul id="toc"></ul> + + <h2><a id="CheckpointAttributes">Checkpoint XML</a></h2> + + <p> + One method of capturing domain disk backups is via the use of + incremental backups. Right now, incremental backups are only + supported for the qemu hypervisor when using qcow2 disks at the + active layer; if other disk formats are in use, capturing disk + backups requires different libvirt APIs + (see <a href="domainstatecapture.html">domain state capture</a> + for a comparison between APIs). + </p> + <p> + Libvirt is able to facilitate incremental backups by tracking + disk checkpoints, which are points in time against which it is + easy to compute which portion of the disk has changed. Given a + full backup (a backup created from the creation of the disk to a + given point in time), coupled with the creation of a disk + checkpoint at that time, and an incremental backup (a backup + created from just the dirty portion of the disk between the + first checkpoint and the second backup operation), it is + possible to do an offline reconstruction of the state of the + disk at the time of the second backup without having to copy as + much data as a second full backup would require. Most disk + checkpoints are created in concert with a backup + via <code>virDomainBackupBegin()</code>; however, libvirt also + exposes enough support to create disk checkpoints independently + from a backup operation + via <code>virDomainCheckpointCreateXML()</code>. + </p> + <p> + Attributes of libvirt checkpoints are stored as child elements + of the <code>domaincheckpoint</code> element. At checkpoint + creation time, normally only + the <code>name</code>, <code>description</code>, + and <code>disks</code> elements are settable. The rest of the + fields are ignored on creation and will be filled in by libvirt + in for informational purposes + by <code>virDomainCheckpointGetXMLDesc()</code>. However, when + redefining a checkpoint, with + the <code>VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE</code> flag + of <code>virDomainCheckpointCreateXML()</code>, all of the XML + fields described here are relevant. + </p> + <p> + Checkpoints are maintained in a hierarchy. A domain can have a + current checkpoint, which is the most recent checkpoint compared to + the current state of the domain (although a domain might have + checkpoints without a current checkpoint, if checkpoints have been + deleted in the meantime). Creating or reverting to a checkpoint + sets that checkpoint as current, and the prior current checkpoint is + the parent of the new checkpoint. Branches in the hierarchy can + be formed by reverting to a checkpoint with a child, then creating + another checkpoint. + </p> + <p> + The top-level <code>domaincheckpoint</code> element may contain + the following elements: + </p> + <dl> + <dt><code>name</code></dt> + <dd>The name for this checkpoint. If the name is specified when + initially creating the checkpoint, then the checkpoint will have + that particular name. If the name is omitted when initially + creating the checkpoint, then libvirt will make up a name for + the checkpoint, based on the time when it was created. + </dd> + <dt><code>description</code></dt> + <dd>A human-readable description of the checkpoint. If the + description is omitted when initially creating the checkpoint, + then this field will be empty. + </dd> + <dt><code>disks</code></dt> + <dd>On input, this is an optional listing of specific + instructions for disk checkpoints; it is needed when making a + checkpoint on only a subset of the disks associated with a + domain (in particular, since qemu checkpoints require qcow2 + disks, this element may be needed on input for excluding guest + disks that are not in qcow2 format); if the entire element was + omitted on input, then all disks participate in the + checkpoint, but if individual disks were omitted from the + element, they will not be part of the checkpoint. On output, + this is fully populated to show the state of each disk in the + checkpoint. This element has a list of <code>disk</code> + sub-elements, describing anywhere from one to all of the disks + associated with the domain. + <dl> + <dt><code>disk</code></dt> + <dd>This sub-element describes the checkpoint properties of + a specific disk. The attribute <code>name</code> is + mandatory, and must match either the <code><target + dev='name'/></code> or an unambiguous <code><source + file='name'/></code> of one of + the <a href="formatdomain.html#elementsDisks">disk + devices</a> specified for the domain at the time of the + checkpoint. The attribute <code>checkpoint</code> is + optional on input; possible values are <code>no</code> + when the disk does not participate in this checkpoint; + or <code>bitmap</code> if the disk will track all changes + since the creation of this checkpoint via a bitmap, in + which case another attribute <code>bitmap</code> will be + the name of the tracking bitmap (defaulting to the + checkpoint name). On output, an additional + attribute <code>size</code> may be present if + the <code>VIR_DOMAIN_CHECKPOINT_XML_SIZE</code> flag was + used to perform a dynamic query of the estimated size in + bytes of the changes made since the checkpoint was created. + </dd> + </dl> + </dd> + <dt><code>creationTime</code></dt> + <dd>The time this checkpoint was created. The time is specified + in seconds since the Epoch, UTC (i.e. Unix time). Readonly. + </dd> + <dt><code>parent</code></dt> + <dd>The parent of this checkpoint. If present, this element + contains exactly one child element, name. This specifies the + name of the parent checkpoint of this one, and is used to + represent trees of checkpoints. Readonly. + </dd> + <dt><code>domain</code></dt> + <dd>The inactive <a href="formatdomain.html">domain + configuration</a> at the time the checkpoint was created. + Readonly. + </dd> + </dl> + + <h2><a id="BackupAttributes">Backup XML</a></h2> + + <p> + Creating a backup, whether full or incremental, is done + via <code>virDomainBackupBegin()</code>, which takes an XML + description of the actions to perform. There are two general + modes for backups: a push mode (where the hypervisor writes out + the data to the destination file, which may be local or remote), + and a pull mode (where the hypervisor creates an NBD server that + a third-party client can then read as needed, and which requires + the use of temporary storage, typically local, until the backup + is complete). + </p> + <p> + The instructions for beginning a backup job are provided as + attributes and elements of the + top-level <code>domainbackup</code> element. This element + includes an optional attribute <code>mode</code> which can be + either "push" or "pull" (default push). Where elements are + optional on creation, <code>virDomainBackupGetXMLDesc()</code> + can be used to see the actual values selected (for example, + learning which port the NBD server is using in the pull model, + or what file names libvirt generated when none were supplied). + The following child elements are supported: + </p> + <dl> + <dt><code>incremental</code></dt> + <dd>Optional. If this element is present, it must name an + existing checkpoint of the domain, which will be used to make + this backup an incremental one (in the push model, only + changes since the checkpoint are written to the destination; + in the pull model, the NBD server uses the + NBD_OPT_SET_META_CONTEXT extension to advertise to the client + which portions of the export contain changes since the + checkpoint). If omitted, a full backup is performed. + </dd> + <dt><code>server</code></dt> + <dd>Present only for a pull mode backup. Contains the same + attributes as the <code>protocol</code> element of a disk + attached via NBD in the domain (such as transport, socket, + name, port, or tls), necessary to set up an NBD server that + exposes the content of each disk at the time the backup + started. + </dd> + <dt><code>disks</code></dt> + <dd>This is an optional listing of instructions for disks + participating in the backup (if omitted, all disks + participate, and libvirt attempts to generate filenames by + appending the current timestamp as a suffix). When provided on + input, disks omitted from the list do not participate in the + backup. On output, the list is present but contains only the + disks participating in the backup job. This element has a + list of <code>disk</code> sub-elements, describing anywhere + from one to all of the disks associated with the domain. + <dl> + <dt><code>disk</code></dt> + <dd>This sub-element describes the checkpoint properties of + a specific disk. The attribute <code>name</code> is + mandatory, and must match either the <code><target + dev='name'/></code> or an unambiguous <code><source + file='name'/></code> of one of + the <a href="formatdomain.html#elementsDisks">disk + devices</a> specified for the domain at the time of the + checkpoint. The optional attribute <code>type</code> can + be <code>file</code>, <code>block</code>, + or <code>network</code>, similar to a disk declaration for + a domain, controls what additional sub-elements are needed + to describe the destination (such as <code>protocol</code> + for a network destination). In push mode backups, the + primary sub-element is <code>target</code>; in pull mode, + the primary sub-element is <code>scratch</code>; but + either way, the primary sub-element describes the file + name to be used during the backup operation, similar to + the <code>source</code> sub-element of a domain disk. In + push mode, an optional sub-element <code>driver</code> can + also be used to specify a destination format different + from qcow2. + </dd> + </dl> + </dd> + </dl> + + <h2><a id="example">Examples</a></h2> + + <p>Using this XML to create a checkpoint of just vda on a qemu + domain with two disks and a prior checkpoint:</p> + <pre> +<domaincheckpoint> + <description>Completion of updates after OS install</description> + <disks> + <disk name='vda' checkpoint='bitmap'/> + <disk name='vdb' checkpoint='no'/> + </disks> +</domaincheckpoint></pre> + + <p>will result in XML similar to this from + <code>virDomainCheckpointGetXMLDesc()</code>:</p> + <pre> +<domaincheckpoint> + <name>1525889631</name> + <description>Completion of updates after OS install</description> + <creationTime>1525889631</creationTime> + <parent> + <name>1525111885</name> + </parent> + <disks> + <disk name='vda' checkpoint='bitmap' bitmap='1525889631'/> + <disk name='vdb' checkpoint='no'/> + </disks> + <domain type='qemu'> + <name>fedora</name> + <uuid>93a5c045-6457-2c09-e56c-927cdf34e178</uuid> + <memory>1048576</memory> + ... + <devices> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/path/to/file1'/> + <target dev='vda' bus='virtio'/> + </disk> + <disk type='file' device='disk' snapshot='external'> + <driver name='qemu' type='raw'/> + <source file='/path/to/file2'/> + <target dev='vdb' bus='virtio'/> + </disk> + ... + </devices> + </domain> +</domaincheckpoint></pre> + + <p>With that checkpoint created, the qcow2 image is now tracking + all changes that occur in the image since the checkpoint via + the persistent bitmap named <code>1525889631</code>. Now, we + can make a subsequent call + to <code>virDomainBackupBegin()</code> to perform an incremental + backup of just this data, using the following XML to start a + pull model NBD export of the vda disk: + </p> + <pre> +<domainbackup mode="pull"> + <incremental>1525889631</incremental> + <server transport="unix" socket="/path/to/server"/> + <disks/> + <disk name='vda' type='file'> + <scratch file='/path/to/file1.scratch'/> + </disk> + </disks/> +</domainbackup> + </pre> + </body> +</html> diff --git a/docs/index.html.in b/docs/index.html.in index 1f9f448399..6c5d3a6dc3 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -68,7 +68,8 @@ <a href="formatdomaincaps.html">domain capabilities</a>, <a href="formatnode.html">node devices</a>, <a href="formatsecret.html">secrets</a>, - <a href="formatsnapshot.html">snapshots</a></dd> + <a href="formatsnapshot.html">snapshots</a>, + <a href="formatcheckpoint.html">backups and checkpoints</a></dd> <dt><a href="http://wiki.libvirt.org">Wiki</a></dt> <dd>Read further community contributed content</dd> </dl> diff --git a/docs/schemas/domainbackup.rng b/docs/schemas/domainbackup.rng new file mode 100644 index 0000000000..edc68a37cf --- /dev/null +++ b/docs/schemas/domainbackup.rng @@ -0,0 +1,185 @@ +<?xml version="1.0"?> +<!-- A Relax NG schema for the libvirt domain backup properties XML format --> +<grammar xmlns="http://relaxng.org/ns/structure/1.0"> + <start> + <ref name='domainbackup'/> + </start> + + <include href='domaincommon.rng'/> + + <define name='domainbackup'> + <element name='domainbackup'> + <optional> + <attribute name='id'> + <ref name="unsignedInt"/> + </attribute> + </optional> + <interleave> + <optional> + <element name='incremental'> + <text/> + </element> + </optional> + <choice> + <group> + <optional> + <attribute name='mode'> + <value>push</value> + </attribute> + </optional> + <ref name='backupDisksPush'/> + </group> + <group> + <attribute name='mode'> + <value>pull</value> + </attribute> + <interleave> + <element name='server'> + <choice> + <group> + <optional> + <attribute name='transport'> + <value>tcp</value> + </attribute> + </optional> + <attribute name='name'> + <choice> + <ref name='dnsName'/> + <ref name='ipAddr'/> + </choice> + </attribute> + <optional> + <attribute name='port'> + <ref name='unsignedInt'/> + </attribute> + </optional> + <!-- add tls? --> + </group> + <group> + <attribute name='transport'> + <value>unix</value> + </attribute> + <attribute name='socket'> + <ref name='absFilePath'/> + </attribute> + </group> + </choice> + </element> + <ref name='backupDisksPull'/> + </interleave> + </group> + </choice> + </interleave> + </element> + </define> + + <define name='backupPushDriver'> + <optional> + <element name='driver'> + <attribute name='type'> + <ref name='storageFormat'/> + </attribute> + </element> + </optional> + </define> + + <define name='backupDisksPush'> + <optional> + <element name='disks'> + <oneOrMore> + <element name='disk'> + <attribute name='name'> + <choice> + <ref name='diskTarget'/> + <ref name='absFilePath'/> + </choice> + </attribute> + <choice> + <!-- FIXME allow push to a network location, by + refactoring 'diskSource' to take element name by a + per-grammar ref --> + <group> + <optional> + <attribute name='type'> + <value>file</value> + </attribute> + </optional> + <interleave> + <optional> + <element name='target'> + <attribute name='file'> + <ref name='absFilePath'/> + </attribute> + </element> + </optional> + <ref name='backupPushDriver'/> + </interleave> + </group> + <group> + <attribute name='type'> + <value>disk</value> + </attribute> + <interleave> + <optional> + <element name='target'> + <attribute name='dev'> + <ref name='absFilePath'/> + </attribute> + </element> + </optional> + <ref name='backupPushDriver'/> + </interleave> + </group> + </choice> + </element> + </oneOrMore> + </element> + </optional> + </define> + + <define name='backupDisksPull'> + <optional> + <element name='disks'> + <oneOrMore> + <element name='disk'> + <attribute name='name'> + <choice> + <ref name='diskTarget'/> + <ref name='absFilePath'/> + </choice> + </attribute> + <choice> + <group> + <optional> + <attribute name='type'> + <value>file</value> + </attribute> + </optional> + <optional> + <element name='scratch'> + <attribute name='file'> + <ref name='absFilePath'/> + </attribute> + </element> + </optional> + </group> + <group> + <attribute name='type'> + <value>disk</value> + </attribute> + <optional> + <element name='scratch'> + <attribute name='dev'> + <ref name='absFilePath'/> + </attribute> + </element> + </optional> + </group> + </choice> + </element> + </oneOrMore> + </element> + </optional> + </define> + +</grammar> diff --git a/docs/schemas/domaincheckpoint.rng b/docs/schemas/domaincheckpoint.rng new file mode 100644 index 0000000000..d8dfda9f1c --- /dev/null +++ b/docs/schemas/domaincheckpoint.rng @@ -0,0 +1,94 @@ +<?xml version="1.0"?> +<!-- A Relax NG schema for the libvirt domain checkpoint properties XML format --> +<grammar xmlns="http://relaxng.org/ns/structure/1.0"> + <start> + <ref name='domaincheckpoint'/> + </start> + + <include href='domaincommon.rng'/> + + <define name='domaincheckpoint'> + <element name='domaincheckpoint'> + <interleave> + <optional> + <element name='name'> + <text/> + </element> + </optional> + <optional> + <element name='description'> + <text/> + </element> + </optional> + <optional> + <element name='creationTime'> + <text/> + </element> + </optional> + <optional> + <element name='disks'> + <oneOrMore> + <ref name='diskcheckpoint'/> + </oneOrMore> + </element> + </optional> + <optional> + <choice> + <element name='domain'> + <element name='uuid'> + <ref name="UUID"/> + </element> + </element> + <!-- Nested grammar ensures that any of our overrides of + storagecommon/domaincommon defines do not conflict + with any domain.rng overrides. --> + <grammar> + <include href='domain.rng'/> + </grammar> + </choice> + </optional> + <optional> + <element name='parent'> + <element name='name'> + <text/> + </element> + </element> + </optional> + </interleave> + </element> + </define> + + <define name='diskcheckpoint'> + <element name='disk'> + <attribute name='name'> + <choice> + <ref name='diskTarget'/> + <ref name='absFilePath'/> + </choice> + </attribute> + <choice> + <attribute name='checkpoint'> + <value>no</value> + </attribute> + <group> + <optional> + <attribute name='checkpoint'> + <value>bitmap</value> + </attribute> + </optional> + <optional> + <attribute name='bitmap'> + <text/> + </attribute> + </optional> + <optional> + <attribute name='size'> + <ref name="unsignedLong"/> + </attribute> + </optional> + </group> + </choice> + </element> + </define> + +</grammar> diff --git a/libvirt.spec.in b/libvirt.spec.in index 90daefe6f1..5c30a45f62 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1834,7 +1834,9 @@ exit 0 %{_datadir}/libvirt/schemas/capability.rng %{_datadir}/libvirt/schemas/cputypes.rng %{_datadir}/libvirt/schemas/domain.rng +%{_datadir}/libvirt/schemas/domainbackup.rng %{_datadir}/libvirt/schemas/domaincaps.rng +%{_datadir}/libvirt/schemas/domaincheckpoint.rng %{_datadir}/libvirt/schemas/domaincommon.rng %{_datadir}/libvirt/schemas/domainsnapshot.rng %{_datadir}/libvirt/schemas/interface.rng diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in index b28e40f7f7..65a48ed960 100644 --- a/mingw-libvirt.spec.in +++ b/mingw-libvirt.spec.in @@ -240,7 +240,9 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh %{mingw32_datadir}/libvirt/schemas/capability.rng %{mingw32_datadir}/libvirt/schemas/cputypes.rng %{mingw32_datadir}/libvirt/schemas/domain.rng +%{mingw32_datadir}/libvirt/schemas/domainbackup.rng %{mingw32_datadir}/libvirt/schemas/domaincaps.rng +%{mingw32_datadir}/libvirt/schemas/domaincheckpoint.rng %{mingw32_datadir}/libvirt/schemas/domaincommon.rng %{mingw32_datadir}/libvirt/schemas/domainsnapshot.rng %{mingw32_datadir}/libvirt/schemas/interface.rng @@ -327,7 +329,9 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh %{mingw64_datadir}/libvirt/schemas/capability.rng %{mingw64_datadir}/libvirt/schemas/cputypes.rng %{mingw64_datadir}/libvirt/schemas/domain.rng +%{mingw64_datadir}/libvirt/schemas/domainbackup.rng %{mingw64_datadir}/libvirt/schemas/domaincaps.rng +%{mingw64_datadir}/libvirt/schemas/domaincheckpoint.rng %{mingw64_datadir}/libvirt/schemas/domaincommon.rng %{mingw64_datadir}/libvirt/schemas/domainsnapshot.rng %{mingw64_datadir}/libvirt/schemas/interface.rng diff --git a/tests/Makefile.am b/tests/Makefile.am index d7ec7e3a6f..9ba6f50118 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -1,6 +1,6 @@ ## Process this file with automake to produce Makefile.in -## Copyright (C) 2005-2015 Red Hat, Inc. +## Copyright (C) 2005-2018 Red Hat, Inc. ## ## This library is free software; you can redistribute it and/or ## modify it under the terms of the GNU Lesser General Public @@ -92,7 +92,11 @@ EXTRA_DIST = \ capabilityschemadata \ commanddata \ cputestdata \ + domainbackupxml2xmlin \ + domainbackupxml2xmlout \ domaincapsschemadata \ + domaincheckpointxml2xmlin \ + domaincheckpointxml2xmlout \ domainconfdata \ domainschemadata \ domainsnapshotxml2xmlin \ diff --git a/tests/domainbackupxml2xmlin/backup-pull.xml b/tests/domainbackupxml2xmlin/backup-pull.xml new file mode 100644 index 0000000000..2ce5cd6711 --- /dev/null +++ b/tests/domainbackupxml2xmlin/backup-pull.xml @@ -0,0 +1,9 @@ +<domainbackup mode="pull"> + <incremental>1525889631</incremental> + <server transport='tcp' name='localhost' port='10809'/> + <disks> + <disk name='vda' type='file'> + <scratch file='/path/to/file'/> + </disk> + </disks> +</domainbackup> diff --git a/tests/domainbackupxml2xmlin/backup-push.xml b/tests/domainbackupxml2xmlin/backup-push.xml new file mode 100644 index 0000000000..1b7d3061fd --- /dev/null +++ b/tests/domainbackupxml2xmlin/backup-push.xml @@ -0,0 +1,9 @@ +<domainbackup mode="push"> + <incremental>1525889631</incremental> + <disks> + <disk name='vda' type='file'> + <driver type='raw'/> + <target file='/path/to/file'/> + </disk> + </disks> +</domainbackup> diff --git a/tests/domainbackupxml2xmlin/empty.xml b/tests/domainbackupxml2xmlin/empty.xml new file mode 100644 index 0000000000..7ed511f97b --- /dev/null +++ b/tests/domainbackupxml2xmlin/empty.xml @@ -0,0 +1 @@ +<domainbackup/> diff --git a/tests/domainbackupxml2xmlout/backup-pull.xml b/tests/domainbackupxml2xmlout/backup-pull.xml new file mode 100644 index 0000000000..2ce5cd6711 --- /dev/null +++ b/tests/domainbackupxml2xmlout/backup-pull.xml @@ -0,0 +1,9 @@ +<domainbackup mode="pull"> + <incremental>1525889631</incremental> + <server transport='tcp' name='localhost' port='10809'/> + <disks> + <disk name='vda' type='file'> + <scratch file='/path/to/file'/> + </disk> + </disks> +</domainbackup> diff --git a/tests/domainbackupxml2xmlout/backup-push.xml b/tests/domainbackupxml2xmlout/backup-push.xml new file mode 100644 index 0000000000..1b7d3061fd --- /dev/null +++ b/tests/domainbackupxml2xmlout/backup-push.xml @@ -0,0 +1,9 @@ +<domainbackup mode="push"> + <incremental>1525889631</incremental> + <disks> + <disk name='vda' type='file'> + <driver type='raw'/> + <target file='/path/to/file'/> + </disk> + </disks> +</domainbackup> diff --git a/tests/domainbackupxml2xmlout/empty.xml b/tests/domainbackupxml2xmlout/empty.xml new file mode 100644 index 0000000000..13600fbb1c --- /dev/null +++ b/tests/domainbackupxml2xmlout/empty.xml @@ -0,0 +1,7 @@ +<domainbackup mode="push"> + <disks> + <disk name="vda" type="file"> + <target file="/path/to/file1.copy"/> + </disk> + </disks> +</domainbackup> diff --git a/tests/domaincheckpointxml2xmlin/empty.xml b/tests/domaincheckpointxml2xmlin/empty.xml new file mode 100644 index 0000000000..dc36449142 --- /dev/null +++ b/tests/domaincheckpointxml2xmlin/empty.xml @@ -0,0 +1 @@ +<domaincheckpoint/> diff --git a/tests/domaincheckpointxml2xmlin/sample.xml b/tests/domaincheckpointxml2xmlin/sample.xml new file mode 100644 index 0000000000..70ed964e1e --- /dev/null +++ b/tests/domaincheckpointxml2xmlin/sample.xml @@ -0,0 +1,7 @@ +<domaincheckpoint> + <description>Completion of updates after OS install</description> + <disks> + <disk name='vda' checkpoint='bitmap'/> + <disk name='vdb' checkpoint='no'/> + </disks> +</domaincheckpoint> diff --git a/tests/domaincheckpointxml2xmlout/empty.xml b/tests/domaincheckpointxml2xmlout/empty.xml new file mode 100644 index 0000000000..a26c7caab0 --- /dev/null +++ b/tests/domaincheckpointxml2xmlout/empty.xml @@ -0,0 +1,10 @@ +<domaincheckpoint> + <name>1525889631</name> + <creationTime>1525889631</creationTime> + <disks> + <disk name='vda' checkpoint='bitmap' bitmap='1525889631'/> + </disks> + <domain> + <uuid>9d37b878-a7cc-9f9a-b78f-49b3abad25a8</uuid> + </domain> +</domaincheckpoint> diff --git a/tests/domaincheckpointxml2xmlout/sample.xml b/tests/domaincheckpointxml2xmlout/sample.xml new file mode 100644 index 0000000000..559b29c8c1 --- /dev/null +++ b/tests/domaincheckpointxml2xmlout/sample.xml @@ -0,0 +1,16 @@ +<domaincheckpoint> + <name>1525889631</name> + <description>Completion of updates after OS install</description> + <creationTime>1525889631</creationTime> + <parent> + <name>1525111885</name> + </parent> + <disks> + <disk name='vda' checkpoint='bitmap' bitmap='1525889631'/> + <disk name='vdb' checkpoint='no'/> + </disks> + <domain type='qemu'> + <name>fedora</name> + <uuid>93a5c045-6457-2c09-e56c-927cdf34e178</uuid> + </domain> +</domaincheckpoint> diff --git a/tests/virschematest.c b/tests/virschematest.c index 7dda14e336..768182b4e4 100644 --- a/tests/virschematest.c +++ b/tests/virschematest.c @@ -221,7 +221,11 @@ mymain(void) "lxcxml2xmloutdata", "bhyvexml2argvdata", "genericxml2xmlindata", "genericxml2xmloutdata", "xlconfigdata", "libxlxml2domconfigdata", "qemuhotplugtestdomains"); + DO_TEST_DIR("domainbackup.rng", "domainbackupxml2xmlin", + "domainbackupxml2xmlout"); DO_TEST_DIR("domaincaps.rng", "domaincapsschemadata"); + DO_TEST_DIR("domaincheckpoint.rng", "domaincheckpointxml2xmlin", + "domaincheckpointxml2xmlout"); DO_TEST_DIR("domainsnapshot.rng", "domainsnapshotxml2xmlin", "domainsnapshotxml2xmlout"); DO_TEST_DIR("interface.rng", "interfaceschemadata"); -- 2.17.1

On Fri, Oct 12, 2018 at 00:10:07 -0500, Eric Blake wrote:
Prepare for new checkpoint and backup APIs by describing the XML that will represent a checkpoint and backup. The checkpoint XML is modeled heavily after virDomainSnapshotPtr, since both represent a point in time of the guest (however, a snapshot exists with the intent to roll back to that point, while a checkpoint exists to facilitate later incremental backups). Meanwhile, the backup XML has enough information to represent both push model (the hypervisor writes the backup file to a location of the user's choice) and the pull model (the hypervisor needs local temporary storage, and also creates an NBD server that the user can use to read the backup via a third-party client).. But while a snapshot exists with the intent of rolling back to that state, a checkpoint instead makes it possible to create an incremental backup at a later time.
Add testsuite coverage for some minimal uses of both XML.
Ultimately, I'd love for push model backups to target a network driver rather than just a local file or block device; but doing that got hairy (while <domain> uses <source> as the description of a host or network resource, I picked <target> as the description of a push model backup target [defaults to qcow2 but can also be raw or any other format], and <scratch> as the description of a pull model backup scratch space [must be qcow2]). The ideal refactoring would be a way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code.
Signed-off-by: Eric Blake <eblake@redhat.com>
[...]
diff --git a/docs/formatcheckpoint.html.in b/docs/formatcheckpoint.html.in new file mode 100644 index 0000000000..f32516894f --- /dev/null +++ b/docs/formatcheckpoint.html.in @@ -0,0 +1,285 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Checkpoint and Backup XML format</h1> + + <ul id="toc"></ul> + + <h2><a id="CheckpointAttributes">Checkpoint XML</a></h2> + + <p> + One method of capturing domain disk backups is via the use of + incremental backups. Right now, incremental backups are only + supported for the qemu hypervisor when using qcow2 disks at the + active layer; if other disk formats are in use, capturing disk + backups requires different libvirt APIs + (see <a href="domainstatecapture.html">domain state capture</a> + for a comparison between APIs).
I'd drop the last sentence as anything else will not give the users the ability to do incremental backups.
+ </p>
[...]
+ <p> + Checkpoints are maintained in a hierarchy. A domain can have a + current checkpoint, which is the most recent checkpoint compared to + the current state of the domain (although a domain might have + checkpoints without a current checkpoint, if checkpoints have been + deleted in the meantime). Creating or reverting to a checkpoint + sets that checkpoint as current, and the prior current checkpoint is + the parent of the new checkpoint. Branches in the hierarchy can
I think that too much of this paragraph was stolen from snapshots. It's not entirely clear to me how the 'current checkpoint' is supposed to work and since this is meant for completely external backups without the way to revert the backup via libvirt the description of the setting of the current checkpoint does not make much sense. I'm not sure even whether we should copy the notion of the 'current' checkpoint at this stage from snapshots.
+ be formed by reverting to a checkpoint with a child, then creating + another checkpoint. + </p> + <p> + The top-level <code>domaincheckpoint</code> element may contain + the following elements: + </p> + <dl> + <dt><code>name</code></dt> + <dd>The name for this checkpoint. If the name is specified when + initially creating the checkpoint, then the checkpoint will have + that particular name. If the name is omitted when initially + creating the checkpoint, then libvirt will make up a name for + the checkpoint, based on the time when it was created. + </dd> + <dt><code>description</code></dt> + <dd>A human-readable description of the checkpoint. If the + description is omitted when initially creating the checkpoint, + then this field will be empty. + </dd> + <dt><code>disks</code></dt> + <dd>On input, this is an optional listing of specific + instructions for disk checkpoints; it is needed when making a + checkpoint on only a subset of the disks associated with a + domain (in particular, since qemu checkpoints require qcow2 + disks, this element may be needed on input for excluding guest + disks that are not in qcow2 format); if the entire element was
I'd avoid the part about 'qcow2' and just state that it can be used to control which disks are part of the checkpoint.
+ omitted on input, then all disks participate in the + checkpoint, but if individual disks were omitted from the + element, they will not be part of the checkpoint. On output, + this is fully populated to show the state of each disk in the + checkpoint. This element has a list of <code>disk</code> + sub-elements, describing anywhere from one to all of the disks + associated with the domain. + <dl> + <dt><code>disk</code></dt> + <dd>This sub-element describes the checkpoint properties of + a specific disk. The attribute <code>name</code> is + mandatory, and must match either the <code><target + dev='name'/></code> or an unambiguous <code><source + file='name'/></code> of one of
Please don't allow the <source> part at all. <target> is unique and we don't have to inflict more pain on us.
+ the <a href="formatdomain.html#elementsDisks">disk + devices</a> specified for the domain at the time of the + checkpoint. The attribute <code>checkpoint</code> is + optional on input; possible values are <code>no</code> + when the disk does not participate in this checkpoint; + or <code>bitmap</code> if the disk will track all changes + since the creation of this checkpoint via a bitmap, in + which case another attribute <code>bitmap</code> will be + the name of the tracking bitmap (defaulting to the + checkpoint name). On output, an additional
I'm afraid that this will lead to a mess if we allow naming the resource differently than the snapshot.
+ attribute <code>size</code> may be present if + the <code>VIR_DOMAIN_CHECKPOINT_XML_SIZE</code> flag was + used to perform a dynamic query of the estimated size in + bytes of the changes made since the checkpoint was created. + </dd> + </dl> + </dd> + <dt><code>creationTime</code></dt> + <dd>The time this checkpoint was created. The time is specified + in seconds since the Epoch, UTC (i.e. Unix time). Readonly. + </dd> + <dt><code>parent</code></dt> + <dd>The parent of this checkpoint. If present, this element + contains exactly one child element, name. This specifies the + name of the parent checkpoint of this one, and is used to + represent trees of checkpoints. Readonly.
Is this possible by itself? Or only with combination with snapshots?
+ </dd> + <dt><code>domain</code></dt> + <dd>The inactive <a href="formatdomain.html">domain + configuration</a> at the time the checkpoint was created. + Readonly.
Umm, I don't see a purpose of this.
+ </dd> + </dl> + + <h2><a id="BackupAttributes">Backup XML</a></h2> + + <p> + Creating a backup, whether full or incremental, is done + via <code>virDomainBackupBegin()</code>, which takes an XML + description of the actions to perform. There are two general + modes for backups: a push mode (where the hypervisor writes out + the data to the destination file, which may be local or remote), + and a pull mode (where the hypervisor creates an NBD server that
The NBD part is a qemuism.
+ a third-party client can then read as needed, and which requires + the use of temporary storage, typically local, until the backup + is complete). + </p> + <p> + The instructions for beginning a backup job are provided as + attributes and elements of the + top-level <code>domainbackup</code> element. This element + includes an optional attribute <code>mode</code> which can be + either "push" or "pull" (default push). Where elements are + optional on creation, <code>virDomainBackupGetXMLDesc()</code> + can be used to see the actual values selected (for example, + learning which port the NBD server is using in the pull model, + or what file names libvirt generated when none were supplied). + The following child elements are supported: + </p> + <dl> + <dt><code>incremental</code></dt> + <dd>Optional. If this element is present, it must name an + existing checkpoint of the domain, which will be used to make + this backup an incremental one (in the push model, only + changes since the checkpoint are written to the destination; + in the pull model, the NBD server uses the + NBD_OPT_SET_META_CONTEXT extension to advertise to the client + which portions of the export contain changes since the + checkpoint). If omitted, a full backup is performed. + </dd> + <dt><code>server</code></dt> + <dd>Present only for a pull mode backup. Contains the same + attributes as the <code>protocol</code> element of a disk + attached via NBD in the domain (such as transport, socket, + name, port, or tls), necessary to set up an NBD server that + exposes the content of each disk at the time the backup + started. + </dd>
Is there a possibility that other hypervisors might use a per-disk server?
+ <dt><code>disks</code></dt> + <dd>This is an optional listing of instructions for disks + participating in the backup (if omitted, all disks + participate, and libvirt attempts to generate filenames by + appending the current timestamp as a suffix). When provided on + input, disks omitted from the list do not participate in the + backup. On output, the list is present but contains only the + disks participating in the backup job. This element has a + list of <code>disk</code> sub-elements, describing anywhere + from one to all of the disks associated with the domain. + <dl> + <dt><code>disk</code></dt> + <dd>This sub-element describes the checkpoint properties of + a specific disk. The attribute <code>name</code> is + mandatory, and must match either the <code><target + dev='name'/></code> or an unambiguous <code><source + file='name'/></code> of one of
Again. Don't allow this or we will get bitten.
+ the <a href="formatdomain.html#elementsDisks">disk + devices</a> specified for the domain at the time of the + checkpoint. The optional attribute <code>type</code> can + be <code>file</code>, <code>block</code>, + or <code>network</code>, similar to a disk declaration for + a domain, controls what additional sub-elements are needed + to describe the destination (such as <code>protocol</code> + for a network destination). In push mode backups, the + primary sub-element is <code>target</code>; in pull mode, + the primary sub-element is <code>scratch</code>; but + either way, the primary sub-element describes the file + name to be used during the backup operation, similar to + the <code>source</code> sub-element of a domain disk. In + push mode, an optional sub-element <code>driver</code> can + also be used to specify a destination format different + from qcow2.
qcow2 is a qemuism. The docs should be general.
+ </dd> + </dl> + </dd> + </dl> + + <h2><a id="example">Examples</a></h2>
[...]
diff --git a/docs/schemas/domainbackup.rng b/docs/schemas/domainbackup.rng new file mode 100644 index 0000000000..edc68a37cf --- /dev/null +++ b/docs/schemas/domainbackup.rng @@ -0,0 +1,185 @@ +<?xml version="1.0"?> +<!-- A Relax NG schema for the libvirt domain backup properties XML format --> +<grammar xmlns="http://relaxng.org/ns/structure/1.0"> + <start> + <ref name='domainbackup'/> + </start> + + <include href='domaincommon.rng'/> + + <define name='domainbackup'> + <element name='domainbackup'> + <optional> + <attribute name='id'> + <ref name="unsignedInt"/>
This was not documented. What's the purpose?
+ </attribute> + </optional> + <interleave> + <optional> + <element name='incremental'> + <text/>
Shouldn't we use <empty/> ?
+ </element> + </optional> + <choice> + <group> + <optional> + <attribute name='mode'> + <value>push</value> + </attribute> + </optional> + <ref name='backupDisksPush'/> + </group> + <group> + <attribute name='mode'> + <value>pull</value> + </attribute>
Split this out similarly to name='backupDisksPush'. I see that the disk portion is removed but the server specification should be as well.
+ <interleave> + <element name='server'> + <choice> + <group> + <optional> + <attribute name='transport'> + <value>tcp</value> + </attribute> + </optional> + <attribute name='name'> + <choice> + <ref name='dnsName'/> + <ref name='ipAddr'/> + </choice> + </attribute> + <optional> + <attribute name='port'> + <ref name='unsignedInt'/> + </attribute> + </optional> + <!-- add tls? -->
Yes
+ </group> + <group> + <attribute name='transport'> + <value>unix</value> + </attribute> + <attribute name='socket'> + <ref name='absFilePath'/> + </attribute> + </group> + </choice> + </element> + <ref name='backupDisksPull'/> + </interleave> + </group> + </choice> + </interleave> + </element> + </define> + + <define name='backupPushDriver'> + <optional> + <element name='driver'> + <attribute name='type'> + <ref name='storageFormat'/> + </attribute> + </element> + </optional> + </define> + + <define name='backupDisksPush'> + <optional> + <element name='disks'> + <oneOrMore> + <element name='disk'> + <attribute name='name'> + <choice> + <ref name='diskTarget'/> + <ref name='absFilePath'/>
The above needs to be deleted.
+ </choice> + </attribute> + <choice> + <!-- FIXME allow push to a network location, by + refactoring 'diskSource' to take element name by a + per-grammar ref --> + <group> + <optional> + <attribute name='type'> + <value>file</value> + </attribute> + </optional> + <interleave> + <optional> + <element name='target'> + <attribute name='file'> + <ref name='absFilePath'/> + </attribute> + </element> + </optional> + <ref name='backupPushDriver'/> + </interleave> + </group> + <group> + <attribute name='type'> + <value>disk</value> + </attribute> + <interleave> + <optional> + <element name='target'> + <attribute name='dev'> + <ref name='absFilePath'/> + </attribute> + </element> + </optional> + <ref name='backupPushDriver'/> + </interleave> + </group> + </choice> + </element> + </oneOrMore> + </element> + </optional> + </define> + + <define name='backupDisksPull'> + <optional> + <element name='disks'> + <oneOrMore> + <element name='disk'> + <attribute name='name'> + <choice> + <ref name='diskTarget'/> + <ref name='absFilePath'/>
The above should be deleted.
+ </choice> + </attribute> + <choice>
[...]
diff --git a/docs/schemas/domaincheckpoint.rng b/docs/schemas/domaincheckpoint.rng new file mode 100644 index 0000000000..d8dfda9f1c --- /dev/null +++ b/docs/schemas/domaincheckpoint.rng @@ -0,0 +1,94 @@
[...]
+ + <define name='diskcheckpoint'> + <element name='disk'> + <attribute name='name'> + <choice> + <ref name='diskTarget'/> + <ref name='absFilePath'/>
Nope.
+ </choice> + </attribute> + <choice> + <attribute name='checkpoint'>

Introduce a bunch of new public APIs related to backup checkpoints. Checkpoints are modeled heavily after virDomainSnapshotPtr (both represent a point in time of the guest), although a snapshot exists with the intent of rolling back to that state, while a checkpoint exists to make it possible to create an incremental backup at a later time. The full list of new API: virDomainCheckpointCreateXML; virDomainCheckpointCurrent; virDomainCheckpointDelete; virDomainCheckpointFree; virDomainCheckpointGetConnect; virDomainCheckpointGetDomain; virDomainCheckpointGetParent; virDomainCheckpointGetXMLDesc; virDomainCheckpointHasMetadata; virDomainCheckpointIsCurrent; virDomainCheckpointListChildren; virDomainCheckpointLookupByName; virDomainCheckpointRef; virDomainHasCurrentCheckpoint; virDomainListCheckpoints; virDomainCheckpointGetName; Signed-off-by: Eric Blake <eblake@redhat.com> --- include/libvirt/libvirt-domain-checkpoint.h | 156 +++++ include/libvirt/libvirt.h | 5 +- src/driver-hypervisor.h | 60 +- docs/Makefile.am | 3 + docs/apibuild.py | 2 + docs/docs.html.in | 1 + libvirt.spec.in | 1 + mingw-libvirt.spec.in | 2 + po/POTFILES | 1 + src/Makefile.am | 2 + src/libvirt-domain-checkpoint.c | 723 ++++++++++++++++++++ src/libvirt_public.syms | 20 + 12 files changed, 972 insertions(+), 4 deletions(-) create mode 100644 include/libvirt/libvirt-domain-checkpoint.h create mode 100644 src/libvirt-domain-checkpoint.c diff --git a/include/libvirt/libvirt-domain-checkpoint.h b/include/libvirt/libvirt-domain-checkpoint.h new file mode 100644 index 0000000000..cfca8f4b7f --- /dev/null +++ b/include/libvirt/libvirt-domain-checkpoint.h @@ -0,0 +1,156 @@ +/* + * libvirt-domain-checkpoint.h + * Summary: APIs for management of domain checkpoints + * Description: Provides APIs for the management of domain checkpoints + * Author: Eric Blake <eblake@redhat.com> + * + * Copyright (C) 2006-2018 Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * <http://www.gnu.org/licenses/>. + */ + +#ifndef __VIR_LIBVIRT_DOMAIN_CHECKPOINT_H__ +# define __VIR_LIBVIRT_DOMAIN_CHECKPOINT_H__ + +# ifndef __VIR_LIBVIRT_H_INCLUDES__ +# error "Don't include this file directly, only use libvirt/libvirt.h" +# endif + +/** + * virDomainCheckpoint: + * + * A virDomainCheckpoint is a private structure representing a checkpoint of + * a domain. A checkpoint is useful for tracking which portions of the + * domain disks have been altered since a point in time, but by itself does + * not allow reverting back to that point in time. + */ +typedef struct _virDomainCheckpoint virDomainCheckpoint; + +/** + * virDomainCheckpointPtr: + * + * A virDomainCheckpointPtr is pointer to a virDomainCheckpoint + * private structure, and is the type used to reference a domain + * checkpoint in the API. + */ +typedef virDomainCheckpoint *virDomainCheckpointPtr; + +const char *virDomainCheckpointGetName(virDomainCheckpointPtr checkpoint); +virDomainPtr virDomainCheckpointGetDomain(virDomainCheckpointPtr checkpoint); +virConnectPtr virDomainCheckpointGetConnect(virDomainCheckpointPtr checkpoint); + +typedef enum { + VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE = (1 << 0), /* Restore or alter + metadata */ + VIR_DOMAIN_CHECKPOINT_CREATE_CURRENT = (1 << 1), /* With redefine, make + checkpoint current */ + VIR_DOMAIN_CHECKPOINT_CREATE_NO_METADATA = (1 << 2), /* Make checkpoint without + remembering it */ + /* TODO: VIR_DOMAIN_CHECKPOINT_CREATE_QUIESCE */ +} virDomainCheckpointCreateFlags; + +/* Create a checkpoint using the current VM state. */ +virDomainCheckpointPtr virDomainCheckpointCreateXML(virDomainPtr domain, + const char *xmlDesc, + unsigned int flags); + +typedef enum { + VIR_DOMAIN_CHECKPOINT_XML_SECURE = (1 << 0), /* Include sensitive data */ + VIR_DOMAIN_CHECKPOINT_XML_NO_DOMAIN = (1 << 1), /* Suppress <domain> + subelement */ + VIR_DOMAIN_CHECKPOINT_XML_SIZE = (1 << 2), /* Include dynamic + per-<disk> size */ +} virDomainCheckpointXMLFlags; + +/* Dump the XML of a checkpoint */ +char *virDomainCheckpointGetXMLDesc(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +/** + * virDomainCheckpointListFlags: + * + * Flags valid for virDomainListCheckpoints() and + * virDomainCheckpointListChildren(). Note that the interpretation of + * flag (1<<0) depends on which function it is passed to; but serves + * to toggle the per-call default of whether the listing is shallow or + * recursive. Remaining bits come in groups; if all bits from a group + * are 0, then that group is not used to filter results. */ +typedef enum { + VIR_DOMAIN_CHECKPOINT_LIST_ROOTS = (1 << 0), /* Filter by checkpoints + with no parents, when + listing a domain */ + VIR_DOMAIN_CHECKPOINT_LIST_DESCENDANTS = (1 << 0), /* List all descendants, + not just children, when + listing a checkpoint */ + + VIR_DOMAIN_CHECKPOINT_LIST_LEAVES = (1 << 1), /* Filter by checkpoints + with no children */ + VIR_DOMAIN_CHECKPOINT_LIST_NO_LEAVES = (1 << 2), /* Filter by checkpoints + that have children */ + + VIR_DOMAIN_CHECKPOINT_LIST_METADATA = (1 << 3), /* Filter by checkpoints + which have metadata */ + VIR_DOMAIN_CHECKPOINT_LIST_NO_METADATA = (1 << 4), /* Filter by checkpoints + with no metadata */ +} virDomainCheckpointListFlags; + +/* Get all checkpoint objects for this domain */ +int virDomainListCheckpoints(virDomainPtr domain, + virDomainCheckpointPtr **checkpoints, + unsigned int flags); + +/* Get all checkpoint object children for this checkpoint */ +int virDomainCheckpointListChildren(virDomainCheckpointPtr checkpoint, + virDomainCheckpointPtr **children, + unsigned int flags); + +/* Get a handle to a named checkpoint */ +virDomainCheckpointPtr virDomainCheckpointLookupByName(virDomainPtr domain, + const char *name, + unsigned int flags); + +/* Check whether a domain has a checkpoint which is currently used */ +int virDomainHasCurrentCheckpoint(virDomainPtr domain, unsigned int flags); + +/* Get a handle to the current checkpoint */ +virDomainCheckpointPtr virDomainCheckpointCurrent(virDomainPtr domain, + unsigned int flags); + +/* Get a handle to the parent checkpoint, if one exists */ +virDomainCheckpointPtr virDomainCheckpointGetParent(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +/* Determine if a checkpoint is the current checkpoint of its domain. */ +int virDomainCheckpointIsCurrent(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +/* Determine if checkpoint has metadata that would prevent domain deletion. */ +int virDomainCheckpointHasMetadata(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +/* Delete a checkpoint */ +typedef enum { + VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN = (1 << 0), /* Also delete children */ + VIR_DOMAIN_CHECKPOINT_DELETE_METADATA_ONLY = (1 << 1), /* Delete just metadata */ + VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN_ONLY = (1 << 2), /* Delete just children */ +} virDomainCheckpointDeleteFlags; + +int virDomainCheckpointDelete(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +int virDomainCheckpointRef(virDomainCheckpointPtr checkpoint); +int virDomainCheckpointFree(virDomainCheckpointPtr checkpoint); + +#endif /* __VIR_LIBVIRT_DOMAIN_CHECKPOINT_H__ */ diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h index 26887a40e7..4e7da0afc4 100644 --- a/include/libvirt/libvirt.h +++ b/include/libvirt/libvirt.h @@ -4,7 +4,7 @@ * Description: Provides the interfaces of the libvirt library to handle * virtualized domains * - * Copyright (C) 2005-2006, 2010-2014 Red Hat, Inc. + * Copyright (C) 2005-2006, 2010-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -36,8 +36,7 @@ extern "C" { # include <libvirt/libvirt-common.h> # include <libvirt/libvirt-host.h> # include <libvirt/libvirt-domain.h> -typedef struct _virDomainCheckpoint virDomainCheckpoint; -typedef virDomainCheckpoint *virDomainCheckpointPtr; +# include <libvirt/libvirt-domain-checkpoint.h> # include <libvirt/libvirt-domain-snapshot.h> # include <libvirt/libvirt-event.h> # include <libvirt/libvirt-interface.h> diff --git a/src/driver-hypervisor.h b/src/driver-hypervisor.h index eef31eb1f0..ee8a9a3e0e 100644 --- a/src/driver-hypervisor.h +++ b/src/driver-hypervisor.h @@ -1,7 +1,7 @@ /* * driver-hypervisor.h: entry points for hypervisor drivers * - * Copyright (C) 2006-2015 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -1321,6 +1321,53 @@ typedef int int *nparams, unsigned int flags); +typedef virDomainCheckpointPtr +(*virDrvDomainCheckpointCreateXML)(virDomainPtr domain, + const char *xmlDesc, + unsigned int flags); + +typedef char * +(*virDrvDomainCheckpointGetXMLDesc)(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +typedef int +(*virDrvDomainListCheckpoints)(virDomainPtr domain, + virDomainCheckpointPtr **checkpoints, + unsigned int flags); + +typedef int +(*virDrvDomainCheckpointListChildren)(virDomainCheckpointPtr checkpoint, + virDomainCheckpointPtr **children, + unsigned int flags); + +typedef virDomainCheckpointPtr +(*virDrvDomainCheckpointLookupByName)(virDomainPtr domain, + const char *name, + unsigned int flags); + +typedef int +(*virDrvDomainHasCurrentCheckpoint)(virDomainPtr domain, + unsigned int flags); + +typedef virDomainCheckpointPtr +(*virDrvDomainCheckpointGetParent)(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +typedef virDomainCheckpointPtr +(*virDrvDomainCheckpointCurrent)(virDomainPtr domain, + unsigned int flags); + +typedef int +(*virDrvDomainCheckpointIsCurrent)(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +typedef int +(*virDrvDomainCheckpointHasMetadata)(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +typedef int +(*virDrvDomainCheckpointDelete)(virDomainCheckpointPtr checkpoint, + unsigned int flags); typedef struct _virHypervisorDriver virHypervisorDriver; typedef virHypervisorDriver *virHypervisorDriverPtr; @@ -1572,6 +1619,17 @@ struct _virHypervisorDriver { virDrvConnectBaselineHypervisorCPU connectBaselineHypervisorCPU; virDrvNodeGetSEVInfo nodeGetSEVInfo; virDrvDomainGetLaunchSecurityInfo domainGetLaunchSecurityInfo; + virDrvDomainCheckpointCreateXML domainCheckpointCreateXML; + virDrvDomainCheckpointGetXMLDesc domainCheckpointGetXMLDesc; + virDrvDomainListCheckpoints domainListCheckpoints; + virDrvDomainCheckpointListChildren domainCheckpointListChildren; + virDrvDomainCheckpointLookupByName domainCheckpointLookupByName; + virDrvDomainHasCurrentCheckpoint domainHasCurrentCheckpoint; + virDrvDomainCheckpointGetParent domainCheckpointGetParent; + virDrvDomainCheckpointCurrent domainCheckpointCurrent; + virDrvDomainCheckpointIsCurrent domainCheckpointIsCurrent; + virDrvDomainCheckpointHasMetadata domainCheckpointHasMetadata; + virDrvDomainCheckpointDelete domainCheckpointDelete; }; diff --git a/docs/Makefile.am b/docs/Makefile.am index bd7bc1a431..88c1e83275 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -25,6 +25,7 @@ apihtml = \ apihtml_generated = \ html/libvirt-libvirt-common.html \ html/libvirt-libvirt-domain.html \ + html/libvirt-libvirt-domain-checkpoint.html \ html/libvirt-libvirt-domain-snapshot.html \ html/libvirt-libvirt-event.html \ html/libvirt-libvirt-host.html \ @@ -316,6 +317,7 @@ $(python_generated_files): $(APIBUILD_STAMP) $(APIBUILD_STAMP): $(srcdir)/apibuild.py \ $(top_srcdir)/include/libvirt/libvirt.h \ $(top_srcdir)/include/libvirt/libvirt-common.h.in \ + $(top_srcdir)/include/libvirt/libvirt-domain-checkpoint.h \ $(top_srcdir)/include/libvirt/libvirt-domain-snapshot.h \ $(top_srcdir)/include/libvirt/libvirt-domain.h \ $(top_srcdir)/include/libvirt/libvirt-event.h \ @@ -332,6 +334,7 @@ $(APIBUILD_STAMP): $(srcdir)/apibuild.py \ $(top_srcdir)/include/libvirt/libvirt-admin.h \ $(top_srcdir)/include/libvirt/virterror.h \ $(top_srcdir)/src/libvirt.c \ + $(top_srcdir)/src/libvirt-domain-checkpoint.c \ $(top_srcdir)/src/libvirt-domain-snapshot.c \ $(top_srcdir)/src/libvirt-domain.c \ $(top_srcdir)/src/libvirt-host.c \ diff --git a/docs/apibuild.py b/docs/apibuild.py index 5e218a9ad0..471547cea7 100755 --- a/docs/apibuild.py +++ b/docs/apibuild.py @@ -26,6 +26,7 @@ debugsym = None included_files = { "libvirt-common.h": "header with general libvirt API definitions", "libvirt-domain.h": "header with general libvirt API definitions", + "libvirt-domain-checkpoint.h": "header with general libvirt API definitions", "libvirt-domain-snapshot.h": "header with general libvirt API definitions", "libvirt-event.h": "header with general libvirt API definitions", "libvirt-host.h": "header with general libvirt API definitions", @@ -39,6 +40,7 @@ included_files = { "virterror.h": "header with error specific API definitions", "libvirt.c": "Main interfaces for the libvirt library", "libvirt-domain.c": "Domain interfaces for the libvirt library", + "libvirt-domain-checkpoint.c": "Domain checkpoint interfaces for the libvirt library", "libvirt-domain-snapshot.c": "Domain snapshot interfaces for the libvirt library", "libvirt-host.c": "Host interfaces for the libvirt library", "libvirt-interface.c": "Interface interfaces for the libvirt library", diff --git a/docs/docs.html.in b/docs/docs.html.in index 4914e7dbed..596bc1613d 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -97,6 +97,7 @@ <dd>Reference manual for the C public API, split in <a href="html/libvirt-libvirt-common.html">common</a>, <a href="html/libvirt-libvirt-domain.html">domain</a>, + <a href="html/libvirt-libvirt-domain-checkpoint.html">domain checkpoint</a>, <a href="html/libvirt-libvirt-domain-snapshot.html">domain snapshot</a>, <a href="html/libvirt-virterror.html">error</a>, <a href="html/libvirt-libvirt-event.html">event</a>, diff --git a/libvirt.spec.in b/libvirt.spec.in index 5c30a45f62..887d18990e 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1894,6 +1894,7 @@ exit 0 %{_includedir}/libvirt/libvirt-admin.h %{_includedir}/libvirt/libvirt-common.h %{_includedir}/libvirt/libvirt-domain.h +%{_includedir}/libvirt/libvirt-domain-checkpoint.h %{_includedir}/libvirt/libvirt-domain-snapshot.h %{_includedir}/libvirt/libvirt-event.h %{_includedir}/libvirt/libvirt-host.h diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in index 65a48ed960..11237b8ab7 100644 --- a/mingw-libvirt.spec.in +++ b/mingw-libvirt.spec.in @@ -272,6 +272,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh %{mingw32_includedir}/libvirt/libvirt.h %{mingw32_includedir}/libvirt/libvirt-common.h %{mingw32_includedir}/libvirt/libvirt-domain.h +%{mingw32_includedir}/libvirt/libvirt-domain-checkpoint.h %{mingw32_includedir}/libvirt/libvirt-domain-snapshot.h %{mingw32_includedir}/libvirt/libvirt-event.h %{mingw32_includedir}/libvirt/libvirt-host.h @@ -361,6 +362,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh %{mingw64_includedir}/libvirt/libvirt.h %{mingw64_includedir}/libvirt/libvirt-common.h %{mingw64_includedir}/libvirt/libvirt-domain.h +%{mingw64_includedir}/libvirt/libvirt-domain-checkpoint.h %{mingw64_includedir}/libvirt/libvirt-domain-snapshot.h %{mingw64_includedir}/libvirt/libvirt-event.h %{mingw64_includedir}/libvirt/libvirt-host.h diff --git a/po/POTFILES b/po/POTFILES index be2874487c..d246657188 100644 --- a/po/POTFILES +++ b/po/POTFILES @@ -69,6 +69,7 @@ src/interface/interface_backend_netcf.c src/interface/interface_backend_udev.c src/internal.h src/libvirt-admin.c +src/libvirt-domain-checkpoint.c src/libvirt-domain-snapshot.c src/libvirt-domain.c src/libvirt-host.c diff --git a/src/Makefile.am b/src/Makefile.am index 33ff280d78..4ec1b78a46 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -175,6 +175,7 @@ DRIVER_SOURCES += \ $(DATATYPES_SOURCES) \ libvirt.c libvirt_internal.h \ libvirt-domain.c \ + libvirt-domain-checkpoint.c \ libvirt-domain-snapshot.c \ libvirt-host.c \ libvirt-interface.c \ @@ -726,6 +727,7 @@ libvirt_setuid_rpc_client_la_SOURCES = \ datatypes.c \ libvirt.c \ libvirt-domain.c \ + libvirt-domain-checkpoint.c \ libvirt-domain-snapshot.c \ libvirt-host.c \ libvirt-interface.c \ diff --git a/src/libvirt-domain-checkpoint.c b/src/libvirt-domain-checkpoint.c new file mode 100644 index 0000000000..8a7b5b3c56 --- /dev/null +++ b/src/libvirt-domain-checkpoint.c @@ -0,0 +1,723 @@ +/* + * libvirt-domain-checkpoint.c: entry points for virDomainCheckpointPtr APIs + * + * Copyright (C) 2006-2014, 2018 Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * <http://www.gnu.org/licenses/>. + */ + +#include <config.h> + +#include "datatypes.h" +#include "virlog.h" + +VIR_LOG_INIT("libvirt.domain-checkpoint"); + +#define VIR_FROM_THIS VIR_FROM_DOMAIN_CHECKPOINT + +/** + * virDomainCheckpointGetName: + * @checkpoint: a checkpoint object + * + * Get the public name for that checkpoint + * + * Returns a pointer to the name or NULL, the string need not be deallocated + * as its lifetime will be the same as the checkpoint object. + */ +const char * +virDomainCheckpointGetName(virDomainCheckpointPtr checkpoint) +{ + VIR_DEBUG("checkpoint=%p", checkpoint); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, NULL); + + return checkpoint->name; +} + + +/** + * virDomainCheckpointGetDomain: + * @checkpoint: a checkpoint object + * + * Provides the domain pointer associated with a checkpoint. The + * reference counter on the domain is not increased by this + * call. + * + * Returns the domain or NULL. + */ +virDomainPtr +virDomainCheckpointGetDomain(virDomainCheckpointPtr checkpoint) +{ + VIR_DEBUG("checkpoint=%p", checkpoint); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, NULL); + + return checkpoint->domain; +} + + +/** + * virDomainCheckpointGetConnect: + * @checkpoint: a checkpoint object + * + * Provides the connection pointer associated with a checkpoint. The + * reference counter on the connection is not increased by this + * call. + * + * Returns the connection or NULL. + */ +virConnectPtr +virDomainCheckpointGetConnect(virDomainCheckpointPtr checkpoint) +{ + VIR_DEBUG("checkpoint=%p", checkpoint); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, NULL); + + return checkpoint->domain->conn; +} + + +/** + * virDomainCheckpointCreateXML: + * @domain: a domain object + * @xmlDesc: description of the checkpoint to create + * @flags: bitwise-OR of supported virDomainCheckpointCreateFlags + * + * Create a new checkpoint using @xmlDesc on a running @domain. + * Typically, it is more common to create a new checkpoint as part of + * kicking off a backup job with virDomainBackupBegin(); however, it + * is also possible to start a checkpoint without a backup. + * + * See <a href=formatcheckpoint.html#CheckpointAttributes">Checkpoint XML</a> + * for more details on @xmlDesc. In particular, some hypervisors may require + * particular disk formats, such as qcow2, in order to support this + * command; where @xmlDesc can be used to limit the checkpoint to a working + * subset of the domain's disks. + * + * If @flags includes VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE, then this + * is a request to reinstate checkpoint metadata that was previously + * discarded, rather than creating a new checkpoint. When redefining + * checkpoint metadata, the current checkpoint will not be altered + * unless the VIR_DOMAIN_CHECKPOINT_CREATE_CURRENT flag is also + * present. It is an error to request the + * VIR_DOMAIN_CHECKPOINT_CREATE_CURRENT flag without + * VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE. + * + * If @flags includes VIR_DOMAIN_CHECKPOINT_CREATE_NO_METADATA, then + * the domain's disk images are modified according to @xmlDesc, but + * then the just-created checkpoint has its metadata deleted. This + * flag is incompatible with VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE. + * + * Returns an (opaque) new virDomainCheckpointPtr on success, or NULL + * on failure. + */ +virDomainCheckpointPtr +virDomainCheckpointCreateXML(virDomainPtr domain, + const char *xmlDesc, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "xmlDesc=%s, flags=0x%x", xmlDesc, flags); + + virResetLastError(); + + virCheckDomainReturn(domain, NULL); + conn = domain->conn; + + virCheckNonNullArgGoto(xmlDesc, error); + virCheckReadOnlyGoto(conn->flags, error); + + VIR_REQUIRE_FLAG_GOTO(VIR_DOMAIN_CHECKPOINT_CREATE_CURRENT, + VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE, + error); + + VIR_EXCLUSIVE_FLAGS_GOTO(VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE, + VIR_DOMAIN_CHECKPOINT_CREATE_NO_METADATA, + error); + + if (conn->driver->domainCheckpointCreateXML) { + virDomainCheckpointPtr ret; + ret = conn->driver->domainCheckpointCreateXML(domain, xmlDesc, flags); + if (!ret) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return NULL; +} + + +/** + * virDomainCheckpointGetXMLDesc: + * @checkpoint: a domain checkpoint object + * @flags: bitwise-OR of supported virDomainCheckpointXMLFlags + * + * Provide an XML description of the domain checkpoint. + * + * No security-sensitive data will be included unless @flags contains + * VIR_DOMAIN_CHECKPOINT_XML_SECURE; this flag is rejected on read-only + * connections. + * + * Normally, the XML description includes an element giving a full + * description of the domain at the time the snapshot was created; to + * reduce parsing time, it will be suppressed when @flags contains + * VIR_DOMAIN_CHECKPOINT_XML_NO_DOMAIN. + * + * By default, the XML description contains only static information that + * does not change over time. However, when @flags contains + * VIR_DOMAIN_CHECKPOINT_XML_SIZE, each <disk> listing adds an additional + * attribute that shows an estimate of the current size in bytes that + * have been dirtied between the time the checkpoint was created and the + * current point in time. + * + * Returns a 0 terminated UTF-8 encoded XML instance, or NULL in case of error. + * the caller must free() the returned value. + */ +char * +virDomainCheckpointGetXMLDesc(virDomainCheckpointPtr checkpoint, + unsigned int flags) +{ + virConnectPtr conn; + VIR_DEBUG("checkpoint=%p, flags=0x%x", checkpoint, flags); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, NULL); + conn = checkpoint->domain->conn; + + if ((conn->flags & VIR_CONNECT_RO) && + (flags & VIR_DOMAIN_CHECKPOINT_XML_SECURE)) { + virReportError(VIR_ERR_OPERATION_DENIED, "%s", + _("virDomainCheckpointGetXMLDesc with secure flag")); + goto error; + } + + if (conn->driver->domainCheckpointGetXMLDesc) { + char *ret; + ret = conn->driver->domainCheckpointGetXMLDesc(checkpoint, flags); + if (!ret) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return NULL; +} + + +/** + * virDomainListCheckpoints: + * @domain: a domain object + * @checkpoints: pointer to variable to store the array containing checkpoint + * objects, or NULL if the list is not required (just returns + * number of checkpoints) + * @flags: bitwise-OR of supported virDomainCheckpoinListFlags + * + * Collect the list of domain checkpoints for the given domain, and allocate + * an array to store those objects. + * + * By default, this command covers all checkpoints; it is also possible to + * limit things to just checkpoints with no parents, when @flags includes + * VIR_DOMAIN_CHECKPOINT_LIST_ROOTS. Additional filters are provided in + * groups, where each group contains bits that describe mutually exclusive + * attributes of a checkpoint, and where all bits within a group describe + * all possible checkpoints. Some hypervisors might reject explicit bits + * from a group where the hypervisor cannot make a distinction. For a + * group supported by a given hypervisor, the behavior when no bits of a + * group are set is identical to the behavior when all bits in that group + * are set. When setting bits from more than one group, it is possible to + * select an impossible combination, in that case a hypervisor may return + * either 0 or an error. + * + * The first group of @flags is VIR_DOMAIN_CHECKPOINT_LIST_LEAVES and + * VIR_DOMAIN_CHECKPOINT_LIST_NO_LEAVES, to filter based on checkpoints that + * have no further children (a leaf checkpoint). + * + * The next group of @flags is VIR_DOMAIN_CHECKPOINT_LIST_METADATA and + * VIR_DOMAIN_CHECKPOINT_LIST_NO_METADATA, for filtering checkpoints based on + * whether they have metadata that would prevent the removal of the last + * reference to a domain. + * + * Returns the number of domain checkpoints found or -1 and sets @checkpoints + * to NULL in case of error. On success, the array stored into @checkpoints + * is guaranteed to have an extra allocated element set to NULL but not + * included in the return count, to make iteration easier. The caller is + * responsible for calling virDomainCheckpointFree() on each array element, + * then calling free() on @checkpoints. + */ +int +virDomainListCheckpoints(virDomainPtr domain, + virDomainCheckpointPtr **checkpoints, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "checkpoints=%p, flags=0x%x", checkpoints, flags); + + virResetLastError(); + + if (checkpoints) + *checkpoints = NULL; + + virCheckDomainReturn(domain, -1); + conn = domain->conn; + + if (conn->driver->domainListCheckpoints) { + int ret = conn->driver->domainListCheckpoints(domain, checkpoints, + flags); + if (ret < 0) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} + + +/** + * virDomainCheckpointListChildren: + * @checkpoint: a domain checkpoint object + * @children: pointer to variable to store the array containing checkpoint + * objects, or NULL if the list is not required (just returns + * number of checkpoints) + * @flags: bitwise-OR of supported virDomainCheckpointListFlags + * + * Collect the list of domain checkpoints that are children of the given + * checkpoint, and allocate an array to store those objects. + * + * By default, this command covers only direct children; it is also possible + * to expand things to cover all descendants, when @flags includes + * VIR_DOMAIN_CHECKPOINT_LIST_DESCENDANTS. Also, some filters are provided in + * groups, where each group contains bits that describe mutually exclusive + * attributes of a snapshot, and where all bits within a group describe + * all possible snapshots. Some hypervisors might reject explicit bits + * from a group where the hypervisor cannot make a distinction. For a + * group supported by a given hypervisor, the behavior when no bits of a + * group are set is identical to the behavior when all bits in that group + * are set. When setting bits from more than one group, it is possible to + * select an impossible combination, in that case a hypervisor may return + * either 0 or an error. + * + * The first group of @flags is VIR_DOMAIN_CHECKPOINT_LIST_LEAVES and + * VIR_DOMAIN_CHECKPOINT_LIST_NO_LEAVES, to filter based on checkpoints that + * have no further children (a leaf checkpoint). + * + * The next group of @flags is VIR_DOMAIN_CHECKPOINT_LIST_METADATA and + * VIR_DOMAIN_CHECKPOINT_LIST_NO_METADATA, for filtering checkpoints based on + * whether they have metadata that would prevent the removal of the last + * reference to a domain. + * + * Returns the number of domain checkpoints found or -1 and sets @children to + * NULL in case of error. On success, the array stored into @children is + * guaranteed to have an extra allocated element set to NULL but not included + * in the return count, to make iteration easier. The caller is responsible + * for calling virDomainCheckpointFree() on each array element, then calling + * free() on @children. + */ +int +virDomainCheckpointListChildren(virDomainCheckpointPtr checkpoint, + virDomainCheckpointPtr **children, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DEBUG("checkpoint=%p, children=%p, flags=0x%x", + checkpoint, children, flags); + + virResetLastError(); + + if (children) + *children = NULL; + + virCheckDomainCheckpointReturn(checkpoint, -1); + conn = checkpoint->domain->conn; + + if (conn->driver->domainCheckpointListChildren) { + int ret = conn->driver->domainCheckpointListChildren(checkpoint, + children, flags); + if (ret < 0) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} + + +/** + * virDomainCheckpointLookupByName: + * @domain: a domain object + * @name: name for the domain checkpoint + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Try to lookup a domain checkpoint based on its name. + * + * Returns a domain checkpoint object or NULL in case of failure. If the + * domain checkpoint cannot be found, then the VIR_ERR_NO_DOMAIN_CHECKPOINT + * error is raised. + */ +virDomainCheckpointPtr +virDomainCheckpointLookupByName(virDomainPtr domain, + const char *name, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "name=%s, flags=0x%x", name, flags); + + virResetLastError(); + + virCheckDomainReturn(domain, NULL); + conn = domain->conn; + + virCheckNonNullArgGoto(name, error); + + if (conn->driver->domainCheckpointLookupByName) { + virDomainCheckpointPtr dom; + dom = conn->driver->domainCheckpointLookupByName(domain, name, flags); + if (!dom) + goto error; + return dom; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return NULL; +} + + +/** + * virDomainHasCurrentCheckpoint: + * @domain: pointer to the domain object + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Determine if the domain has a current checkpoint. + * + * Returns 1 if such checkpoint exists, 0 if it doesn't, -1 on error. + */ +int +virDomainHasCurrentCheckpoint(virDomainPtr domain, unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "flags=0x%x", flags); + + virResetLastError(); + + virCheckDomainReturn(domain, -1); + conn = domain->conn; + + if (conn->driver->domainHasCurrentCheckpoint) { + int ret = conn->driver->domainHasCurrentCheckpoint(domain, flags); + if (ret < 0) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} + + +/** + * virDomainCheckpointCurrent: + * @domain: a domain object + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Get the current checkpoint for a domain, if any. + * + * virDomainCheckpointFree should be used to free the resources after the + * checkpoint object is no longer needed. + * + * Returns a domain checkpoint object or NULL in case of failure. If the + * current domain checkpoint cannot be found, then the + * VIR_ERR_NO_DOMAIN_CHECKPOINT error is raised. + */ +virDomainCheckpointPtr +virDomainCheckpointCurrent(virDomainPtr domain, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "flags=0x%x", flags); + + virResetLastError(); + + virCheckDomainReturn(domain, NULL); + conn = domain->conn; + + if (conn->driver->domainCheckpointCurrent) { + virDomainCheckpointPtr snap; + snap = conn->driver->domainCheckpointCurrent(domain, flags); + if (!snap) + goto error; + return snap; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return NULL; +} + + +/** + * virDomainCheckpointGetParent: + * @checkpoint: a checkpoint object + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Get the parent checkpoint for @checkpoint, if any. + * + * virDomainCheckpointFree should be used to free the resources after the + * checkpoint object is no longer needed. + * + * Returns a domain checkpoint object or NULL in case of failure. If the + * given checkpoint is a root (no parent), then the VIR_ERR_NO_DOMAIN_CHECKPOINT + * error is raised. + */ +virDomainCheckpointPtr +virDomainCheckpointGetParent(virDomainCheckpointPtr checkpoint, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DEBUG("checkpoint=%p, flags=0x%x", checkpoint, flags); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, NULL); + conn = checkpoint->domain->conn; + + if (conn->driver->domainCheckpointGetParent) { + virDomainCheckpointPtr snap; + snap = conn->driver->domainCheckpointGetParent(checkpoint, flags); + if (!snap) + goto error; + return snap; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return NULL; +} + + +/** + * virDomainCheckpointIsCurrent: + * @checkpoint: a checkpoint object + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Determine if the given checkpoint is the domain's current checkpoint. See + * also virDomainHasCurrentCheckpoint(). + * + * Returns 1 if current, 0 if not current, or -1 on error. + */ +int +virDomainCheckpointIsCurrent(virDomainCheckpointPtr checkpoint, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DEBUG("checkpoint=%p, flags=0x%x", checkpoint, flags); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, -1); + conn = checkpoint->domain->conn; + + if (conn->driver->domainCheckpointIsCurrent) { + int ret; + ret = conn->driver->domainCheckpointIsCurrent(checkpoint, flags); + if (ret < 0) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} + + +/** + * virDomainCheckpointHasMetadata: + * @checkpoint: a checkpoint object + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Determine if the given checkpoint is associated with libvirt metadata + * that would prevent the deletion of the domain. + * + * Returns 1 if the checkpoint has metadata, 0 if the checkpoint exists without + * help from libvirt, or -1 on error. + */ +int +virDomainCheckpointHasMetadata(virDomainCheckpointPtr checkpoint, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DEBUG("checkpoint=%p, flags=0x%x", checkpoint, flags); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, -1); + conn = checkpoint->domain->conn; + + if (conn->driver->domainCheckpointHasMetadata) { + int ret; + ret = conn->driver->domainCheckpointHasMetadata(checkpoint, flags); + if (ret < 0) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} + + +/** + * virDomainCheckpointDelete: + * @checkpoint: the checkpoint to remove + * @flags: not used yet, pass 0 + * @flags: bitwise-OR of supported virDomainCheckpointDeleteFlags + * + * Removes a checkpoint from the domain. + * + * When removing a checkpoint, the record of which portions of the + * disk were dirtied after the checkpoint will be merged into the + * record tracked by the parent checkpoint, if any. Likewise, if the + * checkpoint being deleted was the current checkpoint, the parent + * checkpoint becomes the new current checkpoint. + * + * If @flags includes VIR_DOMAIN_CHECKPOINT_DELETE_METADATA_ONLY, then + * any checkpoint metadata tracked by libvirt is removed while keeping + * the checkpoint contents intact; if a hypervisor does not require + * any libvirt metadata to track checkpoints, then this flag is + * silently ignored. + * + * Returns 0 on success, -1 on error. + */ +int +virDomainCheckpointDelete(virDomainCheckpointPtr checkpoint, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DEBUG("checkpoint=%p, flags=0x%x", checkpoint, flags); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, -1); + conn = checkpoint->domain->conn; + + virCheckReadOnlyGoto(conn->flags, error); + + VIR_EXCLUSIVE_FLAGS_GOTO(VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN, + VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN_ONLY, + error); + + if (conn->driver->domainCheckpointDelete) { + int ret = conn->driver->domainCheckpointDelete(checkpoint, flags); + if (ret < 0) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} + + +/** + * virDomainCheckpointRef: + * @checkpoint: the checkpoint to hold a reference on + * + * Increment the reference count on the checkpoint. For each + * additional call to this method, there shall be a corresponding + * call to virDomainCheckpointFree to release the reference count, once + * the caller no longer needs the reference to this object. + * + * This method is typically useful for applications where multiple + * threads are using a connection, and it is required that the + * connection and domain remain open until all threads have finished + * using the checkpoint. ie, each new thread using a checkpoint would + * increment the reference count. + * + * Returns 0 in case of success and -1 in case of failure. + */ +int +virDomainCheckpointRef(virDomainCheckpointPtr checkpoint) +{ + VIR_DEBUG("checkpoint=%p, refs=%d", checkpoint, + checkpoint ? checkpoint->parent.u.s.refs : 0); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, -1); + + virObjectRef(checkpoint); + return 0; +} + + +/** + * virDomainCheckpointFree: + * @checkpoint: a domain checkpoint object + * + * Free the domain checkpoint object. The checkpoint itself is not modified. + * The data structure is freed and should not be used thereafter. + * + * Returns 0 in case of success and -1 in case of failure. + */ +int +virDomainCheckpointFree(virDomainCheckpointPtr checkpoint) +{ + VIR_DEBUG("checkpoint=%p", checkpoint); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, -1); + + virObjectUnref(checkpoint); + return 0; +} diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms index d4cdbd8b32..fb58b95344 100644 --- a/src/libvirt_public.syms +++ b/src/libvirt_public.syms @@ -809,4 +809,24 @@ LIBVIRT_4.5.0 { virNWFilterBindingGetFilterName; } LIBVIRT_4.4.0; +LIBVIRT_4.9.0 { + global: + virDomainCheckpointCreateXML; + virDomainCheckpointCurrent; + virDomainCheckpointDelete; + virDomainCheckpointFree; + virDomainCheckpointGetConnect; + virDomainCheckpointGetDomain; + virDomainCheckpointGetName; + virDomainCheckpointGetParent; + virDomainCheckpointGetXMLDesc; + virDomainCheckpointHasMetadata; + virDomainCheckpointIsCurrent; + virDomainCheckpointListChildren; + virDomainCheckpointLookupByName; + virDomainCheckpointRef; + virDomainHasCurrentCheckpoint; + virDomainListCheckpoints; +} LIBVIRT_4.5.0; + # .... define new API here using predicted next version number .... -- 2.17.1

On Fri, Oct 12, 2018 at 00:10:08 -0500, Eric Blake wrote:
Introduce a bunch of new public APIs related to backup checkpoints. Checkpoints are modeled heavily after virDomainSnapshotPtr (both represent a point in time of the guest), although a snapshot exists with the intent of rolling back to that state, while a checkpoint exists to make it possible to create an incremental backup at a later time.
The full list of new API: virDomainCheckpointCreateXML; virDomainCheckpointCurrent; virDomainCheckpointDelete; virDomainCheckpointFree; virDomainCheckpointGetConnect; virDomainCheckpointGetDomain; virDomainCheckpointGetParent; virDomainCheckpointGetXMLDesc; virDomainCheckpointHasMetadata; virDomainCheckpointIsCurrent; virDomainCheckpointListChildren; virDomainCheckpointLookupByName; virDomainCheckpointRef; virDomainHasCurrentCheckpoint; virDomainListCheckpoints; virDomainCheckpointGetName;
Signed-off-by: Eric Blake <eblake@redhat.com> --- include/libvirt/libvirt-domain-checkpoint.h | 156 +++++ include/libvirt/libvirt.h | 5 +- src/driver-hypervisor.h | 60 +- docs/Makefile.am | 3 + docs/apibuild.py | 2 + docs/docs.html.in | 1 + libvirt.spec.in | 1 + mingw-libvirt.spec.in | 2 + po/POTFILES | 1 + src/Makefile.am | 2 + src/libvirt-domain-checkpoint.c | 723 ++++++++++++++++++++ src/libvirt_public.syms | 20 + 12 files changed, 972 insertions(+), 4 deletions(-) create mode 100644 include/libvirt/libvirt-domain-checkpoint.h create mode 100644 src/libvirt-domain-checkpoint.c
diff --git a/include/libvirt/libvirt-domain-checkpoint.h b/include/libvirt/libvirt-domain-checkpoint.h new file mode 100644 index 0000000000..cfca8f4b7f --- /dev/null +++ b/include/libvirt/libvirt-domain-checkpoint.h @@ -0,0 +1,156 @@ +/* + * libvirt-domain-checkpoint.h + * Summary: APIs for management of domain checkpoints + * Description: Provides APIs for the management of domain checkpoints + * Author: Eric Blake <eblake@redhat.com> + * + * Copyright (C) 2006-2018 Red Hat, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * <http://www.gnu.org/licenses/>. + */ + +#ifndef __VIR_LIBVIRT_DOMAIN_CHECKPOINT_H__ +# define __VIR_LIBVIRT_DOMAIN_CHECKPOINT_H__ + +# ifndef __VIR_LIBVIRT_H_INCLUDES__ +# error "Don't include this file directly, only use libvirt/libvirt.h" +# endif + +/** + * virDomainCheckpoint: + * + * A virDomainCheckpoint is a private structure representing a checkpoint of + * a domain. A checkpoint is useful for tracking which portions of the + * domain disks have been altered since a point in time, but by itself does + * not allow reverting back to that point in time. + */ +typedef struct _virDomainCheckpoint virDomainCheckpoint; + +/** + * virDomainCheckpointPtr: + * + * A virDomainCheckpointPtr is pointer to a virDomainCheckpoint + * private structure, and is the type used to reference a domain + * checkpoint in the API. + */ +typedef virDomainCheckpoint *virDomainCheckpointPtr; + +const char *virDomainCheckpointGetName(virDomainCheckpointPtr checkpoint); +virDomainPtr virDomainCheckpointGetDomain(virDomainCheckpointPtr checkpoint); +virConnectPtr virDomainCheckpointGetConnect(virDomainCheckpointPtr checkpoint); + +typedef enum { + VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE = (1 << 0), /* Restore or alter + metadata */ + VIR_DOMAIN_CHECKPOINT_CREATE_CURRENT = (1 << 1), /* With redefine, make + checkpoint current */ + VIR_DOMAIN_CHECKPOINT_CREATE_NO_METADATA = (1 << 2), /* Make checkpoint without + remembering it */
Is this worth adding? Will there be a way to start an incremental backup without a previously existing libvirt checkpoint (thus having metadata)?
+ /* TODO: VIR_DOMAIN_CHECKPOINT_CREATE_QUIESCE */ +} virDomainCheckpointCreateFlags; + +/* Create a checkpoint using the current VM state. */ +virDomainCheckpointPtr virDomainCheckpointCreateXML(virDomainPtr domain, + const char *xmlDesc, + unsigned int flags); + +typedef enum { + VIR_DOMAIN_CHECKPOINT_XML_SECURE = (1 << 0), /* Include sensitive data */ + VIR_DOMAIN_CHECKPOINT_XML_NO_DOMAIN = (1 << 1), /* Suppress <domain> + subelement */ + VIR_DOMAIN_CHECKPOINT_XML_SIZE = (1 << 2), /* Include dynamic + per-<disk> size */ +} virDomainCheckpointXMLFlags; + +/* Dump the XML of a checkpoint */ +char *virDomainCheckpointGetXMLDesc(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +/** + * virDomainCheckpointListFlags: + * + * Flags valid for virDomainListCheckpoints() and + * virDomainCheckpointListChildren(). Note that the interpretation of + * flag (1<<0) depends on which function it is passed to; but serves + * to toggle the per-call default of whether the listing is shallow or + * recursive. Remaining bits come in groups; if all bits from a group + * are 0, then that group is not used to filter results. */ +typedef enum { + VIR_DOMAIN_CHECKPOINT_LIST_ROOTS = (1 << 0), /* Filter by checkpoints + with no parents, when + listing a domain */ + VIR_DOMAIN_CHECKPOINT_LIST_DESCENDANTS = (1 << 0), /* List all descendants, + not just children, when + listing a checkpoint */ + + VIR_DOMAIN_CHECKPOINT_LIST_LEAVES = (1 << 1), /* Filter by checkpoints + with no children */ + VIR_DOMAIN_CHECKPOINT_LIST_NO_LEAVES = (1 << 2), /* Filter by checkpoints + that have children */ + + VIR_DOMAIN_CHECKPOINT_LIST_METADATA = (1 << 3), /* Filter by checkpoints + which have metadata */ + VIR_DOMAIN_CHECKPOINT_LIST_NO_METADATA = (1 << 4), /* Filter by checkpoints + with no metadata */ +} virDomainCheckpointListFlags; + +/* Get all checkpoint objects for this domain */ +int virDomainListCheckpoints(virDomainPtr domain, + virDomainCheckpointPtr **checkpoints, + unsigned int flags); + +/* Get all checkpoint object children for this checkpoint */ +int virDomainCheckpointListChildren(virDomainCheckpointPtr checkpoint, + virDomainCheckpointPtr **children, + unsigned int flags); + +/* Get a handle to a named checkpoint */ +virDomainCheckpointPtr virDomainCheckpointLookupByName(virDomainPtr domain, + const char *name, + unsigned int flags); + +/* Check whether a domain has a checkpoint which is currently used */ +int virDomainHasCurrentCheckpoint(virDomainPtr domain, unsigned int flags); + +/* Get a handle to the current checkpoint */ +virDomainCheckpointPtr virDomainCheckpointCurrent(virDomainPtr domain, + unsigned int flags); + +/* Get a handle to the parent checkpoint, if one exists */ +virDomainCheckpointPtr virDomainCheckpointGetParent(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +/* Determine if a checkpoint is the current checkpoint of its domain. */ +int virDomainCheckpointIsCurrent(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +/* Determine if checkpoint has metadata that would prevent domain deletion. */ +int virDomainCheckpointHasMetadata(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +/* Delete a checkpoint */ +typedef enum { + VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN = (1 << 0), /* Also delete children */ + VIR_DOMAIN_CHECKPOINT_DELETE_METADATA_ONLY = (1 << 1), /* Delete just metadata */ + VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN_ONLY = (1 << 2), /* Delete just children */ +} virDomainCheckpointDeleteFlags; + +int virDomainCheckpointDelete(virDomainCheckpointPtr checkpoint, + unsigned int flags); + +int virDomainCheckpointRef(virDomainCheckpointPtr checkpoint); +int virDomainCheckpointFree(virDomainCheckpointPtr checkpoint); + +#endif /* __VIR_LIBVIRT_DOMAIN_CHECKPOINT_H__ */ diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h index 26887a40e7..4e7da0afc4 100644 --- a/include/libvirt/libvirt.h +++ b/include/libvirt/libvirt.h @@ -4,7 +4,7 @@ * Description: Provides the interfaces of the libvirt library to handle * virtualized domains * - * Copyright (C) 2005-2006, 2010-2014 Red Hat, Inc. + * Copyright (C) 2005-2006, 2010-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -36,8 +36,7 @@ extern "C" { # include <libvirt/libvirt-common.h> # include <libvirt/libvirt-host.h> # include <libvirt/libvirt-domain.h> -typedef struct _virDomainCheckpoint virDomainCheckpoint; -typedef virDomainCheckpoint *virDomainCheckpointPtr;
This should be part of the patch adding the data structure.
+# include <libvirt/libvirt-domain-checkpoint.h> # include <libvirt/libvirt-domain-snapshot.h> # include <libvirt/libvirt-event.h> # include <libvirt/libvirt-interface.h>
[...]
diff --git a/src/libvirt-domain-checkpoint.c b/src/libvirt-domain-checkpoint.c new file mode 100644 index 0000000000..8a7b5b3c56 --- /dev/null +++ b/src/libvirt-domain-checkpoint.c @@ -0,0 +1,723 @@ +/* + * libvirt-domain-checkpoint.c: entry points for virDomainCheckpointPtr APIs + * + * Copyright (C) 2006-2014, 2018 Red Hat, Inc.
For a new file?
+ * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * <http://www.gnu.org/licenses/>. + */ + +#include <config.h> + +#include "datatypes.h" +#include "virlog.h" + +VIR_LOG_INIT("libvirt.domain-checkpoint"); + +#define VIR_FROM_THIS VIR_FROM_DOMAIN_CHECKPOINT + +/** + * virDomainCheckpointGetName: + * @checkpoint: a checkpoint object + * + * Get the public name for that checkpoint + * + * Returns a pointer to the name or NULL, the string need not be deallocated + * as its lifetime will be the same as the checkpoint object. + */ +const char * +virDomainCheckpointGetName(virDomainCheckpointPtr checkpoint) +{ + VIR_DEBUG("checkpoint=%p", checkpoint); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, NULL); + + return checkpoint->name; +} + + +/** + * virDomainCheckpointGetDomain: + * @checkpoint: a checkpoint object + * + * Provides the domain pointer associated with a checkpoint. The + * reference counter on the domain is not increased by this + * call. + * + * Returns the domain or NULL. + */ +virDomainPtr +virDomainCheckpointGetDomain(virDomainCheckpointPtr checkpoint) +{ + VIR_DEBUG("checkpoint=%p", checkpoint); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, NULL); + + return checkpoint->domain; +} + + +/** + * virDomainCheckpointGetConnect: + * @checkpoint: a checkpoint object + * + * Provides the connection pointer associated with a checkpoint. The + * reference counter on the connection is not increased by this + * call. + * + * Returns the connection or NULL. + */ +virConnectPtr +virDomainCheckpointGetConnect(virDomainCheckpointPtr checkpoint)
This does not seem to be very useful. Users always can do a two step lookup.
+{ + VIR_DEBUG("checkpoint=%p", checkpoint); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, NULL); + + return checkpoint->domain->conn; +} + + +/** + * virDomainCheckpointCreateXML: + * @domain: a domain object + * @xmlDesc: description of the checkpoint to create + * @flags: bitwise-OR of supported virDomainCheckpointCreateFlags + * + * Create a new checkpoint using @xmlDesc on a running @domain. + * Typically, it is more common to create a new checkpoint as part of + * kicking off a backup job with virDomainBackupBegin(); however, it + * is also possible to start a checkpoint without a backup. + * + * See <a href=formatcheckpoint.html#CheckpointAttributes">Checkpoint XML</a> + * for more details on @xmlDesc. In particular, some hypervisors may require + * particular disk formats, such as qcow2, in order to support this + * command; where @xmlDesc can be used to limit the checkpoint to a working + * subset of the domain's disks. + * + * If @flags includes VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE, then this + * is a request to reinstate checkpoint metadata that was previously + * discarded, rather than creating a new checkpoint. When redefining + * checkpoint metadata, the current checkpoint will not be altered + * unless the VIR_DOMAIN_CHECKPOINT_CREATE_CURRENT flag is also + * present. It is an error to request the + * VIR_DOMAIN_CHECKPOINT_CREATE_CURRENT flag without + * VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE. + * + * If @flags includes VIR_DOMAIN_CHECKPOINT_CREATE_NO_METADATA, then + * the domain's disk images are modified according to @xmlDesc, but + * then the just-created checkpoint has its metadata deleted. This + * flag is incompatible with VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE. + * + * Returns an (opaque) new virDomainCheckpointPtr on success, or NULL + * on failure. + */ +virDomainCheckpointPtr +virDomainCheckpointCreateXML(virDomainPtr domain, + const char *xmlDesc, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "xmlDesc=%s, flags=0x%x", xmlDesc, flags); + + virResetLastError(); + + virCheckDomainReturn(domain, NULL); + conn = domain->conn; + + virCheckNonNullArgGoto(xmlDesc, error); + virCheckReadOnlyGoto(conn->flags, error); + + VIR_REQUIRE_FLAG_GOTO(VIR_DOMAIN_CHECKPOINT_CREATE_CURRENT, + VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE, + error); + + VIR_EXCLUSIVE_FLAGS_GOTO(VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE, + VIR_DOMAIN_CHECKPOINT_CREATE_NO_METADATA, + error); + + if (conn->driver->domainCheckpointCreateXML) { + virDomainCheckpointPtr ret; + ret = conn->driver->domainCheckpointCreateXML(domain, xmlDesc, flags); + if (!ret) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return NULL; +} + + +/** + * virDomainCheckpointGetXMLDesc: + * @checkpoint: a domain checkpoint object + * @flags: bitwise-OR of supported virDomainCheckpointXMLFlags + * + * Provide an XML description of the domain checkpoint. + * + * No security-sensitive data will be included unless @flags contains + * VIR_DOMAIN_CHECKPOINT_XML_SECURE; this flag is rejected on read-only + * connections.
As discussed in other places, I'm not convinced that storing a domain is needed with backups.
+ * + * Normally, the XML description includes an element giving a full + * description of the domain at the time the snapshot was created; to
Missed reference to snapshots.
+ * reduce parsing time, it will be suppressed when @flags contains + * VIR_DOMAIN_CHECKPOINT_XML_NO_DOMAIN. + * + * By default, the XML description contains only static information that + * does not change over time. However, when @flags contains + * VIR_DOMAIN_CHECKPOINT_XML_SIZE, each <disk> listing adds an additional + * attribute that shows an estimate of the current size in bytes that + * have been dirtied between the time the checkpoint was created and the + * current point in time. + * + * Returns a 0 terminated UTF-8 encoded XML instance, or NULL in case of error. + * the caller must free() the returned value. + */ +char * +virDomainCheckpointGetXMLDesc(virDomainCheckpointPtr checkpoint, + unsigned int flags) +{ + virConnectPtr conn; + VIR_DEBUG("checkpoint=%p, flags=0x%x", checkpoint, flags); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, NULL); + conn = checkpoint->domain->conn; + + if ((conn->flags & VIR_CONNECT_RO) && + (flags & VIR_DOMAIN_CHECKPOINT_XML_SECURE)) { + virReportError(VIR_ERR_OPERATION_DENIED, "%s", + _("virDomainCheckpointGetXMLDesc with secure flag")); + goto error; + } + + if (conn->driver->domainCheckpointGetXMLDesc) { + char *ret; + ret = conn->driver->domainCheckpointGetXMLDesc(checkpoint, flags); + if (!ret) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return NULL; +} + + +/** + * virDomainListCheckpoints: + * @domain: a domain object + * @checkpoints: pointer to variable to store the array containing checkpoint + * objects, or NULL if the list is not required (just returns + * number of checkpoints) + * @flags: bitwise-OR of supported virDomainCheckpoinListFlags
s/virDomainCheckpoinListFlags/virDomainCheckpointListFlags/
+ * + * Collect the list of domain checkpoints for the given domain, and allocate + * an array to store those objects. + * + * By default, this command covers all checkpoints; it is also possible to + * limit things to just checkpoints with no parents, when @flags includes + * VIR_DOMAIN_CHECKPOINT_LIST_ROOTS. Additional filters are provided in + * groups, where each group contains bits that describe mutually exclusive + * attributes of a checkpoint, and where all bits within a group describe + * all possible checkpoints. Some hypervisors might reject explicit bits + * from a group where the hypervisor cannot make a distinction. For a + * group supported by a given hypervisor, the behavior when no bits of a + * group are set is identical to the behavior when all bits in that group + * are set. When setting bits from more than one group, it is possible to + * select an impossible combination, in that case a hypervisor may return + * either 0 or an error. + * + * The first group of @flags is VIR_DOMAIN_CHECKPOINT_LIST_LEAVES and + * VIR_DOMAIN_CHECKPOINT_LIST_NO_LEAVES, to filter based on checkpoints that + * have no further children (a leaf checkpoint). + * + * The next group of @flags is VIR_DOMAIN_CHECKPOINT_LIST_METADATA and + * VIR_DOMAIN_CHECKPOINT_LIST_NO_METADATA, for filtering checkpoints based on + * whether they have metadata that would prevent the removal of the last + * reference to a domain. + * + * Returns the number of domain checkpoints found or -1 and sets @checkpoints + * to NULL in case of error. On success, the array stored into @checkpoints + * is guaranteed to have an extra allocated element set to NULL but not + * included in the return count, to make iteration easier. The caller is + * responsible for calling virDomainCheckpointFree() on each array element, + * then calling free() on @checkpoints. + */ +int +virDomainListCheckpoints(virDomainPtr domain, + virDomainCheckpointPtr **checkpoints, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "checkpoints=%p, flags=0x%x", checkpoints, flags); + + virResetLastError(); + + if (checkpoints) + *checkpoints = NULL; + + virCheckDomainReturn(domain, -1); + conn = domain->conn; + + if (conn->driver->domainListCheckpoints) { + int ret = conn->driver->domainListCheckpoints(domain, checkpoints, + flags); + if (ret < 0) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +}
[...]
+/** + * virDomainCheckpointIsCurrent: + * @checkpoint: a checkpoint object + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Determine if the given checkpoint is the domain's current checkpoint. See + * also virDomainHasCurrentCheckpoint().
Depending on whether 'current checkpoint' makes sense this might not be needed.
+ * + * Returns 1 if current, 0 if not current, or -1 on error. + */ +int +virDomainCheckpointIsCurrent(virDomainCheckpointPtr checkpoint, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DEBUG("checkpoint=%p, flags=0x%x", checkpoint, flags); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, -1); + conn = checkpoint->domain->conn; + + if (conn->driver->domainCheckpointIsCurrent) { + int ret; + ret = conn->driver->domainCheckpointIsCurrent(checkpoint, flags); + if (ret < 0) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} + + +/** + * virDomainCheckpointHasMetadata: + * @checkpoint: a checkpoint object + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Determine if the given checkpoint is associated with libvirt metadata + * that would prevent the deletion of the domain.
Given that we've never implemented metadata-less snapshots do we expect this to happen with checkpoints?
+ * Returns 1 if the checkpoint has metadata, 0 if the checkpoint exists without + * help from libvirt, or -1 on error. + */ +int +virDomainCheckpointHasMetadata(virDomainCheckpointPtr checkpoint, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DEBUG("checkpoint=%p, flags=0x%x", checkpoint, flags); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, -1); + conn = checkpoint->domain->conn; + + if (conn->driver->domainCheckpointHasMetadata) { + int ret; + ret = conn->driver->domainCheckpointHasMetadata(checkpoint, flags); + if (ret < 0) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} + + +/** + * virDomainCheckpointDelete: + * @checkpoint: the checkpoint to remove + * @flags: not used yet, pass 0 + * @flags: bitwise-OR of supported virDomainCheckpointDeleteFlags
@flags present twice
+ * + * Removes a checkpoint from the domain. + * + * When removing a checkpoint, the record of which portions of the + * disk were dirtied after the checkpoint will be merged into the + * record tracked by the parent checkpoint, if any.
So as a high-level question, since from the APIs added here is clear that we expect tree-like topologies of checkpoints. Does merging of the data _into_ the parent invalidate any other children? This is a big problem we'll be facing when doing external snapshot reversion.
Likewise, if the + * checkpoint being deleted was the current checkpoint, the parent + * checkpoint becomes the new current checkpoint. + * + * If @flags includes VIR_DOMAIN_CHECKPOINT_DELETE_METADATA_ONLY, then + * any checkpoint metadata tracked by libvirt is removed while keeping + * the checkpoint contents intact; if a hypervisor does not require + * any libvirt metadata to track checkpoints, then this flag is + * silently ignored. + * + * Returns 0 on success, -1 on error. + */ +int +virDomainCheckpointDelete(virDomainCheckpointPtr checkpoint, + unsigned int flags) +{ + virConnectPtr conn; + + VIR_DEBUG("checkpoint=%p, flags=0x%x", checkpoint, flags); + + virResetLastError(); + + virCheckDomainCheckpointReturn(checkpoint, -1); + conn = checkpoint->domain->conn; + + virCheckReadOnlyGoto(conn->flags, error); + + VIR_EXCLUSIVE_FLAGS_GOTO(VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN, + VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN_ONLY, + error); + + if (conn->driver->domainCheckpointDelete) { + int ret = conn->driver->domainCheckpointDelete(checkpoint, flags); + if (ret < 0) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +}

Introduce a few more new public APIs related to incremental backups. This builds on the previous notion of a checkpoint (without an existing checkpoint, the new API is a full backup, differing only from virDomainCopy in the point of time chosen); and also allows creation of a new checkpoint at the same time as starting the backup (after all, an incremental backup is only useful if it covers the state since the previous backup). It also enhances event reporting for signaling when a push model backup completes (where the hypervisor creates the backup); note that the pull model does not have an event (starting the backup lets a third party access the data, and only the third party knows when it is finished). The full list of new API: virDomainBackupBegin; virDomainBackupEnd; virDomainBackupGetXMLDesc; Signed-off-by: Eric Blake <eblake@redhat.com> --- include/libvirt/libvirt-domain-checkpoint.h | 21 ++ include/libvirt/libvirt-domain.h | 14 +- src/driver-hypervisor.h | 14 ++ src/libvirt-domain-checkpoint.c | 213 ++++++++++++++++++++ src/libvirt-domain.c | 8 +- src/libvirt_public.syms | 3 + tools/virsh-domain.c | 3 +- 7 files changed, 272 insertions(+), 4 deletions(-) diff --git a/include/libvirt/libvirt-domain-checkpoint.h b/include/libvirt/libvirt-domain-checkpoint.h index cfca8f4b7f..0631a082b3 100644 --- a/include/libvirt/libvirt-domain-checkpoint.h +++ b/include/libvirt/libvirt-domain-checkpoint.h @@ -153,4 +153,25 @@ int virDomainCheckpointDelete(virDomainCheckpointPtr checkpoint, int virDomainCheckpointRef(virDomainCheckpointPtr checkpoint); int virDomainCheckpointFree(virDomainCheckpointPtr checkpoint); +typedef enum { + VIR_DOMAIN_BACKUP_BEGIN_NO_METADATA = (1 << 0), /* Make checkpoint without + remembering it */ + /* TODO: VIR_DOMAIN_BACKUP_BEGIN_QUIESCE */ +} virDomainBackupBeginFlags; + +/* Begin an incremental backup job, possibly creating a checkpoint. */ +int virDomainBackupBegin(virDomainPtr domain, const char *diskXml, + const char *checkpointXml, unsigned int flags); + +/* Learn about an ongoing backup job. */ +char *virDomainBackupGetXMLDesc(virDomainPtr domain, int id, + unsigned int flags); + +typedef enum { + VIR_DOMAIN_BACKUP_END_ABORT = (1 << 0), /* Abandon a push model backup */ +} virDomainBackupEndFlags; + +/* Complete (or abort) an incremental backup job. */ +int virDomainBackupEnd(virDomainPtr domain, int id, unsigned int flags); + #endif /* __VIR_LIBVIRT_DOMAIN_CHECKPOINT_H__ */ diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index fdd2d6b8ea..11692e6ae1 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -4,7 +4,7 @@ * Description: Provides APIs for the management of domains * Author: Daniel Veillard <veillard@redhat.com> * - * Copyright (C) 2006-2015 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -3168,6 +3168,7 @@ typedef enum { VIR_DOMAIN_JOB_OPERATION_SNAPSHOT = 6, VIR_DOMAIN_JOB_OPERATION_SNAPSHOT_REVERT = 7, VIR_DOMAIN_JOB_OPERATION_DUMP = 8, + VIR_DOMAIN_JOB_OPERATION_BACKUP = 9, # ifdef VIR_ENUM_SENTINELS VIR_DOMAIN_JOB_OPERATION_LAST @@ -3183,6 +3184,14 @@ typedef enum { */ # define VIR_DOMAIN_JOB_OPERATION "operation" +/** + * VIR_DOMAIN_JOB_ID: + * + * virDomainGetJobStats field: the id of the job (so far, only for jobs + * started by virDomainBackupBegin()), as VIR_TYPED_PARAM_INT. + */ +# define VIR_DOMAIN_JOB_ID "id" + /** * VIR_DOMAIN_JOB_TIME_ELAPSED: * @@ -3997,7 +4006,8 @@ typedef void (*virConnectDomainEventMigrationIterationCallback)(virConnectPtr co * @nparams: size of the params array * @opaque: application specific data * - * This callback occurs when a job (such as migration) running on the domain + * This callback occurs when a job (such as migration or push-model + * virDomainBackupBegin()) running on the domain * is completed. The params array will contain statistics of the just completed * job as virDomainGetJobStats would return. The callback must not free @params * (the array will be freed once the callback finishes). diff --git a/src/driver-hypervisor.h b/src/driver-hypervisor.h index ee8a9a3e0e..2ae0b381a9 100644 --- a/src/driver-hypervisor.h +++ b/src/driver-hypervisor.h @@ -1369,6 +1369,17 @@ typedef int (*virDrvDomainCheckpointDelete)(virDomainCheckpointPtr checkpoint, unsigned int flags); +typedef int +(*virDrvDomainBackupBegin)(virDomainPtr domain, const char *diskXml, + const char *checkpointXml, unsigned int flags); + +typedef char * +(*virDrvDomainBackupGetXMLDesc)(virDomainPtr domain, int id, + unsigned int flags); + +typedef int +(*virDrvDomainBackupEnd)(virDomainPtr domain, int id, unsigned int flags); + typedef struct _virHypervisorDriver virHypervisorDriver; typedef virHypervisorDriver *virHypervisorDriverPtr; @@ -1630,6 +1641,9 @@ struct _virHypervisorDriver { virDrvDomainCheckpointIsCurrent domainCheckpointIsCurrent; virDrvDomainCheckpointHasMetadata domainCheckpointHasMetadata; virDrvDomainCheckpointDelete domainCheckpointDelete; + virDrvDomainBackupBegin domainBackupBegin; + virDrvDomainBackupGetXMLDesc domainBackupGetXMLDesc; + virDrvDomainBackupEnd domainBackupEnd; }; diff --git a/src/libvirt-domain-checkpoint.c b/src/libvirt-domain-checkpoint.c index 8a7b5b3c56..dd1dd82123 100644 --- a/src/libvirt-domain-checkpoint.c +++ b/src/libvirt-domain-checkpoint.c @@ -721,3 +721,216 @@ virDomainCheckpointFree(virDomainCheckpointPtr checkpoint) virObjectUnref(checkpoint); return 0; } + + +/** + * virDomainBackupBegin: + * @domain: a domain object + * @diskXml: description of storage to utilize and expose during + * the backup, or NULL + * @checkpointXml: description of a checkpoint to create, or NULL + * @flags: bitwise-OR of supported virDomainBackupBeginFlags + * + * Start a point-in-time backup job for the specified disks of a + * running domain. + * + * A backup job is mutually exclusive with domain migration + * (particularly when the job sets up an NBD export, since it is not + * possible to tell any NBD clients about a server migrating between + * hosts). For now, backup jobs are also mutually exclusive with any + * other block job on the same device, although this restriction may + * be lifted in a future release. Progress of the backup job can be + * tracked via virDomainGetJobStats(). The job remains active until a + * subsequent call to virDomainBackupEnd(), even if it no longer has + * anything to copy. + * + * This API differs from virDomainBlockCopy() in that it can grab the + * state of more than one disk in parallel, and the state is captured + * as of the start of the job, rather than the end. + * + * There are two fundamental backup approaches. The first, called a + * push model, instructs the hypervisor to copy the state of the guest + * disk to the designated storage destination (which may be on the + * local file system or a network device); in this mode, the + * hypervisor writes the content of the guest disk to the destination, + * then emits VIR_DOMAIN_EVENT_ID_JOB_COMPLETED when the backup is + * either complete or failed (the backup image is invalid if the job + * is ended prior to the event being emitted). The second, called a + * pull model, instructs the hypervisor to expose the state of the + * guest disk over an NBD export; a third-party client can then + * connect to this export, and read whichever portions of the disk it + * desires. In this mode, there is no event; libvirt has to be + * informed when the third-party NBD client is done and the backup + * resources can be released. + * + * The @diskXml parameter is optional but usually provided, and + * contains details about the backup, including which backup mode to + * use, whether the backup is incremental from a previous checkpoint, + * which disks participate in the backup, the destination for a push + * model backup, and the temporary storage and NBD server details for + * a pull model backup. If omitted, the backup attempts to default to + * a push mode full backup of all disks, where libvirt generates a + * filename for each disk by appending a suffix of a timestamp in + * seconds since the Epoch. virDomainBackupGetXMLDesc() can be called + * to learn actual values selected. For more information, see + * formatcheckpoint.html#BackupAttributes. + * + * The @checkpointXml parameter is optional; if non-NULL, then libvirt + * behaves as if virDomainCheckpointCreateXML() were called with + * @checkpointXml and the flag VIR_DOMAIN_BACKUP_BEGIN_NO_METADATA + * forwarded appropriately, atomically covering the same guest state + * that will be part of the backup. The creation of a new checkpoint + * allows for future incremental backups. Note that some hypervisors + * may require a particular disk format, such as qcow2, in order to + * take advantage of checkpoints, while allowing arbitrary formats + * if checkpoints are not involved. + * + * Returns a non-negative job id on success, or negative on failure. + * This operation returns quickly, such that a user can choose to + * start a backup job between virDomainFSFreeze() and + * virDomainFSThaw() in order to create the backup while guest I/O is + * quiesced. + */ +/* FIXME: Do we need a specific API for listing all current backup + * jobs (which, at the moment, is at most one job), or is it better to + * refactor other existing job APIs in libvirt-domain.c to have job-id + * counterparts along with a generic listing of all jobs (with flags + * for filtering to specific job types)? + */ +int +virDomainBackupBegin(virDomainPtr domain, const char *diskXml, + const char *checkpointXml, unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "diskXml=%s, checkpointXml=%s, flags=0x%x", + NULLSTR(diskXml), NULLSTR(checkpointXml), flags); + + virResetLastError(); + + virCheckDomainReturn(domain, -1); + conn = domain->conn; + + virCheckReadOnlyGoto(conn->flags, error); + if (flags & VIR_DOMAIN_BACKUP_BEGIN_NO_METADATA) + virCheckNonNullArgGoto(checkpointXml, error); + + if (conn->driver->domainBackupBegin) { + int ret; + ret = conn->driver->domainBackupBegin(domain, diskXml, checkpointXml, + flags); + if (!ret) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} + + +/** + * virDomainBackupGetXMLDesc: + * @domain: a domain object + * @id: the id of an active backup job previously started with + * virDomainBackupBegin() + * @flags: bitwise-OR of subset of virDomainXMLFlags + * + * In some cases, a user can start a backup job without supplying all + * details, and rely on libvirt to fill in the rest (for example, + * selecting the port used for an NBD export). This API can then be + * used to learn what default values were chosen. + * + * No security-sensitive data will be included unless @flags contains + * VIR_DOMAIN_XML_SECURE; this flag is rejected on read-only + * connections. For this API, @flags should not contain either + * VIR_DOMAIN_XML_INACTIVE or VIR_DOMAIN_XML_UPDATE_CPU. + * + * Returns a NUL-terminated UTF-8 encoded XML instance, or NULL in + * case of error. The caller must free() the returned value. + */ +char * +virDomainBackupGetXMLDesc(virDomainPtr domain, int id, unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "id=%d, flags=0x%x", id, flags); + + virResetLastError(); + + virCheckDomainReturn(domain, NULL); + conn = domain->conn; + + if ((conn->flags & VIR_CONNECT_RO) && + (flags & VIR_DOMAIN_CHECKPOINT_XML_SECURE)) { + virReportError(VIR_ERR_OPERATION_DENIED, "%s", + _("virDomainCheckpointGetXMLDesc with secure flag")); + goto error; + } + virCheckNonNegativeArgGoto(id, error); + + if (conn->driver->domainBackupGetXMLDesc) { + char *ret; + ret = conn->driver->domainBackupGetXMLDesc(domain, id, flags); + if (!ret) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return NULL; +} + + +/** + * virDomainBackupEnd: + * @domain: a domain object + * @id: the id of an active backup job previously started with + * virDomainBackupBegin() + * @flags: bitwise-OR of supported virDomainBackupEndFlags + * + * Conclude a point-in-time backup job @id on the given domain. + * + * If the backup job uses the push model, but the event marking that + * all data has been copied has not yet been emitted, then the command + * fails unless @flags includes VIR_DOMAIN_BACKUP_END_ABORT. If the + * event has been issued, or if the backup uses the pull model, the + * flag has no effect. + * + * Returns 1 if the backup job completed successfully (the backup + * destination file in a push model is consistent), 0 if the job was + * aborted successfully (only when VIR_DOMAIN_BACKUP_END_ABORT is + * passed; the destination file is unusable), and -1 on failure. + */ +int +virDomainBackupEnd(virDomainPtr domain, int id, unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "id=%d, flags=0x%x", id, flags); + + virResetLastError(); + + virCheckDomainReturn(domain, -1); + conn = domain->conn; + + virCheckReadOnlyGoto(conn->flags, error); + virCheckNonNegativeArgGoto(id, error); + + if (conn->driver->domainBackupEnd) { + int ret; + ret = conn->driver->domainBackupEnd(domain, id, flags); + if (!ret) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 7690339521..002d214880 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -1,7 +1,7 @@ /* * libvirt-domain.c: entry points for virDomainPtr APIs * - * Copyright (C) 2006-2015 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -10261,6 +10261,12 @@ virDomainBlockRebase(virDomainPtr dom, const char *disk, * over the destination format, the ability to copy to a destination that * is not a local file, and the possibility of additional tuning parameters. * + * The copy created by this API is not finalized until the job ends, + * and does not lend itself to incremental backups (beyond what + * VIR_DOMAIN_BLOCK_COPY_SHALLOW provides) nor to third-party control + * over the data being copied. For those features, use + * virDomainBackupBegin(). + * * Returns 0 if the operation has started, -1 on failure. */ int diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms index fb58b95344..61a5085dcb 100644 --- a/src/libvirt_public.syms +++ b/src/libvirt_public.syms @@ -811,6 +811,9 @@ LIBVIRT_4.5.0 { LIBVIRT_4.9.0 { global: + virDomainBackupBegin; + virDomainBackupEnd; + virDomainBackupGetXMLDesc; virDomainCheckpointCreateXML; virDomainCheckpointCurrent; virDomainCheckpointDelete; diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 372bdb95d3..ba4a0f5310 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -6069,7 +6069,8 @@ VIR_ENUM_IMPL(virshDomainJobOperation, N_("Outgoing migration"), N_("Snapshot"), N_("Snapshot revert"), - N_("Dump")) + N_("Dump"), + N_("Backup")) static const char * virshDomainJobOperationToString(int op) -- 2.17.1

On Fri, Oct 12, 2018 at 00:10:09 -0500, Eric Blake wrote:
Introduce a few more new public APIs related to incremental backups. This builds on the previous notion of a checkpoint (without an existing checkpoint, the new API is a full backup, differing only from virDomainCopy in the point of time chosen); and also allows creation of a new checkpoint at the same time as starting the backup (after all, an incremental backup is only useful if it covers the state since the previous backup). It also enhances event reporting for signaling when a push model backup completes (where the hypervisor creates the backup); note that the pull model does not have an event (starting the backup lets a third party access the data, and only the third party knows when it is finished).
The full list of new API: virDomainBackupBegin; virDomainBackupEnd; virDomainBackupGetXMLDesc;
Signed-off-by: Eric Blake <eblake@redhat.com> --- include/libvirt/libvirt-domain-checkpoint.h | 21 ++ include/libvirt/libvirt-domain.h | 14 +- src/driver-hypervisor.h | 14 ++ src/libvirt-domain-checkpoint.c | 213 ++++++++++++++++++++ src/libvirt-domain.c | 8 +- src/libvirt_public.syms | 3 + tools/virsh-domain.c | 3 +- 7 files changed, 272 insertions(+), 4 deletions(-)
[...]
diff --git a/src/libvirt-domain-checkpoint.c b/src/libvirt-domain-checkpoint.c index 8a7b5b3c56..dd1dd82123 100644 --- a/src/libvirt-domain-checkpoint.c +++ b/src/libvirt-domain-checkpoint.c @@ -721,3 +721,216 @@ virDomainCheckpointFree(virDomainCheckpointPtr checkpoint) virObjectUnref(checkpoint); return 0; } + + +/** + * virDomainBackupBegin: + * @domain: a domain object + * @diskXml: description of storage to utilize and expose during + * the backup, or NULL + * @checkpointXml: description of a checkpoint to create, or NULL + * @flags: bitwise-OR of supported virDomainBackupBeginFlags + * + * Start a point-in-time backup job for the specified disks of a + * running domain. + * + * A backup job is mutually exclusive with domain migration + * (particularly when the job sets up an NBD export, since it is not + * possible to tell any NBD clients about a server migrating between + * hosts). For now, backup jobs are also mutually exclusive with any + * other block job on the same device, although this restriction may + * be lifted in a future release. Progress of the backup job can be
Hypervisors may not allow this job if other block devices are part of other block jobs.
+ * tracked via virDomainGetJobStats(). The job remains active until a
How is this going to track multiple jobs?
+ * subsequent call to virDomainBackupEnd(), even if it no longer has + * anything to copy. + * + * This API differs from virDomainBlockCopy() in that it can grab the + * state of more than one disk in parallel, and the state is captured + * as of the start of the job, rather than the end.
As I've mentioned in previous responses, the idea/semantics of virDomainBlockCopy are different so I'd refrain from mentioning it here.
+ * + * There are two fundamental backup approaches. The first, called a + * push model, instructs the hypervisor to copy the state of the guest + * disk to the designated storage destination (which may be on the + * local file system or a network device); in this mode, the + * hypervisor writes the content of the guest disk to the destination, + * then emits VIR_DOMAIN_EVENT_ID_JOB_COMPLETED when the backup is + * either complete or failed (the backup image is invalid if the job + * is ended prior to the event being emitted). The second, called a + * pull model, instructs the hypervisor to expose the state of the + * guest disk over an NBD export; a third-party client can then + * connect to this export, and read whichever portions of the disk it + * desires. In this mode, there is no event; libvirt has to be + * informed when the third-party NBD client is done and the backup + * resources can be released. + * + * The @diskXml parameter is optional but usually provided, and + * contains details about the backup, including which backup mode to + * use, whether the backup is incremental from a previous checkpoint, + * which disks participate in the backup, the destination for a push + * model backup, and the temporary storage and NBD server details for + * a pull model backup. If omitted, the backup attempts to default to + * a push mode full backup of all disks, where libvirt generates a + * filename for each disk by appending a suffix of a timestamp in
Do we really want to support this convenience option?
+ * seconds since the Epoch. virDomainBackupGetXMLDesc() can be called + * to learn actual values selected. For more information, see + * formatcheckpoint.html#BackupAttributes. + * + * The @checkpointXml parameter is optional; if non-NULL, then libvirt + * behaves as if virDomainCheckpointCreateXML() were called with + * @checkpointXml and the flag VIR_DOMAIN_BACKUP_BEGIN_NO_METADATA + * forwarded appropriately, atomically covering the same guest state + * that will be part of the backup. The creation of a new checkpoint + * allows for future incremental backups. Note that some hypervisors + * may require a particular disk format, such as qcow2, in order to + * take advantage of checkpoints, while allowing arbitrary formats + * if checkpoints are not involved. + * + * Returns a non-negative job id on success, or negative on failure. + * This operation returns quickly, such that a user can choose to + * start a backup job between virDomainFSFreeze() and + * virDomainFSThaw() in order to create the backup while guest I/O is + * quiesced. + */ +/* FIXME: Do we need a specific API for listing all current backup + * jobs (which, at the moment, is at most one job), or is it better to + * refactor other existing job APIs in libvirt-domain.c to have job-id + * counterparts along with a generic listing of all jobs (with flags + * for filtering to specific job types)?
This concern itself should be a warning that we should not push this until a full implementation is provided, so that we know that the job handling APIs will be enough. You probably also need an API to list the job if a client loses the job id somehow, since all the other APIs below take it. Additionally since I'm currently working on re-doing blockjobs to support -blockdev and friends, one of the steps involves changing from the 'block-job-***' QMP apis to the newer 'job-**' APIs so that 'blockdev-create' can be supported. Is there any overlap with the backup APIs? Specifically number-based names for 'job-**' are less than sub-optimal, but in this case we could map from them to a proper name. At any rate, if the backup work requires to use the 'job-***' APIs we'll need to find an intersection.
+int +virDomainBackupBegin(virDomainPtr domain, const char *diskXml, + const char *checkpointXml, unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "diskXml=%s, checkpointXml=%s, flags=0x%x", + NULLSTR(diskXml), NULLSTR(checkpointXml), flags); + + virResetLastError(); + + virCheckDomainReturn(domain, -1); + conn = domain->conn; + + virCheckReadOnlyGoto(conn->flags, error); + if (flags & VIR_DOMAIN_BACKUP_BEGIN_NO_METADATA) + virCheckNonNullArgGoto(checkpointXml, error); + + if (conn->driver->domainBackupBegin) { + int ret; + ret = conn->driver->domainBackupBegin(domain, diskXml, checkpointXml, + flags); + if (!ret) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +} + + +/** + * virDomainBackupGetXMLDesc: + * @domain: a domain object + * @id: the id of an active backup job previously started with + * virDomainBackupBegin() + * @flags: bitwise-OR of subset of virDomainXMLFlags + * + * In some cases, a user can start a backup job without supplying all + * details, and rely on libvirt to fill in the rest (for example, + * selecting the port used for an NBD export). This API can then be + * used to learn what default values were chosen. + * + * No security-sensitive data will be included unless @flags contains + * VIR_DOMAIN_XML_SECURE; this flag is rejected on read-only + * connections. For this API, @flags should not contain either + * VIR_DOMAIN_XML_INACTIVE or VIR_DOMAIN_XML_UPDATE_CPU.
I fail to see why the full domain XML should be part of the backup job description.
+ * + * Returns a NUL-terminated UTF-8 encoded XML instance, or NULL in + * case of error. The caller must free() the returned value. + */ +char * +virDomainBackupGetXMLDesc(virDomainPtr domain, int id, unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "id=%d, flags=0x%x", id, flags); + + virResetLastError(); + + virCheckDomainReturn(domain, NULL); + conn = domain->conn; + + if ((conn->flags & VIR_CONNECT_RO) && + (flags & VIR_DOMAIN_CHECKPOINT_XML_SECURE)) {
Wrong flag name.
+ virReportError(VIR_ERR_OPERATION_DENIED, "%s", + _("virDomainCheckpointGetXMLDesc with secure flag")); + goto error; + } + virCheckNonNegativeArgGoto(id, error); + + if (conn->driver->domainBackupGetXMLDesc) { + char *ret; + ret = conn->driver->domainBackupGetXMLDesc(domain, id, flags); + if (!ret) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return NULL; +} + + +/** + * virDomainBackupEnd: + * @domain: a domain object + * @id: the id of an active backup job previously started with + * virDomainBackupBegin() + * @flags: bitwise-OR of supported virDomainBackupEndFlags + * + * Conclude a point-in-time backup job @id on the given domain. + * + * If the backup job uses the push model, but the event marking that + * all data has been copied has not yet been emitted, then the command + * fails unless @flags includes VIR_DOMAIN_BACKUP_END_ABORT. If the + * event has been issued, or if the backup uses the pull model, the + * flag has no effect. + * + * Returns 1 if the backup job completed successfully (the backup + * destination file in a push model is consistent), 0 if the job was + * aborted successfully (only when VIR_DOMAIN_BACKUP_END_ABORT is + * passed; the destination file is unusable), and -1 on failure. + */ +int +virDomainBackupEnd(virDomainPtr domain, int id, unsigned int flags) +{ + virConnectPtr conn; + + VIR_DOMAIN_DEBUG(domain, "id=%d, flags=0x%x", id, flags); + + virResetLastError(); + + virCheckDomainReturn(domain, -1); + conn = domain->conn; + + virCheckReadOnlyGoto(conn->flags, error); + virCheckNonNegativeArgGoto(id, error); + + if (conn->driver->domainBackupEnd) { + int ret; + ret = conn->driver->domainBackupEnd(domain, id, flags); + if (!ret) + goto error; + return ret; + } + + virReportUnsupportedError(); + error: + virDispatchError(conn); + return -1; +}
[...]
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 7690339521..002d214880 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -1,7 +1,7 @@ /* * libvirt-domain.c: entry points for virDomainPtr APIs * - * Copyright (C) 2006-2015 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -10261,6 +10261,12 @@ virDomainBlockRebase(virDomainPtr dom, const char *disk, * over the destination format, the ability to copy to a destination that * is not a local file, and the possibility of additional tuning parameters. * + * The copy created by this API is not finalized until the job ends, + * and does not lend itself to incremental backups (beyond what + * VIR_DOMAIN_BLOCK_COPY_SHALLOW provides) nor to third-party control + * over the data being copied. For those features, use + * virDomainBackupBegin().
This is certainly misplaced. Please put it in a separate commit with proper justification. [...]

On 10/12/18 9:02 AM, Peter Krempa wrote:
On Fri, Oct 12, 2018 at 00:10:09 -0500, Eric Blake wrote:
Introduce a few more new public APIs related to incremental backups. This builds on the previous notion of a checkpoint (without an existing checkpoint, the new API is a full backup, differing only from virDomainCopy in the point of time chosen); and also allows creation of a new checkpoint at the same time as starting the backup (after all, an incremental backup is only useful if it covers the state since the previous backup). It also enhances event reporting for signaling when a push model backup completes (where the hypervisor creates the backup); note that the pull model does not have an event (starting the backup lets a third party access the data, and only the third party knows when it is finished).
The full list of new API: virDomainBackupBegin; virDomainBackupEnd; virDomainBackupGetXMLDesc;
Skipping wording improvements for now (which I will probably incorporate without question), and focusing on:
+ * Start a point-in-time backup job for the specified disks of a + * running domain. + * + * A backup job is mutually exclusive with domain migration + * (particularly when the job sets up an NBD export, since it is not + * possible to tell any NBD clients about a server migrating between + * hosts). For now, backup jobs are also mutually exclusive with any + * other block job on the same device, although this restriction may + * be lifted in a future release. Progress of the backup job can be
Hypervisors may not allow this job if other block devices are part of other block jobs.
+ * tracked via virDomainGetJobStats(). The job remains active until a
How is this going to track multiple jobs?
Yeah, that's already become obvious to me that we really don't have any GOOD design in place for multiple parallel jobs. At the moment, qemu itself is hard-coded to at most one NBD server (and thus at most one pull backup job), but I really don't want the backup APIs to be held hostage to also fixing the fact that libvirt needs a generic API for multiple parallel jobs. At a high level, what I imagine is a parallel set of APIs that takes a job id everywhere, as well as a way to set the "default" job id. All existing APIs, such as virDomainGetJobStats(), would then have documentation updated to state that they work on the "default" job, and APIs that start a job but do not return a job id implicitly change the "default" job.
+ * The @diskXml parameter is optional but usually provided, and + * contains details about the backup, including which backup mode to + * use, whether the backup is incremental from a previous checkpoint, + * which disks participate in the backup, the destination for a push + * model backup, and the temporary storage and NBD server details for + * a pull model backup. If omitted, the backup attempts to default to + * a push mode full backup of all disks, where libvirt generates a + * filename for each disk by appending a suffix of a timestamp in
Do we really want to support this convenience option?
It's always possible to make things mandatory initially, then relax things to optional later. I can make those sorts of tweaks once I have the qemu code demonstration working (KVM Forum is next week - it will be interesting to see how much I have in place).
+ * seconds since the Epoch. virDomainBackupGetXMLDesc() can be called + * to learn actual values selected. For more information, see + * formatcheckpoint.html#BackupAttributes. + * + * The @checkpointXml parameter is optional; if non-NULL, then libvirt + * behaves as if virDomainCheckpointCreateXML() were called with + * @checkpointXml and the flag VIR_DOMAIN_BACKUP_BEGIN_NO_METADATA + * forwarded appropriately, atomically covering the same guest state + * that will be part of the backup. The creation of a new checkpoint + * allows for future incremental backups. Note that some hypervisors + * may require a particular disk format, such as qcow2, in order to + * take advantage of checkpoints, while allowing arbitrary formats + * if checkpoints are not involved. + * + * Returns a non-negative job id on success, or negative on failure. + * This operation returns quickly, such that a user can choose to + * start a backup job between virDomainFSFreeze() and + * virDomainFSThaw() in order to create the backup while guest I/O is + * quiesced. + */ +/* FIXME: Do we need a specific API for listing all current backup + * jobs (which, at the moment, is at most one job), or is it better to + * refactor other existing job APIs in libvirt-domain.c to have job-id + * counterparts along with a generic listing of all jobs (with flags + * for filtering to specific job types)?
This concern itself should be a warning that we should not push this until a full implementation is provided, so that we know that the job handling APIs will be enough.
You probably also need an API to list the job if a client loses the job id somehow, since all the other APIs below take it.
Yes, anything smarter than "the job id is always 1 because we don't support parallel jobs yet" will need an API for getting the id again.
Additionally since I'm currently working on re-doing blockjobs to support -blockdev and friends, one of the steps involves changing from the 'block-job-***' QMP apis to the newer 'job-**' APIs so that 'blockdev-create' can be supported. Is there any overlap with the backup APIs? Specifically number-based names for 'job-**' are less than sub-optimal, but in this case we could map from them to a proper name.
Would it be better to return a char* job name, and/or let the user request a job name of their choice in the XML? That's doable, but it does have ripple effects on the entire design, so it's the sort of thing that we DO want to figure out before promoting this into a release.
At any rate, if the backup work requires to use the 'job-***' APIs we'll need to find an intersection.
My initial implementation is using blockdev-backup, but yes, we want to use the job-*** APIs where possible.
+/** + * virDomainBackupGetXMLDesc: + * @domain: a domain object + * @id: the id of an active backup job previously started with + * virDomainBackupBegin() + * @flags: bitwise-OR of subset of virDomainXMLFlags + * + * In some cases, a user can start a backup job without supplying all + * details, and rely on libvirt to fill in the rest (for example, + * selecting the port used for an NBD export). This API can then be + * used to learn what default values were chosen. + * + * No security-sensitive data will be included unless @flags contains + * VIR_DOMAIN_XML_SECURE; this flag is rejected on read-only + * connections. For this API, @flags should not contain either + * VIR_DOMAIN_XML_INACTIVE or VIR_DOMAIN_XML_UPDATE_CPU.
I fail to see why the full domain XML should be part of the backup job description.
It's not. It remains a useful part of the checkpoint XML, but I'm dropping it from the backup XML - _if_ we keep <domaincheckpoint> and <domainbackup> as separate XML arguments. Then again, I still have the open question about how to extend checkpoints onto external snapshots. There are two viable approaches to consider: 1. expand existing <domainsnapshot> XML to take <domainbackup> as a subelement, then we can atomically create checkpoints as part of the existing virDomainSnapshotCreateXML - if we do this, then virDomainBackupBegin() should take only one XML argument, where <domainsnapshot> is a subelement of <domainbackup> 2. add a new API that parallels virDomainSnapshotCreateXML but takes an additional XML argument for creating a checkpoint at the same time - if we do this, then virDomainBackupBegin() remains in its current style of two XML arguments. Depending on which approach we like better, the flags here may make sense after all. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org

Creating a checkpoint does not modify guest-visible state, but does modify host resources. Rather than reuse existing domain:write, domain:block_write, or domain:snapshot access controls, it seems better to introduce a new access control specific to tasks related to checkpoints and incremental backups of guest disk state. Signed-off-by: Eric Blake <eblake@redhat.com> --- src/access/viraccessperm.h | 8 +++++++- src/access/viraccessperm.c | 5 +++-- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/src/access/viraccessperm.h b/src/access/viraccessperm.h index 5ac5ff3377..c6fd31dcc0 100644 --- a/src/access/viraccessperm.h +++ b/src/access/viraccessperm.h @@ -1,7 +1,7 @@ /* * viraccessperm.h: access control permissions * - * Copyright (C) 2012-2014 Red Hat, Inc. + * Copyright (C) 2012-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -186,6 +186,12 @@ typedef enum { */ VIR_ACCESS_PERM_DOMAIN_MIGRATE, /* Host migration */ + /** + * @desc: Checkpoint domain + * @message: Checkpointing domain requires authorization + */ + VIR_ACCESS_PERM_DOMAIN_CHECKPOINT, /* Checkpoint disks */ + /** * @desc: Snapshot domain * @message: Snapshotting domain requires authorization diff --git a/src/access/viraccessperm.c b/src/access/viraccessperm.c index d7cbb70b7b..5cb14d4cd8 100644 --- a/src/access/viraccessperm.c +++ b/src/access/viraccessperm.c @@ -1,7 +1,7 @@ /* * viraccessperm.c: access control permissions * - * Copyright (C) 2012-2014 Red Hat, Inc. + * Copyright (C) 2012-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -38,7 +38,8 @@ VIR_ENUM_IMPL(virAccessPermDomain, "getattr", "read", "write", "read_secure", "start", "stop", "reset", "save", "delete", - "migrate", "snapshot", "suspend", "hibernate", "core_dump", "pm_control", + "migrate", "checkpoint", "snapshot", "suspend", "hibernate", + "core_dump", "pm_control", "init_control", "inject_nmi", "send_input", "send_signal", "fs_trim", "fs_freeze", "block_read", "block_write", "mem_read", -- 2.17.1

The remote code generator had to be taught about the new virDomainCheckpointPtr type, at which point the remote driver code for backups can be generated. Signed-off-by: Eric Blake <eblake@redhat.com> --- src/remote/remote_daemon_dispatch.c | 15 ++ src/remote/remote_driver.c | 33 +++- src/remote/remote_protocol.x | 240 +++++++++++++++++++++++++++- src/remote_protocol-structs | 129 +++++++++++++++ src/rpc/gendispatch.pl | 32 ++-- 5 files changed, 430 insertions(+), 19 deletions(-) diff --git a/src/remote/remote_daemon_dispatch.c b/src/remote/remote_daemon_dispatch.c index e62ebfb596..09fda113a8 100644 --- a/src/remote/remote_daemon_dispatch.c +++ b/src/remote/remote_daemon_dispatch.c @@ -91,6 +91,7 @@ static virStorageVolPtr get_nonnull_storage_vol(virConnectPtr conn, remote_nonnu static virSecretPtr get_nonnull_secret(virConnectPtr conn, remote_nonnull_secret secret); static virNWFilterPtr get_nonnull_nwfilter(virConnectPtr conn, remote_nonnull_nwfilter nwfilter); static virNWFilterBindingPtr get_nonnull_nwfilter_binding(virConnectPtr conn, remote_nonnull_nwfilter_binding binding); +static virDomainCheckpointPtr get_nonnull_domain_checkpoint(virDomainPtr dom, remote_nonnull_domain_checkpoint checkpoint); static virDomainSnapshotPtr get_nonnull_domain_snapshot(virDomainPtr dom, remote_nonnull_domain_snapshot snapshot); static virNodeDevicePtr get_nonnull_node_device(virConnectPtr conn, remote_nonnull_node_device dev); static void make_nonnull_domain(remote_nonnull_domain *dom_dst, virDomainPtr dom_src); @@ -102,6 +103,7 @@ static void make_nonnull_node_device(remote_nonnull_node_device *dev_dst, virNod static void make_nonnull_secret(remote_nonnull_secret *secret_dst, virSecretPtr secret_src); static void make_nonnull_nwfilter(remote_nonnull_nwfilter *net_dst, virNWFilterPtr nwfilter_src); static void make_nonnull_nwfilter_binding(remote_nonnull_nwfilter_binding *binding_dst, virNWFilterBindingPtr binding_src); +static void make_nonnull_domain_checkpoint(remote_nonnull_domain_checkpoint *checkpoint_dst, virDomainCheckpointPtr checkpoint_src); static void make_nonnull_domain_snapshot(remote_nonnull_domain_snapshot *snapshot_dst, virDomainSnapshotPtr snapshot_src); static int @@ -7093,6 +7095,12 @@ get_nonnull_nwfilter_binding(virConnectPtr conn, remote_nonnull_nwfilter_binding return virGetNWFilterBinding(conn, binding.portdev, binding.filtername); } +static virDomainCheckpointPtr +get_nonnull_domain_checkpoint(virDomainPtr dom, remote_nonnull_domain_checkpoint checkpoint) +{ + return virGetDomainCheckpoint(dom, checkpoint.name); +} + static virDomainSnapshotPtr get_nonnull_domain_snapshot(virDomainPtr dom, remote_nonnull_domain_snapshot snapshot) { @@ -7172,6 +7180,13 @@ make_nonnull_nwfilter_binding(remote_nonnull_nwfilter_binding *binding_dst, virN ignore_value(VIR_STRDUP_QUIET(binding_dst->filtername, binding_src->filtername)); } +static void +make_nonnull_domain_checkpoint(remote_nonnull_domain_checkpoint *checkpoint_dst, virDomainCheckpointPtr checkpoint_src) +{ + ignore_value(VIR_STRDUP_QUIET(checkpoint_dst->name, checkpoint_src->name)); + make_nonnull_domain(&checkpoint_dst->dom, checkpoint_src->domain); +} + static void make_nonnull_domain_snapshot(remote_nonnull_domain_snapshot *snapshot_dst, virDomainSnapshotPtr snapshot_src) { diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 3b43e219e5..9c3501cba3 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -2,7 +2,7 @@ * remote_driver.c: driver to provide access to libvirtd running * on a remote machine * - * Copyright (C) 2007-2015 Red Hat, Inc. + * Copyright (C) 2007-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -147,6 +147,7 @@ static virStoragePoolPtr get_nonnull_storage_pool(virConnectPtr conn, remote_non static virStorageVolPtr get_nonnull_storage_vol(virConnectPtr conn, remote_nonnull_storage_vol vol); static virNodeDevicePtr get_nonnull_node_device(virConnectPtr conn, remote_nonnull_node_device dev); static virSecretPtr get_nonnull_secret(virConnectPtr conn, remote_nonnull_secret secret); +static virDomainCheckpointPtr get_nonnull_domain_checkpoint(virDomainPtr domain, remote_nonnull_domain_checkpoint checkpoint); static virDomainSnapshotPtr get_nonnull_domain_snapshot(virDomainPtr domain, remote_nonnull_domain_snapshot snapshot); static void make_nonnull_domain(remote_nonnull_domain *dom_dst, virDomainPtr dom_src); static void make_nonnull_network(remote_nonnull_network *net_dst, virNetworkPtr net_src); @@ -158,6 +159,7 @@ make_nonnull_node_device(remote_nonnull_node_device *dev_dst, virNodeDevicePtr d static void make_nonnull_secret(remote_nonnull_secret *secret_dst, virSecretPtr secret_src); static void make_nonnull_nwfilter(remote_nonnull_nwfilter *nwfilter_dst, virNWFilterPtr nwfilter_src); static void make_nonnull_nwfilter_binding(remote_nonnull_nwfilter_binding *binding_dst, virNWFilterBindingPtr binding_src); +static void make_nonnull_domain_checkpoint(remote_nonnull_domain_checkpoint *checkpoint_dst, virDomainCheckpointPtr checkpoint_src); static void make_nonnull_domain_snapshot(remote_nonnull_domain_snapshot *snapshot_dst, virDomainSnapshotPtr snapshot_src); /*----------------------------------------------------------------------*/ @@ -8214,6 +8216,12 @@ get_nonnull_nwfilter_binding(virConnectPtr conn, remote_nonnull_nwfilter_binding return virGetNWFilterBinding(conn, binding.portdev, binding.filtername); } +static virDomainCheckpointPtr +get_nonnull_domain_checkpoint(virDomainPtr domain, remote_nonnull_domain_checkpoint checkpoint) +{ + return virGetDomainCheckpoint(domain, checkpoint.name); +} + static virDomainSnapshotPtr get_nonnull_domain_snapshot(virDomainPtr domain, remote_nonnull_domain_snapshot snapshot) { @@ -8288,6 +8296,13 @@ make_nonnull_nwfilter_binding(remote_nonnull_nwfilter_binding *binding_dst, virN binding_dst->filtername = binding_src->filtername; } +static void +make_nonnull_domain_checkpoint(remote_nonnull_domain_checkpoint *checkpoint_dst, virDomainCheckpointPtr checkpoint_src) +{ + checkpoint_dst->name = checkpoint_src->name; + make_nonnull_domain(&checkpoint_dst->dom, checkpoint_src->domain); +} + static void make_nonnull_domain_snapshot(remote_nonnull_domain_snapshot *snapshot_dst, virDomainSnapshotPtr snapshot_src) { @@ -8536,7 +8551,21 @@ static virHypervisorDriver hypervisor_driver = { .connectCompareHypervisorCPU = remoteConnectCompareHypervisorCPU, /* 4.4.0 */ .connectBaselineHypervisorCPU = remoteConnectBaselineHypervisorCPU, /* 4.4.0 */ .nodeGetSEVInfo = remoteNodeGetSEVInfo, /* 4.5.0 */ - .domainGetLaunchSecurityInfo = remoteDomainGetLaunchSecurityInfo /* 4.5.0 */ + .domainGetLaunchSecurityInfo = remoteDomainGetLaunchSecurityInfo, /* 4.5.0 */ + .domainCheckpointCreateXML = remoteDomainCheckpointCreateXML, /* 4.9.0 */ + .domainCheckpointGetXMLDesc = remoteDomainCheckpointGetXMLDesc, /* 4.9.0 */ + .domainListCheckpoints = remoteDomainListCheckpoints, /* 4.9.0 */ + .domainCheckpointListChildren = remoteDomainCheckpointListChildren, /* 4.9.0 */ + .domainCheckpointLookupByName = remoteDomainCheckpointLookupByName, /* 4.9.0 */ + .domainHasCurrentCheckpoint = remoteDomainHasCurrentCheckpoint, /* 4.9.0 */ + .domainCheckpointGetParent = remoteDomainCheckpointGetParent, /* 4.9.0 */ + .domainCheckpointCurrent = remoteDomainCheckpointCurrent, /* 4.9.0 */ + .domainCheckpointIsCurrent = remoteDomainCheckpointIsCurrent, /* 4.9.0 */ + .domainCheckpointHasMetadata = remoteDomainCheckpointHasMetadata, /* 4.9.0 */ + .domainCheckpointDelete = remoteDomainCheckpointDelete, /* 4.9.0 */ + .domainBackupBegin = remoteDomainBackupBegin, /* 4.9.0 */ + .domainBackupGetXMLDesc = remoteDomainBackupGetXMLDesc, /* 4.9.0 */ + .domainBackupEnd = remoteDomainBackupEnd, /* 4.9.0 */ }; static virNetworkDriver network_driver = { diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x index 28c8febabd..1e9632743a 100644 --- a/src/remote/remote_protocol.x +++ b/src/remote/remote_protocol.x @@ -3,7 +3,7 @@ * remote_internal driver and libvirtd. This protocol is * internal and may change at any time. * - * Copyright (C) 2006-2015 Red Hat, Inc. + * Copyright (C) 2006-2018 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -139,6 +139,9 @@ const REMOTE_AUTH_TYPE_LIST_MAX = 20; /* Upper limit on list of memory stats */ const REMOTE_DOMAIN_MEMORY_STATS_MAX = 1024; +/* Upper limit on lists of domain checkpoints. */ +const REMOTE_DOMAIN_CHECKPOINT_LIST_MAX = 16384; + /* Upper limit on lists of domain snapshots. */ const REMOTE_DOMAIN_SNAPSHOT_LIST_MAX = 16384; @@ -321,6 +324,12 @@ struct remote_nonnull_secret { remote_nonnull_string usageID; }; +/* A checkpoint which may not be NULL. */ +struct remote_nonnull_domain_checkpoint { + remote_nonnull_string name; + remote_nonnull_domain dom; +}; + /* A snapshot which may not be NULL. */ struct remote_nonnull_domain_snapshot { remote_nonnull_string name; @@ -3556,6 +3565,137 @@ struct remote_connect_list_all_nwfilter_bindings_ret { /* insert@1 */ remote_nonnull_nwfilter_binding bindings<REMOTE_NWFILTER_BINDING_LIST_MAX>; unsigned int ret; }; +struct remote_domain_checkpoint_create_xml_args { + remote_nonnull_domain dom; + remote_nonnull_string xml_desc; + unsigned int flags; +}; + +struct remote_domain_checkpoint_create_xml_ret { + remote_nonnull_domain_checkpoint checkpoint; +}; + +struct remote_domain_checkpoint_get_xml_desc_args { + remote_nonnull_domain_checkpoint checkpoint; + unsigned int flags; +}; + +struct remote_domain_checkpoint_get_xml_desc_ret { + remote_nonnull_string xml; +}; + +struct remote_domain_list_checkpoints_args { + remote_nonnull_domain dom; + int need_results; + unsigned int flags; +}; + +struct remote_domain_list_checkpoints_ret { /* insert@1 */ + remote_nonnull_domain_checkpoint checkpoints<REMOTE_DOMAIN_CHECKPOINT_LIST_MAX>; + int ret; +}; + +struct remote_domain_checkpoint_list_children_args { + remote_nonnull_domain_checkpoint checkpoint; + int need_results; + unsigned int flags; +}; + +struct remote_domain_checkpoint_list_children_ret { /* insert@1 */ + remote_nonnull_domain_checkpoint checkpoints<REMOTE_DOMAIN_CHECKPOINT_LIST_MAX>; + int ret; +}; + +struct remote_domain_checkpoint_lookup_by_name_args { + remote_nonnull_domain dom; + remote_nonnull_string name; + unsigned int flags; +}; + +struct remote_domain_checkpoint_lookup_by_name_ret { + remote_nonnull_domain_checkpoint checkpoint; +}; + +struct remote_domain_has_current_checkpoint_args { + remote_nonnull_domain dom; + unsigned int flags; +}; + +struct remote_domain_has_current_checkpoint_ret { + int result; +}; + +struct remote_domain_checkpoint_get_parent_args { + remote_nonnull_domain_checkpoint checkpoint; + unsigned int flags; +}; + +struct remote_domain_checkpoint_get_parent_ret { + remote_nonnull_domain_checkpoint parent; +}; + +struct remote_domain_checkpoint_current_args { + remote_nonnull_domain dom; + unsigned int flags; +}; + +struct remote_domain_checkpoint_current_ret { + remote_nonnull_domain_checkpoint checkpoint; +}; + +struct remote_domain_checkpoint_is_current_args { + remote_nonnull_domain_checkpoint checkpoint; + unsigned int flags; +}; + +struct remote_domain_checkpoint_is_current_ret { + int current; +}; + +struct remote_domain_checkpoint_has_metadata_args { + remote_nonnull_domain_checkpoint checkpoint; + unsigned int flags; +}; + +struct remote_domain_checkpoint_has_metadata_ret { + int metadata; +}; + +struct remote_domain_checkpoint_delete_args { + remote_nonnull_domain_checkpoint checkpoint; + unsigned int flags; +}; + +struct remote_domain_backup_begin_args { + remote_nonnull_domain dom; + remote_string disk_xml; + remote_string checkpoint_xml; + unsigned int flags; +}; + +struct remote_domain_backup_begin_ret { + int result; +}; + +struct remote_domain_backup_get_xml_desc_args { + remote_nonnull_domain dom; + int id; + unsigned int flags; +}; + +struct remote_domain_backup_get_xml_desc_ret { + remote_nonnull_string xml; +}; + +struct remote_domain_backup_end_args { + remote_nonnull_domain dom; + int id; + unsigned int flags; +}; + +struct remote_domain_backup_end_ret { + int retcode; +}; /*----- Protocol. -----*/ @@ -6312,5 +6452,101 @@ enum remote_procedure { * @acl: connect:search_nwfilter_bindings * @aclfilter: nwfilter_binding:getattr */ - REMOTE_PROC_CONNECT_LIST_ALL_NWFILTER_BINDINGS = 401 + REMOTE_PROC_CONNECT_LIST_ALL_NWFILTER_BINDINGS = 401, + + /** + * @generate: both + * @acl: domain:checkpoint + */ + REMOTE_PROC_DOMAIN_CHECKPOINT_CREATE_XML = 402, + + /** + * @generate: both + * @acl: domain:read + * @acl: domain:read_secure:VIR_DOMAIN_CHECKPOINT_XML_SECURE + */ + REMOTE_PROC_DOMAIN_CHECKPOINT_GET_XML_DESC = 403, + + /** + * @generate: both + * @priority: high + * @acl: domain:read + */ + REMOTE_PROC_DOMAIN_LIST_CHECKPOINTS = 404, + + /** + * @generate: both + * @priority: high + * @acl: domain:read + */ + REMOTE_PROC_DOMAIN_CHECKPOINT_LIST_CHILDREN = 405, + + /** + * @generate: both + * @priority: high + * @acl: domain:read + */ + REMOTE_PROC_DOMAIN_CHECKPOINT_LOOKUP_BY_NAME = 406, + + /** + * @generate: both + * @priority: high + * @acl: domain:read + */ + REMOTE_PROC_DOMAIN_HAS_CURRENT_CHECKPOINT = 407, + + /** + * @generate: both + * @priority: high + * @acl: domain:read + */ + REMOTE_PROC_DOMAIN_CHECKPOINT_CURRENT = 408, + + /** + * @generate: both + * @priority: high + * @acl: domain:read + */ + REMOTE_PROC_DOMAIN_CHECKPOINT_GET_PARENT = 409, + + /** + * @generate: both + * @priority: high + * @acl: domain:read + */ + REMOTE_PROC_DOMAIN_CHECKPOINT_IS_CURRENT = 410, + + /** + * @generate: both + * @priority: high + * @acl: domain:read + */ + REMOTE_PROC_DOMAIN_CHECKPOINT_HAS_METADATA = 411, + + /** + * @generate: both + * @acl: domain:checkpoint + */ + REMOTE_PROC_DOMAIN_CHECKPOINT_DELETE = 412, + + /** + * @generate: both + * @acl: domain:checkpoint + * @acl: domain:block_read + */ + REMOTE_PROC_DOMAIN_BACKUP_BEGIN = 413, + + /** + * @generate: both + * @priority: high + * @acl: domain:read + * @acl: domain:read_secure:VIR_DOMAIN_XML_SECURE + */ + REMOTE_PROC_DOMAIN_BACKUP_GET_XML_DESC = 414, + + /** + * @generate: both + * @acl: domain:checkpoint + */ + REMOTE_PROC_DOMAIN_BACKUP_END = 415 }; diff --git a/src/remote_protocol-structs b/src/remote_protocol-structs index 6343e14638..86c7c34cf5 100644 --- a/src/remote_protocol-structs +++ b/src/remote_protocol-structs @@ -46,6 +46,10 @@ struct remote_nonnull_secret { int usageType; remote_nonnull_string usageID; }; +struct remote_nonnull_domain_checkpoint { + remote_nonnull_string name; + remote_nonnull_domain dom; +}; struct remote_nonnull_domain_snapshot { remote_nonnull_string name; remote_nonnull_domain dom; @@ -2966,6 +2970,117 @@ struct remote_connect_list_all_nwfilter_bindings_ret { } bindings; u_int ret; }; +struct remote_domain_checkpoint_create_xml_args { + remote_nonnull_domain dom; + remote_nonnull_string xml_desc; + u_int flags; +}; +struct remote_domain_checkpoint_create_xml_ret { + remote_nonnull_domain_checkpoint checkpoint; +}; +struct remote_domain_checkpoint_get_xml_desc_args { + remote_nonnull_domain_checkpoint checkpoint; + u_int flags; +}; +struct remote_domain_checkpoint_get_xml_desc_ret { + remote_nonnull_string xml; +}; +struct remote_domain_list_checkpoints_args { + remote_nonnull_domain dom; + int need_results; + u_int flags; +}; +struct remote_domain_list_checkpoints_ret { + struct { + u_int checkpoints_len; + remote_nonnull_domain_checkpoint * checkpoints_val; + } checkpoints; + int ret; +}; +struct remote_domain_checkpoint_list_children_args { + remote_nonnull_domain_checkpoint checkpoint; + int need_results; + u_int flags; +}; +struct remote_domain_checkpoint_list_children_ret { + struct { + u_int checkpoints_len; + remote_nonnull_domain_checkpoint * checkpoints_val; + } checkpoints; + int ret; +}; +struct remote_domain_checkpoint_lookup_by_name_args { + remote_nonnull_domain dom; + remote_nonnull_string name; + u_int flags; +}; +struct remote_domain_checkpoint_lookup_by_name_ret { + remote_nonnull_domain_checkpoint checkpoint; +}; +struct remote_domain_has_current_checkpoint_args { + remote_nonnull_domain dom; + u_int flags; +}; +struct remote_domain_has_current_checkpoint_ret { + int result; +}; +struct remote_domain_checkpoint_get_parent_args { + remote_nonnull_domain_checkpoint checkpoint; + u_int flags; +}; +struct remote_domain_checkpoint_get_parent_ret { + remote_nonnull_domain_checkpoint parent; +}; +struct remote_domain_checkpoint_current_args { + remote_nonnull_domain dom; + u_int flags; +}; +struct remote_domain_checkpoint_current_ret { + remote_nonnull_domain_checkpoint checkpoint; +}; +struct remote_domain_checkpoint_is_current_args { + remote_nonnull_domain_checkpoint checkpoint; + u_int flags; +}; +struct remote_domain_checkpoint_is_current_ret { + int current; +}; +struct remote_domain_checkpoint_has_metadata_args { + remote_nonnull_domain_checkpoint checkpoint; + u_int flags; +}; +struct remote_domain_checkpoint_has_metadata_ret { + int metadata; +}; +struct remote_domain_checkpoint_delete_args { + remote_nonnull_domain_checkpoint checkpoint; + u_int flags; +}; +struct remote_domain_backup_begin_args { + remote_nonnull_domain dom; + remote_string disk_xml; + remote_string checkpoint_xml; + u_int flags; +}; +struct remote_domain_backup_begin_ret { + int result; +}; +struct remote_domain_backup_get_xml_desc_args { + remote_nonnull_domain dom; + int id; + u_int flags; +}; +struct remote_domain_backup_get_xml_desc_ret { + remote_nonnull_string xml; +}; +struct remote_domain_backup_end_args { + remote_nonnull_domain dom; + int id; + u_int flags; +}; +struct remote_domain_backup_end_ret { + int retcode; +}; enum remote_procedure { REMOTE_PROC_CONNECT_OPEN = 1, REMOTE_PROC_CONNECT_CLOSE = 2, @@ -3368,4 +3483,18 @@ enum remote_procedure { REMOTE_PROC_NWFILTER_BINDING_CREATE_XML = 399, REMOTE_PROC_NWFILTER_BINDING_DELETE = 400, REMOTE_PROC_CONNECT_LIST_ALL_NWFILTER_BINDINGS = 401, + REMOTE_PROC_DOMAIN_CHECKPOINT_CREATE_XML = 402, + REMOTE_PROC_DOMAIN_CHECKPOINT_GET_XML_DESC = 403, + REMOTE_PROC_DOMAIN_LIST_CHECKPOINTS = 404, + REMOTE_PROC_DOMAIN_CHECKPOINT_LIST_CHILDREN = 405, + REMOTE_PROC_DOMAIN_CHECKPOINT_LOOKUP_BY_NAME = 406, + REMOTE_PROC_DOMAIN_HAS_CURRENT_CHECKPOINT = 407, + REMOTE_PROC_DOMAIN_CHECKPOINT_CURRENT = 408, + REMOTE_PROC_DOMAIN_CHECKPOINT_GET_PARENT = 409, + REMOTE_PROC_DOMAIN_CHECKPOINT_IS_CURRENT = 410, + REMOTE_PROC_DOMAIN_CHECKPOINT_HAS_METADATA = 411, + REMOTE_PROC_DOMAIN_CHECKPOINT_DELETE = 412, + REMOTE_PROC_DOMAIN_BACKUP_BEGIN = 413, + REMOTE_PROC_DOMAIN_BACKUP_GET_XML_DESC = 414, + REMOTE_PROC_DOMAIN_BACKUP_END = 415, }; diff --git a/src/rpc/gendispatch.pl b/src/rpc/gendispatch.pl index 0c4648c0fb..348039af3d 100755 --- a/src/rpc/gendispatch.pl +++ b/src/rpc/gendispatch.pl @@ -1,6 +1,6 @@ #!/usr/bin/env perl # -# Copyright (C) 2010-2015 Red Hat, Inc. +# Copyright (C) 2010-2018 Red Hat, Inc. # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -567,18 +567,20 @@ elsif ($mode eq "server") { push(@args_list, "$2"); push(@free_list, " virObjectUnref($2);"); - } elsif ($args_member =~ m/^remote_nonnull_domain_snapshot (\S+);$/) { + } elsif ($args_member =~ m/^remote_nonnull_domain_(checkpoint|snapshot) (\S+);$/) { + my $type_name = name_to_TypeName($1); + push(@vars_list, "virDomainPtr dom = NULL"); - push(@vars_list, "virDomainSnapshotPtr snapshot = NULL"); + push(@vars_list, "virDomain${type_name}Ptr ${1} = NULL"); push(@getters_list, - " if (!(dom = get_nonnull_domain($conn, args->${1}.dom)))\n" . + " if (!(dom = get_nonnull_domain($conn, args->${2}.dom)))\n" . " goto cleanup;\n" . "\n" . - " if (!(snapshot = get_nonnull_domain_snapshot(dom, args->${1})))\n" . + " if (!($1 = get_nonnull_domain_${1}(dom, args->$2)))\n" . " goto cleanup;\n"); - push(@args_list, "snapshot"); + push(@args_list, "$1"); push(@free_list, - " virObjectUnref(snapshot);\n" . + " virObjectUnref($1);\n" . " virObjectUnref(dom);"); } elsif ($args_member =~ m/^(?:(?:admin|remote)_string|remote_uuid) (\S+)<\S+>;/) { push(@args_list, $conn) if !@args_list; @@ -722,7 +724,7 @@ elsif ($mode eq "server") { if (!$modern_ret_as_list) { push(@ret_list, "ret->$3 = tmp.$3;"); } - } elsif ($ret_member =~ m/(?:admin|remote)_nonnull_(secret|nwfilter|nwfilter_binding|node_device|interface|network|storage_vol|storage_pool|domain_snapshot|domain|server|client) (\S+)<(\S+)>;/) { + } elsif ($ret_member =~ m/(?:admin|remote)_nonnull_(secret|nwfilter|nwfilter_binding|node_device|interface|network|storage_vol|storage_pool|domain_checkpoint|domain_snapshot|domain|server|client) (\S+)<(\S+)>;/) { $modern_ret_struct_name = $1; $single_ret_list_error_msg_type = $1; $single_ret_list_name = $2; @@ -780,7 +782,7 @@ elsif ($mode eq "server") { $single_ret_var = $1; $single_ret_by_ref = 0; $single_ret_check = " == NULL"; - } elsif ($ret_member =~ m/^remote_nonnull_(domain|network|storage_pool|storage_vol|interface|node_device|secret|nwfilter|nwfilter_binding|domain_snapshot) (\S+);/) { + } elsif ($ret_member =~ m/^remote_nonnull_(domain|network|storage_pool|storage_vol|interface|node_device|secret|nwfilter|nwfilter_binding|domain_checkpoint|domain_snapshot) (\S+);/) { my $type_name = name_to_TypeName($1); if ($call->{ProcName} eq "DomainCreateWithFlags") { @@ -1325,13 +1327,13 @@ elsif ($mode eq "client") { $priv_src = "dev->conn"; push(@args_list, "virNodeDevicePtr dev"); push(@setters_list, "args.name = dev->name;"); - } elsif ($args_member =~ m/^remote_nonnull_(domain|network|storage_pool|storage_vol|interface|secret|nwfilter|nwfilter_binding|domain_snapshot) (\S+);/) { + } elsif ($args_member =~ m/^remote_nonnull_(domain|network|storage_pool|storage_vol|interface|secret|nwfilter|nwfilter_binding|domain_checkpoint|domain_snapshot) (\S+);/) { my $name = $1; my $arg_name = $2; my $type_name = name_to_TypeName($name); if ($is_first_arg) { - if ($name eq "domain_snapshot") { + if ($name =~ m/^domain_.*/) { $priv_src = "$arg_name->domain->conn"; } else { $priv_src = "$arg_name->conn"; @@ -1518,7 +1520,7 @@ elsif ($mode eq "client") { } push(@ret_list, "memcpy(result->$3, ret.$3, sizeof(result->$3));"); - } elsif ($ret_member =~ m/(?:admin|remote)_nonnull_(secret|nwfilter|nwfilter_binding|node_device|interface|network|storage_vol|storage_pool|domain_snapshot|domain|server|client) (\S+)<(\S+)>;/) { + } elsif ($ret_member =~ m/(?:admin|remote)_nonnull_(secret|nwfilter|nwfilter_binding|node_device|interface|network|storage_vol|storage_pool|domain_checkpoint|domain_snapshot|domain|server|client) (\S+)<(\S+)>;/) { my $proc_name = name_to_TypeName($1); if ($structprefix eq "admin") { @@ -1571,7 +1573,7 @@ elsif ($mode eq "client") { push(@ret_list, "VIR_FREE(ret.$1);"); $single_ret_var = "char *rv = NULL"; $single_ret_type = "char *"; - } elsif ($ret_member =~ m/^remote_nonnull_(domain|network|storage_pool|storage_vol|node_device|interface|secret|nwfilter|nwfilter_binding|domain_snapshot) (\S+);/) { + } elsif ($ret_member =~ m/^remote_nonnull_(domain|network|storage_pool|storage_vol|node_device|interface|secret|nwfilter|nwfilter_binding|domain_checkpoint|domain_snapshot) (\S+);/) { my $name = $1; my $arg_name = $2; my $type_name = name_to_TypeName($name); @@ -1585,7 +1587,7 @@ elsif ($mode eq "client") { $single_ret_var = "int rv = -1"; $single_ret_type = "int"; } else { - if ($name eq "domain_snapshot") { + if ($name =~ m/^domain_.*/) { my $dom = "$priv_src"; $dom =~ s/->conn//; push(@ret_list, "rv = get_nonnull_$name($dom, ret.$arg_name);"); @@ -1928,7 +1930,7 @@ elsif ($mode eq "client") { print " }\n"; print "\n"; } elsif ($modern_ret_as_list) { - if ($modern_ret_struct_name =~ m/domain_snapshot|client/) { + if ($modern_ret_struct_name =~ m/domain_checkpoint|domain_snapshot|client/) { $priv_src =~ s/->conn//; } print " if (result) {\n"; -- 2.17.1

On Fri, Oct 12, 2018 at 00:10:02 -0500, Eric Blake wrote:
The following is the latest version of my API proposal for incremental backups.
I have even more work-in-progress patches on top of these: https://repo.or.cz/libvirt/ericb.git which I am slowly improving to be more in line with my thread on the overview of the API usage: https://www.redhat.com/archives/libvir-list/2018-October/msg00217.html
But I am fairly satisfied that the API as presented is sufficient for everything I have still been implementing in the qemu driver, and that even when qemu is slightly tweaked (such as dropping the x- prefix on various commands, or maybe adding a new command to make it easier to compute the estimated size of the union of several bitmaps), those changes will be limited to the src/qemu directory rather than affecting the API.
Since I will be demonstrating the use of this API at the KVM Forum, I would really like a decision on whether we can commit the API into libvirt now, even if we have to wait for the qemu implementation
No we can't. We did it once in the past and although I don't remember the exact details I remember it turned out to be a bad idea. Also pushing an API with no implementation doesn't really make sense since the API is unusable until it is implemented in some hypervisor driver.
of the API until qemu stabilizes its interfaces (also, having the libvirt API in place gives qemu an incentive to drop the x- prefix sooner rather than later).
The presence of public API in libvirt gives no clue to QEMU engineers that their API provides everything needed and x- prefix should be dropped. Only working patches implementing the libvirt APIs for QEMU can provide such feedback to QEMU developers. Jirka

On 10/12/18 11:28 AM, Jiri Denemark wrote:
Since I will be demonstrating the use of this API at the KVM Forum, I would really like a decision on whether we can commit the API into libvirt now, even if we have to wait for the qemu implementation
No we can't. We did it once in the past and although I don't remember the exact details I remember it turned out to be a bad idea. Also pushing an API with no implementation doesn't really make sense since the API is unusable until it is implemented in some hypervisor driver.
You wouldn't, by chance, be thinking of the fact that virDomainBlockCopy() landed in 1.2.8, but didn't get implemented until 1.2.9? (Yes, that one also has my name suspiciously tied to it. How come I always seem to be implementing APIs that downstream wants sooner than upstream is ready to commit to?)
of the API until qemu stabilizes its interfaces (also, having the libvirt API in place gives qemu an incentive to drop the x- prefix sooner rather than later).
The presence of public API in libvirt gives no clue to QEMU engineers that their API provides everything needed and x- prefix should be dropped. Only working patches implementing the libvirt APIs for QEMU can provide such feedback to QEMU developers.
My v3 is demonstration that QEMU is on the right track for providing everything I needed for a rudimentary implementation; the qemu implementation can be further fine-tuned as it waits for qemu to polish its interface. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
participants (3)
-
Eric Blake
-
Jiri Denemark
-
Peter Krempa