Module libvirt-domain-snapshot from libvirt

Creates a new snapshot of a domain based on the snapshot xml contained in xmlDesc, with a top-level element <domainsnapshot>.

If @flags is 0, the domain can be active, in which case the 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 just the disk state prior to booting. The newly created snapshot becomes current (see virDomainSnapshotCurrent()), and is a child of any previous current snapshot.

If @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_VALIDATE, then @xmlDesc is validated against the <domainsnapshot> XML schema.

If @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE, then this is a request to reinstate snapshot metadata that was previously captured from virDomainSnapshotGetXMLDesc() before removing that metadata, rather than creating a new snapshot. This can be used to recreate a snapshot hierarchy on a destination, then remove it on the source, in order to allow migration (since migration normally fails if snapshot metadata still remains on the source machine). 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). When redefining snapshot metadata, the domain's current snapshot will not be altered unless the VIR_DOMAIN_SNAPSHOT_CREATE_CURRENT flag is also present. It is an error to request the VIR_DOMAIN_SNAPSHOT_CREATE_CURRENT flag without VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE. On some hypervisors, redefining an existing snapshot can be used to alter host-specific portions of the domain XML to be used during revert (such as backing filenames associated with disk devices), but must not alter guest-visible layout. When redefining a snapshot name that does not exist, the hypervisor may validate that reverting to the snapshot appears to be possible (for example, disk images have snapshot contents by the requested name). Not all hypervisors support these flags.

If @flags includes VIR_DOMAIN_SNAPSHOT_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 virDomainSnapshotDelete() with VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY). This flag is incompatible with VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE.

If @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_HALT, then the domain will be inactive after the snapshot completes, regardless of whether it was active before; otherwise, a running domain will still be running after the snapshot. This flag is invalid on transient domains, and is incompatible with VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE.

If @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_LIVE, then the domain 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 snapshots.

If @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY, then the snapshot will be limited to the disks described in @xmlDesc, and no VM state will be saved. For an active guest, the disk image may be inconsistent (as if power had been pulled), and specifying this with the VIR_DOMAIN_SNAPSHOT_CREATE_HALT flag risks data loss.

If @flags includes VIR_DOMAIN_SNAPSHOT_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. Moreover, this flag requires VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY to be passed as well.

By default, if the snapshot involves external files, and any of the destination files already exist as a non-empty regular file, the snapshot is rejected to avoid losing contents of those files. However, if @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT, then the destination files must be pre-created manually with the correct image format and metadata including backing store path (this allows a management app to pre-create files with relative backing file names, rather than the default of creating with absolute backing file names). Note that only the file specified in the snapshot XML is inserted as a snapshot thus setting incorrect metadata in the pre-created image may lead to the VM being unable to start or other block jobs may fail.

Be aware that although libvirt prefers to report errors up front with no other effect, some hypervisors have certain types of failures where the overall command can easily fail even though the guest configuration was partially altered (for example, if a disk snapshot request for two disks fails on the second disk, but the first disk alteration cannot be rolled back). If this API call fails, it is therefore normally necessary to follow up with virDomainGetXMLDesc() and check each disk to determine if any partial changes occurred. However, if @flags contains VIR_DOMAIN_SNAPSHOT_CREATE_ATOMIC, then libvirt guarantees that this command will not alter any disks unless the entire set of changes can be done atomically, making failure recovery simpler (note that it is still possible to fail after disks have changed, but only in the much rarer cases of running out of memory or disk space).

Some hypervisors may prevent this operation if there is a current block copy operation; in that case, use virDomainBlockJobAbort() to stop the block copy first.

virDomainSnapshotFree should be used to free the resources after the snapshot object is no longer needed.