There are several types of snapshots:
Libvirt can manage all three types of snapshots. For now, VM
state (memory) snapshots are created only by
the virDomainSave()
, virDomainSaveFlags
,
and virDomainManagedSave()
functions, and restored
via the virDomainRestore()
,
virDomainRestoreFlags()
, virDomainCreate()
,
and virDomainCreateWithFlags()
functions (as well
as via domain autostart). With managed snapshots, libvirt
tracks all information internally; with save images, the user
tracks the snapshot file, but libvirt provides functions such
as virDomainSaveImageGetXMLDesc()
to work with
those files.
System checkpoints are created
by virDomainSnapshotCreateXML()
with no flags, and
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 virDomainRevertToSnapshot()
function. For
these types of snapshots, libvirt tracks each snapshot as a
separate virDomainSnapshotPtr
object, and maintains
a tree relationship of which snapshots descended from an earlier
point in time.
Attributes of libvirt snapshots are stored as child elements of
the domainsnapshot
element. At snapshot 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 virDomainSnapshotGetXMLDesc()
. However, when
redefining a snapshot (since 0.9.5),
with the VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE
flag
of virDomainSnapshotCreateXML()
, all of the XML
described here is relevant.
Snapshots are maintained in a hierarchy. A domain can have a current snapshot, which is the most recent snapshot compared to the current state of the domain (although a domain might have snapshots without a current snapshot, if snapshots have been deleted in the meantime). Creating or reverting to a snapshot 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.
The top-level domainsnapshot
element may contain
the following elements:
name
description
memory
snapshot
must be no
, since
there is no VM state saved; otherwise, the attribute can
be internal
if the memory state is piggy-backed with
other internal disk state, or external
along with
a second attribute file
giving the absolute path
of the file holding the VM memory state. Since
1.0.1
disks
disks
with a system
checkpoint. 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
disk
name
is
mandatory, and must match either the <target
dev='name'/>
or an unambiguous <source
file='name'/>
of one of
the disk
devices specified for the domain at the time of the
snapshot. The attribute snapshot
is
optional, and the possible values are the same as the
snapshot
attribute for
disk devices
(no
, internal
,
or external
). Some hypervisors like ESX
require that if specified, the snapshot mode must not
override any snapshot mode attached to the corresponding
domain disk, while others like qemu allow this field to
override the domain default. If the snapshot mode is
external (whether specified or inherited), then there is
an optional sub-element source
, with an
attribute file
giving the name, and an
optional sub-element driver
, with an
attribute type
giving the driver type (such
as qcow2), of the new file created by the external
snapshot of the new file. If source
is not
given, a file name is generated that consists of the
existing file name with anything after the trailing dot
replaced by the snapshot name. Remember that with external
snapshots, the original file name becomes the read-only
snapshot, and the new file name contains the read-write
delta of all disk changes since the snapshot.
Since 1.2.2 the disk
element
supports an optional attribute type
if the
snapshot
attribute is set to external
.
This attribute specifies the snapshot target storage type and allows
to overwrite the default file
type. The type
attribute along with the format of the source
sub-element is identical to the source
element used in
domain disk definitions. See the
disk devices section
documentation for further information.
Libvirt currently supports the type
element in the qemu
driver and supported values are file
and
block
(since 1.2.2).
creationTime
state
virDomainRevertToSnapshot()
. 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
snapshot will default to an inactive guest. Readonly.
parent
domain
VIR_DOMAIN_SNAPSHOT_REVERT_FORCE
flag
in virDomainRevertToSnapshot()
. Newer versions
of libvirt (since 0.9.5) store the entire
inactive domain configuration
at the time of the snapshot (since
0.9.5). Readonly.
Using this XML to create a disk snapshot of just vda on a qemu domain with two disks:
<domainsnapshot> <description>Snapshot of OS install and updates</description> <disks> <disk name='/path/to/old'> <source file='/path/to/new'/> </disk> <disk name='vdb' snapshot='no'/> </disks> </domainsnapshot>
will result in XML similar to this from
virDomainSnapshotGetXMLDesc()
:
<domainsnapshot> <name>1270477159</name> <description>Snapshot of OS install and updates</description> <state>running</state> <creationTime>1270477159</creationTime> <parent> <name>bare-os-install</name> </parent> <memory snapshot='no'/> <disks> <disk name='vda' snapshot='external'> <driver type='qcow2'/> <source file='/path/to/new'/> </disk> <disk name='vdb' snapshot='no'/> </disks> <domain> <name>fedora</name> <uuid>93a5c045-6457-2c09-e56c-927cdf34e178</uuid> <memory>1048576</memory> ... <devices> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/path/to/old'/> <target dev='vda' bus='virtio'/> </disk> <disk type='file' device='disk' snapshot='external'> <driver name='qemu' type='raw'/> <source file='/path/to/old2'/> <target dev='vdb' bus='virtio'/> </disk> ... </devices> </domain> </domainsnapshot>
With that snapshot created, /path/to/old
is the
read-only backing file to the new active
file /path/to/new
. The <domain>
element within the snapshot xml records the state of the domain
just before the snapshot; a call
to virDomainGetXMLDesc()
will show that the domain
has been changed to reflect the snapshot:
<domain> <name>fedora</name> <uuid>93a5c045-6457-2c09-e56c-927cdf34e178</uuid> <memory>1048576</memory> ... <devices> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/path/to/new'/> <target dev='vda' bus='virtio'/> </disk> <disk type='file' device='disk' snapshot='external'> <driver name='qemu' type='raw'/> <source file='/path/to/old2'/> <target dev='vdb' bus='virtio'/> </disk> ... </devices> </domain>