From nobody Wed Jan 15 08:10:15 2025
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
Return-Path: virDomainSaveImageGetXMLDesc()
to work with
those files.
System checkpoints are created
- by virDomainSnapshotCreateXML()
with no flags, and
+
Full system snapshots are created
+ by virDomainSnapshotCreateXML()
with no flags, while
disk snapshots are created by the same function with
- the VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY
flag; in
- both cases, they are restored by
+ the VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY
+ flag. Regardless of the flags provided, restoration of the
+ snapshot is handled by
the virDomainRevertToSnapshot()
function. For
these types of snapshots, libvirt tracks each snapshot as a
separate virDomainSnapshotPtr
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 disks
with a system
- checkpoint. This element has a list of disk
+ 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 disk
sub-elements, describing anywhere from zero to all of the
disks associated with the domain. Since
0.9.5
@@ -206,11 +204,12 @@
state
virDomainRevertToSnapshot()
. Additionally,
+ this state, unless overridden
+ by virDomainRevertToSnapshot()
flags to revert to
+ a running or paused state. Additionally,
this field can be the value "disk-snapshot"
(since 0.9.5) 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 =3D=3D VIR_DOMAIN_DISK_SNAPSHOT) !=3D
(def->state =3D=3D 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 snapsh=
ot)
* 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 snapsh=
ot)
* 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 9f71641dfa..bb5bc4d200 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 =3D=3D VIR_DOMAIN_SNAPSHOT_LOCATION_INTERNAL && !foun=
d_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(virQEMUDrive=
rPtr driver,
if (virDomainObjGetState(vm, NULL) =3D=3D VIR_DOMAIN_PMSUSPENDED) {
pmsuspended =3D true;
} else if (virDomainObjGetState(vm, NULL) =3D=3D VIR_DOMAIN_RUNNING) {
- /* For external checkpoints (those with memory), the guest
+ /* For full system external snapshots (those with memory), the gue=
st
* 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 =3D=3D 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[] =3D {
},
{.name =3D "active",
.type =3D VSH_OT_BOOL,
- .help =3D N_("filter by snapshots taken while active (system checkpoi=
nts)")
+ .help =3D N_("filter by snapshots taken while active (full system sna=
pshots)")
},
{.name =3D "disk-only",
.type =3D 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 hyp=
ervisors may fail
after partially performing the action, and B+ 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. Some of the topics presented below may relate to inactive + state collection, but it is not the primary focus of this page. +
+ +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: +
+ ++ 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. +
+ +With those definitions, the following libvirt APIs related to + state capture have these properties:
+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.virDomainBackupBegin()
, since a
+ second incremental backup is most useful when using the
+ checkpoint created during the first. 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 +virDomainBackeupEnd() ++ + + 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 @@
+ Snapshots are one form + of domain state capture. There are several types of snapshots:
virDomainBackupBegin()
, since a
second incremental backup is most useful when using the
- checkpoint created during the first.
+ this command.
+ 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 domain state capture + for a comparison between 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. Most disk
+ checkpoints are created in concert with a backup
+ via virDomainBackupBegin()
; however, libvirt also
+ 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.
+
+ 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. +
+
+ The top-level domaincheckpoint
element may contain
+ the following elements:
+
name
description
disks
disk
+ sub-elements, describing anywhere from one to all of the disks
+ associated with the domain.
+ disk
name
is
+ mandatory, and 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. The attribute checkpoint
is
+ optional on input; 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, in
+ which case another attribute bitmap
will be
+ the name of the tracking bitmap (defaulting to the
+ checkpoint name). On output, an additional
+ attribute size
may be 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
parent
domain
+ Creating a backup, whether full or incremental, is done
+ via virDomainBackupBegin()
, 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).
+
+ The instructions for beginning a backup job are provided as
+ attributes and elements of the
+ top-level domainbackup
element. This element
+ includes an optional attribute mode
which can be
+ either "push" or "pull" (default push). Where elements are
+ optional on creation, virDomainBackupGetXMLDesc()
+ 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:
+
incremental
server
protocol
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.
+ disks
disk
sub-elements, describing anywhere
+ from one to all of the disks associated with the domain.
+ disk
name
is
+ mandatory, and 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. The optional attribute type
can
+ be file
, block
,
+ or network
, similar to a disk declaration for
+ a domain, controls what additional sub-elements are needed
+ to describe the destination (such as protocol
+ for a network destination). In push mode backups, the
+ primary sub-element is target
; in pull mode,
+ the primary sub-element is scratch
; but
+ either way, the primary sub-element describes the file
+ name to be used during the backup operation, similar to
+ the source
sub-element of a domain disk. In
+ push mode, an optional sub-element driver
can
+ also be used, with an attribute type
to
+ specify a destination format different from
+ qcow2. Additionally, if a push backup is not
+ incremental, target
may contain an optional
+ attribute shallow=3D"on"
so that the
+ destination file copies only the top-most source file in a
+ backing chain, rather than collapsing the entire chain
+ into the copy.
+ Using this XML to create a checkpoint of just vda on a qemu + domain with two disks and a prior checkpoint:
++<domaincheckpoint> + <description>Completion of updates after OS install</descriptio= n> + <disks> + <disk name=3D'vda' checkpoint=3D'bitmap'/> + <disk name=3D'vdb' checkpoint=3D'no'/> + </disks> +</domaincheckpoint>+ +
will result in XML similar to this from
+ virDomainCheckpointGetXMLDesc()
:
+<domaincheckpoint> + <name>1525889631</name> + <description>Completion of updates after OS install</descriptio= n> + <creationTime>1525889631</creationTime> + <parent> + <name>1525111885</name> + </parent> + <disks> + <disk name=3D'vda' checkpoint=3D'bitmap' bitmap=3D'1525889631'/> + <disk name=3D'vdb' checkpoint=3D'no'/> + </disks> + <domain type=3D'qemu'> + <name>fedora</name> + <uuid>93a5c045-6457-2c09-e56c-927cdf34e178</uuid> + <memory>1048576</memory> + ... + <devices> + <disk type=3D'file' device=3D'disk'> + <driver name=3D'qemu' type=3D'qcow2'/> + <source file=3D'/path/to/file1'/> + <target dev=3D'vda' bus=3D'virtio'/> + </disk> + <disk type=3D'file' device=3D'disk' snapshot=3D'external'> + <driver name=3D'qemu' type=3D'raw'/> + <source file=3D'/path/to/file2'/> + <target dev=3D'vdb' bus=3D'virtio'/> + </disk> + ... + </devices> + </domain> +</domaincheckpoint>+ +
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
. Now, we
+ can make a subsequent call
+ to virDomainBackupBegin()
to perform an incremental
+ backup of just this data, using the following XML to start a
+ pull model NBD export of the vda disk:
+
+<domainbackup mode=3D"pull"> + <incremental>1525889631</incremental> + <server transport=3D"unix" socket=3D"/path/to/server"/> + <disks/> + <disk name=3D'vda' type=3D'file'> + <scratch file=3D'/path/to/file1.scratch'/> + </disk> + </disks/> +</domainbackup> ++ + 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 @@ domain capabilities, node devices, secrets, - snapshots