+ 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.
+
+
+ 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. Future API
+ additions will make it possible to create checkpoints in
+ conjunction with a backup
+ via virDomainBackupBegin() or with an external
+ snapshot via virDomainSnapshotCreateXML2; but for
+ now, libvirt exposes enough support to create disk checkpoints
+ independently from a backup operation
+ via virDomainCheckpointCreateXML().
+
+
+ Attributes of libvirt checkpoints are stored as child elements
+ of the domaincheckpoint element. At checkpoint
+ creation time, normally only
+ the name, description,
+ and disks elements are settable. The rest of the
+ fields are ignored on creation and will be filled in by libvirt
+ in for informational purposes
+ by virDomainCheckpointGetXMLDesc(). However, when
+ redefining a checkpoint, with
+ the VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE flag
+ of virDomainCheckpointCreateXML(), all of the XML
+ fields described here are relevant on input, even the fields
+ that are normally described as readonly for output.
+
+
+ A checkpoint is marked current if the hypervisor is actively
+ updating the checkpoint as guest operations modify the disk
+ after the point where the checkpoint was created. When tracking
+ multiple checkpoints, a hypervisor may choose to either have all
+ relevant checkpoints be current (a guest write updates the
+ associated tracking for each checkpoint), or to have a single
+ checkpoint be current (older checkpoints stop tracking changes
+ when a newer one is created, and describing all changes since an
+ older checkpoint then involves libvirt automatically combining
+ the changes from the chain of checkpoints from the current back
+ to the checkpoint in question; the QEMU hypervisor uses this
+ method). Checkpoints are maintained in a hierarchy to facilitate
+ hypervisors that use this latter method, where libvirt
+ automatically updates the parent-child relationship as well as
+ which checkpoint is current when creating or deleting
+ checkpoints. For now, the creation of checkpoints is not
+ possible when external snapshots exist, but this may be added in
+ the future.
+
+
+ The top-level domaincheckpoint element may contain
+ the following elements:
+
+
+
name
+
The optional name for this checkpoint. If the name is
+ omitted, libvirt will create a name based on the time of the
+ creation.
+
+
description
+
An optional human-readable description of the checkpoint.
+ If the description is omitted when initially creating the
+ checkpoint, then this field will be empty.
+
+
disks
+
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, otherwise, only the disks explicitly listed which
+ do not also use checkpoint=3D'no' will
+ participate. On output, this is the checkpoint state of each
+ of the domain's disks.
+
+
disk
+
This sub-element describes the checkpoint properties of
+ a specific disk with the following attributes:
+
+
name
+
A mandatory attribute which must match either
+ the <target dev=3D'name'/> or an
+ unambiguous <source file=3D'name'/>
+ of one of
+ the disk
+ devices specified for the domain at the time of
+ the checkpoint.
+
checkpoint
+
An optional attribute; possible values
+ are no when the disk does not participate
+ in this checkpoint; or bitmap if the disk
+ will track all changes since the creation of this
+ checkpoint via a bitmap.
+
bitmap
+
The attribute bitmap is only valid
+ if checkpoint=3D'bitmap'; it describes the
+ name of the tracking bitmap (defaulting to the
+ checkpoint name).
+
size
+
The attribute size is ignored on input;
+ on output, it is only present if
+ the VIR_DOMAIN_CHECKPOINT_XML_SIZE flag
+ was used to perform a dynamic query of the estimated
+ size in bytes of the changes made since the checkpoint
+ was created.
+
+
+
+
+
creationTime
+
A readonly representation of the time this checkpoint was
+ created. The time is specified in seconds since the Epoch,
+ UTC (i.e. Unix time).
+
+
parent
+
An optional readonly representation of the parent of this
+ checkpoint. If present, this element contains exactly one
+ child element, name.
+
+
current
+
A readonly integer, 1 if this checkpoint is current (that
+ is, actively tracking guest changes) or 0 if the checkpoint is
+ inactive because a child checkpoint is now tracking changes.
+
+
domain
+
A readonly representation of the
+ inactive domain configuration
+ at the time the checkpoint was created. This element may be
+ omitted for output brevity by supplying
+ the VIR_DOMAIN_CHECKPOINT_XML_NO_DOMAIN flag, but
+ the resulting XML is no longer viable for use with
+ the VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE flag
+ of virDomainCheckpointCreateXML(). The domain
+ will have security-sensitive information omitted unless the
+ flag VIR_DOMAIN_CHECKPOINT_XML_SECURE is provided
+ on a read-write connection.
+
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 1525889631.
+
+
+
diff --git a/docs/formatsnapshot.html.in b/docs/formatsnapshot.html.in
index 92cc566467..2bfb69cf49 100644
--- a/docs/formatsnapshot.html.in
+++ b/docs/formatsnapshot.html.in
@@ -91,7 +91,9 @@
sets that snapshot as current, and the prior current snapshot is
the parent of the new snapshot. Branches in the hierarchy can
be formed by reverting to a snapshot with a child, then creating
- another snapshot.
+ another snapshot. For now, the creation of external snapshots
+ when checkpoints exist is forbidden, although future work will
+ make it possible to integrate these two concepts.
The top-level domainsnapshot element may contain
diff --git a/docs/index.html.in b/docs/index.html.in
index 2bd647f8dd..7d0ab650e3 100644
--- a/docs/index.html.in
+++ b/docs/index.html.in
@@ -58,7 +58,8 @@
storage pool capabilities,
node devices,
secrets,
- snapshots
+ snapshots,
+ checkpoints
diff --git a/docs/schemas/domaincheckpoint.rng b/docs/schemas/domaincheckpo=
int.rng
new file mode 100644
index 0000000000..ceb5436aa3
--- /dev/null
+++ b/docs/schemas/domaincheckpoint.rng
@@ -0,0 +1,95 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0
+ 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ no
+
+
+
+
+ bitmap
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/libvirt.spec.in b/libvirt.spec.in
index d54f58f1d4..dece22688d 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1780,6 +1780,7 @@ exit 0
%{_datadir}/libvirt/schemas/cputypes.rng
%{_datadir}/libvirt/schemas/domain.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 ad6d6e952e..df89d9f8b3 100644
--- a/mingw-libvirt.spec.in
+++ b/mingw-libvirt.spec.in
@@ -232,6 +232,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-gue=
sts.sh
%{mingw32_datadir}/libvirt/schemas/cputypes.rng
%{mingw32_datadir}/libvirt/schemas/domain.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
@@ -321,6 +322,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-gue=
sts.sh
%{mingw64_datadir}/libvirt/schemas/cputypes.rng
%{mingw64_datadir}/libvirt/schemas/domain.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 e57d0da58a..66c6ad911e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -110,6 +110,8 @@ EXTRA_DIST =3D \
qemublocktestdata \
qemucapabilitiesdata \
qemucaps2xmloutdata \
+ qemudomaincheckpointxml2xmlin \
+ qemudomaincheckpointxml2xmlout \
qemudomainsnapshotxml2xmlin \
qemudomainsnapshotxml2xmlout \
qemuhotplugtestcpus \
diff --git a/tests/qemudomaincheckpointxml2xmlin/empty.xml b/tests/qemudoma=
incheckpointxml2xmlin/empty.xml
new file mode 100644
index 0000000000..dc36449142
--- /dev/null
+++ b/tests/qemudomaincheckpointxml2xmlin/empty.xml
@@ -0,0 +1 @@
+
diff --git a/tests/qemudomaincheckpointxml2xmlin/sample.xml b/tests/qemudom=
aincheckpointxml2xmlin/sample.xml
new file mode 100644
index 0000000000..70ed964e1e
--- /dev/null
+++ b/tests/qemudomaincheckpointxml2xmlin/sample.xml
@@ -0,0 +1,7 @@
+
+ Completion of updates after OS install
+
+
+
+
+
diff --git a/tests/qemudomaincheckpointxml2xmlin/size.xml b/tests/qemudomai=
ncheckpointxml2xmlin/size.xml
new file mode 100644
index 0000000000..99ce84c7a0
--- /dev/null
+++ b/tests/qemudomaincheckpointxml2xmlin/size.xml
@@ -0,0 +1,4 @@
+
+ c2
+ something fun
+
diff --git a/tests/qemudomaincheckpointxml2xmlout/empty.xml b/tests/qemudom=
aincheckpointxml2xmlout/empty.xml
new file mode 100644
index 0000000000..ff49bef17f
--- /dev/null
+++ b/tests/qemudomaincheckpointxml2xmlout/empty.xml
@@ -0,0 +1,8 @@
+
+ 1525889631
+ 1525889631
+ 0
+
+
+
+
diff --git a/tests/qemudomaincheckpointxml2xmlout/redefine.xml b/tests/qemu=
domaincheckpointxml2xmlout/redefine.xml
new file mode 100644
index 0000000000..44310c2e1d
--- /dev/null
+++ b/tests/qemudomaincheckpointxml2xmlout/redefine.xml
@@ -0,0 +1,64 @@
+
+ c1
+ 1553647812
+ 1
+
+
+
+
+
+
+
+ QEMUGuest1
+ c7a5fdbd-edaf-9455-926a-d65c16db1809
+ 219136
+ 219136
+ 1
+
+ hvm
+
+
+
+ destroy
+ restart
+ destroy
+
+ /usr/bin/qemu-system-i686
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/tests/qemudomaincheckpointxml2xmlout/sample.xml b/tests/qemudo=
maincheckpointxml2xmlout/sample.xml
new file mode 100644
index 0000000000..913c26d2b9
--- /dev/null
+++ b/tests/qemudomaincheckpointxml2xmlout/sample.xml
@@ -0,0 +1,13 @@
+
+ 1525889631
+ Completion of updates after OS install
+
+ 1525111885
+
+ 1525889631
+ 0
+
+
+
+
+
diff --git a/tests/qemudomaincheckpointxml2xmlout/size.xml b/tests/qemudoma=
incheckpointxml2xmlout/size.xml
new file mode 100644
index 0000000000..17d884983d
--- /dev/null
+++ b/tests/qemudomaincheckpointxml2xmlout/size.xml
@@ -0,0 +1,12 @@
+
+ c2
+ something fun
+
+ 1525111885
+
+ 1553648510
+ 1
+
+
+
+
diff --git a/tests/virschematest.c b/tests/virschematest.c
index b7c2f7cfaa..8f5101df21 100644
--- a/tests/virschematest.c
+++ b/tests/virschematest.c
@@ -222,6 +222,8 @@ mymain(void)
"genericxml2xmloutdata", "xlconfigdata", "libxlxml2domconf=
igdata",
"qemuhotplugtestdomains");
DO_TEST_DIR("domaincaps.rng", "domaincapsschemadata");
+ DO_TEST_DIR("domaincheckpoint.rng", "qemudomaincheckpointxml2xmlin",
+ "qemudomaincheckpointxml2xmlout");
DO_TEST_DIR("domainsnapshot.rng", "qemudomainsnapshotxml2xmlin",
"qemudomainsnapshotxml2xmlout");
DO_TEST_DIR("interface.rng", "interfaceschemadata");
--=20
2.20.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
From nobody Sat May 4 11:59:44 2024
Delivered-To: importer@patchew.org
Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28
as permitted sender) client-ip=209.132.183.28;
envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com;
Authentication-Results: mx.zohomail.com;
spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as
permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com;
dmarc=pass(p=none dis=none) header.from=redhat.com
ARC-Seal: i=1; a=rsa-sha256; t=1562471783; cv=none;
d=zoho.com; s=zohoarc;
b=lUzvQpT57UjAiKehwWTCeUxVMMeR72ShGHXrNhcFer5QQhpOf5mO+/3T2t0a2EQ0Cbm4e/e49RvUH1vHo0glCYIwB99AqJcXIJNUYU5pKMbTWlL1nvJOK0NW3NaECb8GPKABm9soJQoR5St0yBz0rb0uZI679HwJAyYounom5pY=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc;
t=1562471783;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results;
bh=xgoS44+UfzKjkk1w0D3AS+TiVODHOsOm+IKkbuYalj4=;
b=ZCnkN78bas6jYuXuwQUzl5++mvumc1GjEObFszafiuSh/n5Gu1gg2ty0wGbvo8R/OGgqw6F15nAlmGo6ljRTPLpUmi+Mdmf+zFJTjT7QiO8spVS/F0yemeau++khjXXZkIIiv3hu4+rys2Hs0NxSqSFLbvNWC5OjOZ/Tadz8bnY=
ARC-Authentication-Results: i=1; mx.zoho.com;
spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as
permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com;
dmarc=pass header.from= (p=none dis=none)
header.from=
Return-Path:
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by
mx.zohomail.com
with SMTPS id 15624717836318.863692297419334;
Sat, 6 Jul 2019 20:56:23 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com
[10.5.11.14])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id 557C4A7F8;
Sun, 7 Jul 2019 03:56:21 +0000 (UTC)
Received: from colo-mx.corp.redhat.com
(colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21])
by smtp.corp.redhat.com (Postfix) with ESMTPS id EC173772BC;
Sun, 7 Jul 2019 03:56:20 +0000 (UTC)
Received: from lists01.pubmisc.prod.ext.phx2.redhat.com
(lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33])
by colo-mx.corp.redhat.com (Postfix) with ESMTP id B84A8206D2;
Sun, 7 Jul 2019 03:56:19 +0000 (UTC)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
[10.5.11.11])
by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
id x673uHtm006184 for ;
Sat, 6 Jul 2019 23:56:17 -0400
Received: by smtp.corp.redhat.com (Postfix)
id 7333118A82; Sun, 7 Jul 2019 03:56:17 +0000 (UTC)
Received: from blue.redhat.com (ovpn-116-78.phx2.redhat.com [10.3.116.78])
by smtp.corp.redhat.com (Postfix) with ESMTP id D6A1E18A86;
Sun, 7 Jul 2019 03:56:16 +0000 (UTC)
From: Eric Blake
To: libvir-list@redhat.com
Date: Sat, 6 Jul 2019 22:56:02 -0500
Message-Id: <20190707035613.25754-3-eblake@redhat.com>
In-Reply-To: <20190707035613.25754-1-eblake@redhat.com>
References: <20190707035613.25754-1-eblake@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-loop: libvir-list@redhat.com
Cc: nsoffer@redhat.com, eshenitz@redhat.com, pkrempa@redhat.com
Subject: [libvirt] [PATCH v9 02/13] backup: Introduce virDomainCheckpoint
APIs
X-BeenThere: libvir-list@redhat.com
X-Mailman-Version: 2.1.12
Precedence: junk
List-Id: Development discussions about the libvirt library & tools
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Transfer-Encoding: quoted-printable
Sender: libvir-list-bounces@redhat.com
Errors-To: libvir-list-bounces@redhat.com
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted,
not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]);
Sun, 07 Jul 2019 03:56:21 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
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. We may have a future hypervisor that can completely manage
checkpoints without libvirt metadata, but the first two planned
hypervisors (qemu and test) both always use libvirt for tracking
metadata relations between checkpoints, so for now, I've deferred
the counterpart of virDomainSnapshotHasMetadata for a separate
API addition at a later date if there is ever a need for it.
The following map shows the API relations to snapshots, with new APIs
on the right:
Operate on a domain object to create/redefine a child:
virDomainSnapshotCreateXML virDomainCheckpointCreateXML
Operate on a child object for lifetime management:
virDomainSnapshotDelete virDomainCheckpointDelete
virDomainSnapshotFree virDomainCheckpointFree
virDomainSnapshotRef virDomainCheckpointRef
Operate on a child object to learn more about it:
virDomainSnapshotGetXMLDesc virDomainCheckpointGetXMLDesc
virDomainSnapshotGetConnect virDomainCheckpointGetConnect
virDomainSnapshotGetDomain virDomainCheckpointGetDomain
virDomainSnapshotGetName virDomainCheckpiontGetName
virDomainSnapshotGetParent virDomainCheckpiontGetParent
virDomainSnapshotHasMetadata (deferred for later)
virDomainSnapshotIsCurrent (no counterpart, present in XML instead)
Operate on a domain object to list all children:
virDomainSnapshotNum (no counterparts, these are the old
virDomainSnapshotListNames racy interfaces)
virDomainSnapshotListAllSnapshots virDomainListAllCheckpoints
Operate on a child object to list descendents:
virDomainSnapshotNumChildren (no counterparts, these are the old
virDomainSnapshotListChildrenNames racy interfaces)
virDomainSnapshotListAllChildren virDomainCheckpointListAllChildren
Operate on a domain to locate a particular child:
virDomainSnapshotLookupByName virDomainCheckpointLookupByName
virDomainSnapshotCurrent (obtained by flag to ListAllCheckpoints)
virDomainHasCurrentSnapshot (no counterpart, old racy interface)
Operate on a snapshot to roll back to earlier state:
virDomainSnapshotRevert (no counterpart, instead checkpoints
are used in incremental backups via
XML to virDomainBackupBegin)
Signed-off-by: Eric Blake
---
include/libvirt/libvirt-domain-checkpoint.h | 143 +++++
include/libvirt/libvirt-domain.h | 6 +
include/libvirt/libvirt.h | 5 +-
src/conf/virdomainmomentobjlist.h | 5 +-
src/driver-hypervisor.h | 38 ++
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 | 586 ++++++++++++++++++++
src/libvirt-domain.c | 19 +-
src/libvirt_public.syms | 16 +
15 files changed, 821 insertions(+), 9 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..b2d5c5758b
--- /dev/null
+++ b/include/libvirt/libvirt-domain-checkpoint.h
@@ -0,0 +1,143 @@
+/*
+ * libvirt-domain-checkpoint.h
+ * Summary: APIs for management of domain checkpoints
+ * Description: Provides APIs for the management of domain checkpoints
+ *
+ * Copyright (C) 2006-2019 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
+ * .
+ */
+
+#ifndef LIBVIRT_DOMAIN_CHECKPOINT_H
+# define 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 checkpoin=
t);
+virConnectPtr virDomainCheckpointGetConnect(virDomainCheckpointPtr checkpo=
int);
+
+typedef enum {
+ VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE =3D (1 << 0), /* Restore or a=
lter
+ metadata */
+ VIR_DOMAIN_CHECKPOINT_CREATE_NO_METADATA =3D (1 << 1), /* Make checkpo=
int without
+ remembering it=
*/
+ VIR_DOMAIN_CHECKPOINT_CREATE_QUIESCE =3D (1 << 2), /* use guest ag=
ent to
+ quiesce all mo=
unted
+ file systems w=
ithin
+ the domain */
+} 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 =3D (1 << 0), /* Include sensitive=
data */
+ VIR_DOMAIN_CHECKPOINT_XML_NO_DOMAIN =3D (1 << 1), /* Suppress
+ subelement */
+ VIR_DOMAIN_CHECKPOINT_XML_SIZE =3D (1 << 2), /* Include dynamic
+ per- size */
+} virDomainCheckpointXMLFlags;
+
+/* Dump the XML of a checkpoint */
+char *virDomainCheckpointGetXMLDesc(virDomainCheckpointPtr checkpoint,
+ unsigned int flags);
+
+/**
+ * virDomainCheckpointListFlags:
+ *
+ * Flags valid for virDomainListAllCheckpoints() and
+ * virDomainCheckpointListAllChildren(). 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 =3D (1 << 0), /* Filter by chec=
kpoints
+ with no parents,=
when
+ listing a domain=
*/
+ VIR_DOMAIN_CHECKPOINT_LIST_DESCENDANTS =3D (1 << 0), /* List all desce=
ndants,
+ not just childre=
n, when
+ listing a checkp=
oint */
+ VIR_DOMAIN_CHECKPOINT_LIST_TOPOLOGICAL =3D (1 << 1), /* Ensure parents=
occur
+ before children =
in
+ the resulting li=
st */
+
+ VIR_DOMAIN_CHECKPOINT_LIST_LEAVES =3D (1 << 2), /* Filter by chec=
kpoints
+ with no children=
*/
+ VIR_DOMAIN_CHECKPOINT_LIST_NO_LEAVES =3D (1 << 3), /* Filter by chec=
kpoints
+ that have childr=
en */
+ VIR_DOMAIN_CHECKPOINT_LIST_CURRENT =3D (1 << 4), /* Filter by chec=
kpoints
+ that are current=
*/
+ VIR_DOMAIN_CHECKPOINT_LIST_NO_CURRENT =3D (1 << 5), /* Filter by chec=
kpoints
+ that are inactiv=
e */
+} virDomainCheckpointListFlags;
+
+/* Get all checkpoint objects for this domain */
+int virDomainListAllCheckpoints(virDomainPtr domain,
+ virDomainCheckpointPtr **checkpoints,
+ unsigned int flags);
+
+/* Get all checkpoint object children for this checkpoint */
+int virDomainCheckpointListAllChildren(virDomainCheckpointPtr checkpoint,
+ virDomainCheckpointPtr **children,
+ unsigned int flags);
+
+/* Get a handle to a named checkpoint */
+virDomainCheckpointPtr virDomainCheckpointLookupByName(virDomainPtr domain,
+ const char *name,
+ unsigned int flags);
+
+/* Get a handle to the parent checkpoint, if one exists */
+virDomainCheckpointPtr virDomainCheckpointGetParent(virDomainCheckpointPtr=
checkpoint,
+ unsigned int flags);
+
+/* Delete a checkpoint */
+typedef enum {
+ VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN =3D (1 << 0), /* Also delet=
e children */
+ VIR_DOMAIN_CHECKPOINT_DELETE_METADATA_ONLY =3D (1 << 1), /* Delete jus=
t metadata */
+ VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN_ONLY =3D (1 << 2), /* Delete jus=
t children */
+} virDomainCheckpointDeleteFlags;
+
+int virDomainCheckpointDelete(virDomainCheckpointPtr checkpoint,
+ unsigned int flags);
+
+int virDomainCheckpointRef(virDomainCheckpointPtr checkpoint);
+int virDomainCheckpointFree(virDomainCheckpointPtr checkpoint);
+
+#endif /* LIBVIRT_DOMAIN_CHECKPOINT_H */
diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-dom=
ain.h
index 2dbd74d4f3..f160ee88b5 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -1800,6 +1800,9 @@ typedef enum {
VIR_DOMAIN_UNDEFINE_NVRAM =3D (1 << 2), /* Also remove any
nvram file */
VIR_DOMAIN_UNDEFINE_KEEP_NVRAM =3D (1 << 3), /* Keep nvram fil=
e */
+ VIR_DOMAIN_UNDEFINE_CHECKPOINTS_METADATA =3D (1 << 4), /* If last use =
of domain,
+ then also remo=
ve any
+ checkpoint met=
adata */
/* Future undefine control flags should come here. */
} virDomainUndefineFlagsValues;
@@ -1838,6 +1841,9 @@ typedef enum {
VIR_CONNECT_LIST_DOMAINS_HAS_SNAPSHOT =3D 1 << 12,
VIR_CONNECT_LIST_DOMAINS_NO_SNAPSHOT =3D 1 << 13,
+
+ VIR_CONNECT_LIST_DOMAINS_HAS_CHECKPOINT =3D 1 << 14,
+ VIR_CONNECT_LIST_DOMAINS_NO_CHECKPOINT =3D 1 << 15,
} virConnectListAllDomainsFlags;
int virConnectListAllDomains (virConnectPtr conn,
diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h
index 13de151cb6..f93e3bfa85 100644
--- a/include/libvirt/libvirt.h
+++ b/include/libvirt/libvirt.h
@@ -34,10 +34,7 @@ extern "C" {
# include
# include
# include
-/* FIXME: Temporary hack until later patch creates new
- * libvirt-domain-checkpoint.h file */
-typedef struct _virDomainCheckpoint virDomainCheckpoint;
-typedef virDomainCheckpoint *virDomainCheckpointPtr;
+# include
# include
# include
# include
diff --git a/src/conf/virdomainmomentobjlist.h b/src/conf/virdomainmomentob=
jlist.h
index 7628df5e29..3402f6aa3a 100644
--- a/src/conf/virdomainmomentobjlist.h
+++ b/src/conf/virdomainmomentobjlist.h
@@ -70,8 +70,9 @@ virDomainMomentObjPtr virDomainMomentAssignDef(virDomainM=
omentObjListPtr moments
virDomainMomentDefPtr def);
/* Various enum bits that map to public API filters. Note that the
- * values of the internal bits are not necessarily the same as the
- * public ones. */
+ * values of the internal bits are not the same as the public ones for
+ * snapshot, however, this list should be kept in sync with the public
+ * ones for checkpoint. */
typedef enum {
VIR_DOMAIN_MOMENT_LIST_ROOTS =3D (1 << 0),
VIR_DOMAIN_MOMENT_LIST_DESCENDANTS =3D (1 << 0),
diff --git a/src/driver-hypervisor.h b/src/driver-hypervisor.h
index b15aaa36bc..c1632ae4c6 100644
--- a/src/driver-hypervisor.h
+++ b/src/driver-hypervisor.h
@@ -1327,6 +1327,37 @@ 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
+(*virDrvDomainListAllCheckpoints)(virDomainPtr domain,
+ virDomainCheckpointPtr **checkpoints,
+ unsigned int flags);
+
+typedef int
+(*virDrvDomainCheckpointListAllChildren)(virDomainCheckpointPtr checkpoint,
+ virDomainCheckpointPtr **children,
+ unsigned int flags);
+
+typedef virDomainCheckpointPtr
+(*virDrvDomainCheckpointLookupByName)(virDomainPtr domain,
+ const char *name,
+ unsigned int flags);
+
+typedef virDomainCheckpointPtr
+(*virDrvDomainCheckpointGetParent)(virDomainCheckpointPtr checkpoint,
+ unsigned int flags);
+
+typedef int
+(*virDrvDomainCheckpointDelete)(virDomainCheckpointPtr checkpoint,
+ unsigned int flags);
typedef struct _virHypervisorDriver virHypervisorDriver;
typedef virHypervisorDriver *virHypervisorDriverPtr;
@@ -1579,4 +1610,11 @@ struct _virHypervisorDriver {
virDrvConnectBaselineHypervisorCPU connectBaselineHypervisorCPU;
virDrvNodeGetSEVInfo nodeGetSEVInfo;
virDrvDomainGetLaunchSecurityInfo domainGetLaunchSecurityInfo;
+ virDrvDomainCheckpointCreateXML domainCheckpointCreateXML;
+ virDrvDomainCheckpointGetXMLDesc domainCheckpointGetXMLDesc;
+ virDrvDomainListAllCheckpoints domainListAllCheckpoints;
+ virDrvDomainCheckpointListAllChildren domainCheckpointListAllChildren;
+ virDrvDomainCheckpointLookupByName domainCheckpointLookupByName;
+ virDrvDomainCheckpointGetParent domainCheckpointGetParent;
+ virDrvDomainCheckpointDelete domainCheckpointDelete;
};
diff --git a/docs/Makefile.am b/docs/Makefile.am
index 977be471ad..aaf26ae55a 100644
--- a/docs/Makefile.am
+++ b/docs/Makefile.am
@@ -22,6 +22,7 @@ DEVHELP_DIR=3D$(datadir)/gtk-doc/html/libvirt
modules =3D \
libvirt-common \
libvirt-domain \
+ libvirt-domain-checkpoint \
libvirt-domain-snapshot \
libvirt-event \
libvirt-host \
@@ -312,6 +313,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 \
@@ -328,6 +330,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 9e04871220..dbdc1c95af 100755
--- a/docs/apibuild.py
+++ b/docs/apibuild.py
@@ -26,6 +26,7 @@ debugsym =3D None
included_files =3D {
"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 definiti=
ons",
"libvirt-domain-snapshot.h": "header with general libvirt API definition=
s",
"libvirt-event.h": "header with general libvirt API definitions",
"libvirt-host.h": "header with general libvirt API definitions",
@@ -39,6 +40,7 @@ included_files =3D {
"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 lib=
virt 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 55cbab5f15..2d44e3ab2e 100644
--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -99,6 +99,7 @@
Reference manual for the C public API, split in
common,
domain,
+ domain c=
heckpoint,
domain sna=
pshot,
error,
event,
diff --git a/libvirt.spec.in b/libvirt.spec.in
index dece22688d..ffadaf2d49 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1840,6 +1840,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 df89d9f8b3..a20c4b7d74 100644
--- a/mingw-libvirt.spec.in
+++ b/mingw-libvirt.spec.in
@@ -264,6 +264,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-gue=
sts.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
@@ -354,6 +355,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-gue=
sts.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 8017712ff4..21eea80329 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 0b562dc250..4a8cae11dc 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -167,6 +167,7 @@ DRIVER_SOURCES +=3D \
$(DATATYPES_SOURCES) \
libvirt.c libvirt_internal.h \
libvirt-domain.c \
+ libvirt-domain-checkpoint.c \
libvirt-domain-snapshot.c \
libvirt-host.c \
libvirt-interface.c \
@@ -719,6 +720,7 @@ libvirt_setuid_rpc_client_la_SOURCES =3D \
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-checkpoin=
t.c
new file mode 100644
index 0000000000..ab82d8422b
--- /dev/null
+++ b/src/libvirt-domain-checkpoint.c
@@ -0,0 +1,586 @@
+/*
+ * libvirt-domain-checkpoint.c: entry points for virDomainCheckpointPtr AP=
Is
+ *
+ * Copyright (C) 2006-2019 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
+ * .
+ */
+
+#include
+
+#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 deallocat=
ed
+ * as its lifetime will be the same as the checkpoint object.
+ */
+const char *
+virDomainCheckpointGetName(virDomainCheckpointPtr checkpoint)
+{
+ VIR_DEBUG("checkpoint=3D%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=3D%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=3D%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, with a top-level
+ * element, on a running @domain. Note that @xmlDesc
+ * must validate against the XML schema.
+ *
+ * See Checkpoint XM=
L
+ * for more details on @xmlDesc. In particular, some hypervisors may requi=
re
+ * 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
+ * captured from virDomainCheckpointGetXMLDesc() before removing that
+ * metadata, rather than creating a new checkpoint. Note that while
+ * original creation can omit a number of elements from @xmlDesc (and
+ * libvirt will supply sane defaults based on the domain state at that
+ * point in time), a redefinition must supply more elements (as the
+ * domain may have changed in the meantime, so that libvirt no longer
+ * has a way to resupply correct defaults). Not all hypervisors support
+ * this flag.
+ *
+ * If @flags includes VIR_DOMAIN_CHECKPOINT_CREATE_NO_METADATA, then
+ * the domain's disk images are modified according to @xmlDesc, but
+ * libvirt does not track any metadata (similar to immediately calling
+ * virDomainCheckpointDelete() with
+ * VIR_DOMAIN_CHECKPOINT_DELETE_METADATA_ONLY). This flag is
+ * incompatible with VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE, and is
+ * not supported by all hypervisors.
+ *
+ * If @flags includes VIR_DOMAIN_CHECKPOINT_CREATE_QUIESCE, then the
+ * libvirt will attempt to use guest agent to freeze and thaw all file
+ * systems in use within domain OS. However, if the guest agent is not
+ * present, an error is thrown. 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=3D%s, flags=3D0x%x", xmlDesc, flags);
+
+ virResetLastError();
+
+ virCheckDomainReturn(domain, NULL);
+ conn =3D domain->conn;
+
+ virCheckNonNullArgGoto(xmlDesc, error);
+ virCheckReadOnlyGoto(conn->flags, error);
+
+ VIR_EXCLUSIVE_FLAGS_GOTO(VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE,
+ VIR_DOMAIN_CHECKPOINT_CREATE_NO_METADATA,
+ error);
+ VIR_EXCLUSIVE_FLAGS_GOTO(VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE,
+ VIR_DOMAIN_CHECKPOINT_CREATE_QUIESCE,
+ error);
+
+ if (conn->driver->domainCheckpointCreateXML) {
+ virDomainCheckpointPtr ret;
+ ret =3D conn->driver->domainCheckpointCreateXML(domain, xmlDesc, f=
lags);
+ 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 checkpoint 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 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=3D%p, flags=3D0x%x", checkpoint, flags);
+
+ virResetLastError();
+
+ virCheckDomainCheckpointReturn(checkpoint, NULL);
+ conn =3D 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 =3D conn->driver->domainCheckpointGetXMLDesc(checkpoint, flags=
);
+ if (!ret)
+ goto error;
+ return ret;
+ }
+
+ virReportUnsupportedError();
+ error:
+ virDispatchError(conn);
+ return NULL;
+}
+
+
+/**
+ * virDomainListAllCheckpoints:
+ * @domain: a domain object
+ * @checkpoints: pointer to variable to store the array containing checkpo=
int
+ * object, 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.
+ *
+ * If @flags contains VIR_DOMAIN_CHECKPOINT_LIST_TOPOLOGICAL,
+ * @checkpoints is non-NULL, and no other connection is modifying
+ * checkpoints, then it is guaranteed that for any checkpoint in the
+ * resulting list, no checkpoints later in the list can be reached by
+ * a sequence of virDomainCheckpointGetParent() starting from that
+ * earlier checkpoint; otherwise, the order of checkpoints in the
+ * resulting list is unspecified.
+ *
+ * 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 listed below. Within a group, bits
+ * are mutually exclusive, where all possible checkpoints are
+ * described by exactly one bit from the group. Some hypervisors might
+ * reject particular flags where it cannot make a distinction for
+ * filtering. If the set of filter flags selected forms an impossible
+ * combination, the 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 th=
at
+ * have no further children (a leaf checkpoint).
+ *
+ * The next group of @flags is VIR_DOMAIN_CHECKPOINT_LIST_CURRENT and
+ * VIR_DOMAIN_CHECKPOINT_LIST_NO_CURRENT, to filter based on checkpoints
+ * that are currently being modified by guest activity vs. those that
+ * are no longer tracking changes but instead rely on automatic merging
+ * with child checkpoints when computing changes since the checkpoint.
+ *
+ * Returns the number of domain checkpoints found or -1 and sets @checkpoi=
nts
+ * to NULL in case of error. On success, the array stored into @checkpoin=
ts
+ * 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
+virDomainListAllCheckpoints(virDomainPtr domain,
+ virDomainCheckpointPtr **checkpoints,
+ unsigned int flags)
+{
+ virConnectPtr conn;
+
+ VIR_DOMAIN_DEBUG(domain, "checkpoints=3D%p, flags=3D0x%x", checkpoints=
, flags);
+
+ virResetLastError();
+
+ if (checkpoints)
+ *checkpoints =3D NULL;
+
+ virCheckDomainReturn(domain, -1);
+ conn =3D domain->conn;
+
+ if (conn->driver->domainListAllCheckpoints) {
+ int ret =3D conn->driver->domainListAllCheckpoints(domain, checkpo=
ints,
+ flags);
+ if (ret < 0)
+ goto error;
+ return ret;
+ }
+
+ virReportUnsupportedError();
+ error:
+ virDispatchError(conn);
+ return -1;
+}
+
+
+/**
+ * virDomainCheckpointListAllChildren:
+ * @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.
+ *
+ * If @flags contains VIR_DOMAIN_CHECKPOINT_LIST_TOPOLOGICAL,
+ * @checkpoints is non-NULL, and no other connection is modifying
+ * checkpoints, then it is guaranteed that for any checkpoint in the
+ * resulting list, no checkpoints later in the list can be reached by
+ * a sequence of virDomainCheckpointGetParent() starting from that
+ * earlier checkpoint; otherwise, the order of checkpoints in the
+ * resulting list is unspecified.
+ *
+ * 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. Additional
+ * are provided via the remaining @flags values as documented in
+ * virDomainListAllCheckpoints(), with the exception that
+ * VIR_DOMAIN_CHECKPOINT_LIST_ROOTS is not supported (in fact,
+ * VIR_DOMAIN_CHECKPOINT_LIST_DESCENDANTS has the same bit value but
+ * opposite semantics of widening rather than narrowing the listing).
+ *
+ * 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 inclu=
ded
+ * in the return count, to make iteration easier. The caller is responsib=
le
+ * for calling virDomainCheckpointFree() on each array element, then calli=
ng
+ * free() on @children.
+ */
+int
+virDomainCheckpointListAllChildren(virDomainCheckpointPtr checkpoint,
+ virDomainCheckpointPtr **children,
+ unsigned int flags)
+{
+ virConnectPtr conn;
+
+ VIR_DEBUG("checkpoint=3D%p, children=3D%p, flags=3D0x%x",
+ checkpoint, children, flags);
+
+ virResetLastError();
+
+ if (children)
+ *children =3D NULL;
+
+ virCheckDomainCheckpointReturn(checkpoint, -1);
+ conn =3D checkpoint->domain->conn;
+
+ if (conn->driver->domainCheckpointListAllChildren) {
+ int ret =3D conn->driver->domainCheckpointListAllChildren(checkpoi=
nt,
+ 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=3D%s, flags=3D0x%x", name, flags);
+
+ virResetLastError();
+
+ virCheckDomainReturn(domain, NULL);
+ conn =3D domain->conn;
+
+ virCheckNonNullArgGoto(name, error);
+
+ if (conn->driver->domainCheckpointLookupByName) {
+ virDomainCheckpointPtr checkpoint;
+ checkpoint =3D conn->driver->domainCheckpointLookupByName(domain, =
name,
+ flags);
+ if (!checkpoint)
+ goto error;
+ return checkpoint;
+ }
+
+ 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_CHEC=
KPOINT
+ * error is raised.
+ */
+virDomainCheckpointPtr
+virDomainCheckpointGetParent(virDomainCheckpointPtr checkpoint,
+ unsigned int flags)
+{
+ virConnectPtr conn;
+
+ VIR_DEBUG("checkpoint=3D%p, flags=3D0x%x", checkpoint, flags);
+
+ virResetLastError();
+
+ virCheckDomainCheckpointReturn(checkpoint, NULL);
+ conn =3D checkpoint->domain->conn;
+
+ if (conn->driver->domainCheckpointGetParent) {
+ virDomainCheckpointPtr parent;
+ parent =3D conn->driver->domainCheckpointGetParent(checkpoint, fla=
gs);
+ if (!parent)
+ goto error;
+ return parent;
+ }
+
+ virReportUnsupportedError();
+ error:
+ virDispatchError(conn);
+ return NULL;
+}
+
+
+/**
+ * virDomainCheckpointDelete:
+ * @checkpoint: the checkpoint to remove
+ * @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 a current checkpoint, the parent
+ * checkpoint becomes a current checkpoint again.
+ *
+ * If @flags includes VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN, then any
+ * descendant checkpoints are also deleted. If @flags includes
+ * VIR_DOMAIN_CHECKPOINT_DELETE_CHILDREN_ONLY, then any descendant
+ * checkepoints are deleted, but this checkpoint remains. These two
+ * flags are mutually exclusive.
+ *
+ * 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=3D%p, flags=3D0x%x", checkpoint, flags);
+
+ virResetLastError();
+
+ virCheckDomainCheckpointReturn(checkpoint, -1);
+ conn =3D 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 =3D 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=3D%p, refs=3D%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 modifi=
ed.
+ * 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=3D%p", checkpoint);
+
+ virResetLastError();
+
+ virCheckDomainCheckpointReturn(checkpoint, -1);
+
+ virObjectUnref(checkpoint);
+ return 0;
+}
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index 3d12e7c125..2fe9bb8e91 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -6218,8 +6218,9 @@ virDomainDefineXMLFlags(virConnectPtr conn, const cha=
r *xml, unsigned int flags)
*
* If the domain has a managed save image (see
* virDomainHasManagedSaveImage()), or if it is inactive and has any
- * snapshot metadata (see virDomainSnapshotNum()), then the undefine will
- * fail. See virDomainUndefineFlags() for more control.
+ * snapshot metadata (see virDomainSnapshotNum()) or checkpoint
+ * metadata (see virDomainListAllCheckpoints()), then the undefine
+ * will fail. See virDomainUndefineFlags() for more control.
*
* Returns 0 in case of success, -1 in case of error
*/
@@ -6276,6 +6277,16 @@ virDomainUndefine(virDomainPtr domain)
* support snapshots, but where snapshots do not use libvirt metadata,
* this flag has no effect.
*
+ * If the domain is inactive and has any checkpoint metadata (see
+ * virDomainListAllCheckpoints()), then including
+ * VIR_DOMAIN_UNDEFINE_CHECKPOINTS_METADATA in @flags will also remove
+ * that metadata. Omitting the flag will cause the undefine of an
+ * inactive domain with checkpoints to fail. Active domains will
+ * retain checkpoint metadata until the (now-transient) domain halts,
+ * regardless of whether this flag is present. On hypervisors that
+ * support checkpoints, but where checkpoints do not use libvirt
+ * metadata, this flag has no effect.
+ *
* If the domain has any nvram specified, the undefine process will fail
* unless VIR_DOMAIN_UNDEFINE_KEEP_NVRAM is specified, or if
* VIR_DOMAIN_UNDEFINE_NVRAM is specified to remove the nvram file.
@@ -6436,7 +6447,9 @@ virConnectListDefinedDomains(virConnectPtr conn, char=
**const names,
* VIR_CONNECT_LIST_DOMAINS_NO_AUTOSTART, for filtering based on autostart;
* VIR_CONNECT_LIST_DOMAINS_HAS_SNAPSHOT and
* VIR_CONNECT_LIST_DOMAINS_NO_SNAPSHOT, for filtering based on whether
- * a domain has snapshots.
+ * a domain has snapshots; VIR_CONNECT_LIST_DOMAINS_HAS_CHECKPOINT and
+ * VIR_CONNECT_LIST_DOMAINS_NO_CHECKPOINT, for filtering based on whether
+ * a domain has checkpoints.
*
* Example of usage:
*
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 18500ec8b2..54256b6317 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -836,4 +836,20 @@ LIBVIRT_5.5.0 {
virNetworkPortSetParameters;
} LIBVIRT_5.2.0;
+LIBVIRT_5.6.0 {
+ global:
+ virDomainCheckpointCreateXML;
+ virDomainCheckpointDelete;
+ virDomainCheckpointFree;
+ virDomainCheckpointGetConnect;
+ virDomainCheckpointGetDomain;
+ virDomainCheckpointGetName;
+ virDomainCheckpointGetParent;
+ virDomainCheckpointGetXMLDesc;
+ virDomainCheckpointListAllChildren;
+ virDomainCheckpointLookupByName;
+ virDomainCheckpointRef;
+ virDomainListAllCheckpoints;
+} LIBVIRT_5.5.0;
+
# .... define new API here using predicted next version number ....
--=20
2.20.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
From nobody Sat May 4 11:59:44 2024
Delivered-To: importer@patchew.org
Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28
as permitted sender) client-ip=209.132.183.28;
envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com;
Authentication-Results: mx.zohomail.com;
spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as
permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com;
dmarc=pass(p=none dis=none) header.from=redhat.com
ARC-Seal: i=1; a=rsa-sha256; t=1562471812; cv=none;
d=zoho.com; s=zohoarc;
b=GQ3gb2vomiaKdSeiC97RImMhH66CuYJ98v7KbdPV+gBnG/kSm1DSNPyvSiLavLp37/ueQOgQlSSyX80vcrxW7XzjCVs4x3vr/o32fFO8oD/F9ERtsZDxLH35ZK3jnTFrCViw1mSfllBQYy0oEGMhUe5kFE6UfPHUIhT5z0pMU2U=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc;
t=1562471812;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results;
bh=XJd/LAJ1uGDbAKRufyJncAyPZsDSom1Cak2GsR8q6A4=;
b=TfnkGhcws12oiaRBy/Q/4WYpE1+J/h9XEKlYlqVm4Tx/uqU4OLatrHtfb/aQe0M/As07MR+eM7cE4P3xsdUhgQ5O68c1kbzwFeVNt2NW4gK1a9N8R7tm9Ula5eIN8lHORbDy7/TXNik0VLUksn7sDi+sGxLLw3OI7AZRPRchfnY=
ARC-Authentication-Results: i=1; mx.zoho.com;
spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as
permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com;
dmarc=pass header.from= (p=none dis=none)
header.from=
Return-Path:
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by
mx.zohomail.com
with SMTPS id 1562471812730701.0563421913054;
Sat, 6 Jul 2019 20:56:52 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com
[10.5.11.12])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id DF6F6C055676;
Sun, 7 Jul 2019 03:56:42 +0000 (UTC)
Received: from colo-mx.corp.redhat.com
(colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20])
by smtp.corp.redhat.com (Postfix) with ESMTPS id BCA5651F0A;
Sun, 7 Jul 2019 03:56:42 +0000 (UTC)
Received: from lists01.pubmisc.prod.ext.phx2.redhat.com
(lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33])
by colo-mx.corp.redhat.com (Postfix) with ESMTP id 8252A18184A5;
Sun, 7 Jul 2019 03:56:42 +0000 (UTC)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com
[10.5.11.11])
by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
id x673uOrA006207 for ;
Sat, 6 Jul 2019 23:56:24 -0400
Received: by smtp.corp.redhat.com (Postfix)
id 621912B599; Sun, 7 Jul 2019 03:56:24 +0000 (UTC)
Received: from blue.redhat.com (ovpn-116-78.phx2.redhat.com [10.3.116.78])
by smtp.corp.redhat.com (Postfix) with ESMTP id B92BF413A;
Sun, 7 Jul 2019 03:56:23 +0000 (UTC)
From: Eric Blake
To: libvir-list@redhat.com
Date: Sat, 6 Jul 2019 22:56:03 -0500
Message-Id: <20190707035613.25754-4-eblake@redhat.com>
In-Reply-To: <20190707035613.25754-1-eblake@redhat.com>
References: <20190707035613.25754-1-eblake@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-loop: libvir-list@redhat.com
Cc: nsoffer@redhat.com, eshenitz@redhat.com, pkrempa@redhat.com
Subject: [libvirt] [PATCH v9 03/13] backup: Document nuances between
different state capture APIs
X-BeenThere: libvir-list@redhat.com
X-Mailman-Version: 2.1.12
Precedence: junk
List-Id: Development discussions about the libvirt library & tools
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Sender: libvir-list-bounces@redhat.com
Errors-To: libvir-list-bounces@redhat.com
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted,
not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]);
Sun, 07 Jul 2019 03:56:43 +0000 (UTC)
Now that various new API have been added or are coming soon, it is
worth 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
Reviewed-by: John Ferlan
Reviewed-by: Daniel P. Berrang=C3=A9
---
docs/docs.html.in | 5 +
docs/domainstatecapture.html.in | 314 ++++++++++++++++++++++++++++++++
docs/formatcheckpoint.html.in | 4 +-
docs/formatsnapshot.html.in | 2 +
4 files changed, 324 insertions(+), 1 deletion(-)
create mode 100644 docs/domainstatecapture.html.in
diff --git a/docs/docs.html.in b/docs/docs.html.in
index 2d44e3ab2e..a00b131466 100644
--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -124,6 +124,11 @@
+ 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.
+
+
+
+ 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.
+
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.
+
+
+
+ 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:
+
+
+
+
Duration
+
Capturing state can be a lengthy process, so while the
+ captured state ideally represents an atomic point in time
+ corresponding 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.
+
+
+
Amount of state
+
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.
+
+
+
Quiescing of data
+
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.
+
+
+
Quantity of files
+
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.
+
+
+
Impact to guest definition
+
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.
+
+
+
Third-party integration
+
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.
+
+
Full vs. incremental
+
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.
+
+
Local vs. remote
+
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.
+
+
Network latency
+
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.
+
+
+
+ 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.
+
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.
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.
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 virDomainBlockCommit() 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 XML details used with
+ this command.
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.
This API wraps approaches for capturing the disk state of a
+ running guest, but does not track accompanying guest memory
+ state, and can only operate on one block device per job. To
+ get a consistent copy of multiple disks, multiple jobs must 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.
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 virDomainBackupBegin() or at the
+ creation of an external snapshot
+ with virDomainSnapshotCreateXML2(), since a
+ second incremental backup is most useful when using the
+ checkpoint created during the first. See also
+ the XML details used with
+ this command.
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.
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.
+
+
1. Backup via temporary snapshot
+
+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
+
+
+
2. Direct backup
+
+virDomainFSFreeze()
+virDomainBackupBegin()
+virDomainFSThaw()
+wait for push mode event, or pull data over NBD # most time spent here
+virDomainBackupEnd()
+
+
+
+
diff --git a/docs/formatcheckpoint.html.in b/docs/formatcheckpoint.html.in
index ef5f8a826b..030f0d6af0 100644
--- a/docs/formatcheckpoint.html.in
+++ b/docs/formatcheckpoint.html.in
@@ -13,7 +13,9 @@
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.
+ backups requires different libvirt APIs
+ (see domain state capture
+ for a comparison between APIs).
Libvirt is able to facilitate incremental backups by tracking
diff --git a/docs/formatsnapshot.html.in b/docs/formatsnapshot.html.in
index 2bfb69cf49..ee9aa7817f 100644
--- a/docs/formatsnapshot.html.in
+++ b/docs/formatsnapshot.html.in
@@ -9,6 +9,8 @@