File: formatcheckpoint.html.in

package info (click to toggle)
libvirt 5.6.0-2
  • links: PTS, VCS
  • area: main
  • in suites: bullseye
  • size: 240,844 kB
  • sloc: ansic: 584,521; xml: 176,725; sh: 9,912; python: 4,731; perl: 4,343; makefile: 3,321; ml: 465
file content (198 lines) | stat: -rw-r--r-- 8,980 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
  <body>
    <h1>Checkpoint XML format</h1>

    <ul id="toc"></ul>

    <h2><a id="CheckpointAttributes">Checkpoint XML</a></h2>

    <p>
      One method of capturing domain disk backups is via the use of
      incremental backups. Right now, incremental backups are only
      supported for the QEMU hypervisor when using qcow2 disks at the
      active layer; if other disk formats are in use, capturing disk
      backups requires different libvirt APIs
      (see <a href="kbase/domainstatecapture.html">domain state
      capture</a> for a comparison between APIs).
    </p>
    <p>
      Libvirt is able to facilitate incremental backups by tracking
      disk checkpoints, which are points in time against which it is
      easy to compute which portion of the disk has changed. Given a
      full backup (a backup created from the creation of the disk to a
      given point in time), coupled with the creation of a disk
      checkpoint at that time, and an incremental backup (a backup
      created from just the dirty portion of the disk between the
      first checkpoint and the second backup operation), it is
      possible to do an offline reconstruction of the state of the
      disk at the time of the second backup without having to copy as
      much data as a second full backup would require.  Future API
      additions will make it possible to create checkpoints in
      conjunction with a backup
      via <code>virDomainBackupBegin()</code> or with an external
      snapshot via <code>virDomainSnapshotCreateXML2</code>; but for
      now, libvirt exposes enough support to create disk checkpoints
      independently from a backup operation
      via <code>virDomainCheckpointCreateXML()</code> <span class="since">since
      5.6.0</span>.  Likewise, the creation of checkpoints when
      external snapshots exist is currently forbidden, although future
      work will make it possible to integrate these two concepts.
    </p>
    <p>
      Attributes of libvirt checkpoints are stored as child elements
      of the <code>domaincheckpoint</code> element. At checkpoint
      creation time, normally only
      the <code>name</code>, <code>description</code>,
      and <code>disks</code> elements are settable. The rest of the
      fields are ignored on creation and will be filled in by libvirt
      in for informational purposes
      by <code>virDomainCheckpointGetXMLDesc()</code>. However, when
      redefining a checkpoint, with
      the <code>VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE</code> flag
      of <code>virDomainCheckpointCreateXML()</code>, all of the XML
      fields described here are relevant on input, even the fields
      that are normally described as readonly for output.
    </p>
    <p>
      The top-level <code>domaincheckpoint</code> element may contain
      the following elements:
    </p>
    <dl>
      <dt><code>name</code></dt>
      <dd>The optional name for this checkpoint. If the name is
        omitted, libvirt will create a name based on the time of the
        creation.
      </dd>
      <dt><code>description</code></dt>
      <dd>An optional human-readable description of the checkpoint.
        If the description is omitted when initially creating the
        checkpoint, then this field will be empty.
      </dd>
      <dt><code>disks</code></dt>
      <dd>On input, this is an optional listing of specific
        instructions for disk checkpoints; it is needed when making a
        checkpoint on only a subset of the disks associated with a
        domain. In particular, since QEMU checkpoints require qcow2
        disks, this element may be needed on input for excluding guest
        disks that are not in qcow2 format. If the entire element was
        omitted on input, then all disks participate in the
        checkpoint, otherwise, only the disks explicitly listed which
        do not also use <code>checkpoint='no'</code> will
        participate. On output, this is the checkpoint state of each
        of the domain's disks.
        <dl>
          <dt><code>disk</code></dt>
          <dd>This sub-element describes the checkpoint properties of
            a specific disk with the following attributes:
            <dl>
              <dt><code>name</code></dt>
              <dd>A mandatory attribute which must match either
                the <code>&lt;target dev='name'/&gt;</code> or an
                unambiguous <code>&lt;source file='name'/&gt;</code>
                of one of
                the <a href="formatdomain.html#elementsDisks">disk
                devices</a> specified for the domain at the time of
                the checkpoint.</dd>
              <dt><code>checkpoint</code></dt>
              <dd>An optional attribute; possible values
                are <code>no</code> when the disk does not participate
                in this checkpoint; or <code>bitmap</code> if the disk
                will track all changes since the creation of this
                checkpoint via a bitmap.</dd>
              <dt><code>bitmap</code></dt>
              <dd>The attribute <code>bitmap</code> is only valid
                if <code>checkpoint='bitmap'</code>; it describes the
                name of the tracking bitmap (defaulting to the
                checkpoint name).</dd>
              <dt><code>size</code></dt>
              <dd>The attribute <code>size</code> is ignored on input;
                on output, it is only present if
                the <code>VIR_DOMAIN_CHECKPOINT_XML_SIZE</code> flag
                was used to perform a dynamic query of the estimated
                size in bytes of the changes made since the checkpoint
                was created.</dd>
            </dl>
          </dd>
        </dl>
      </dd>
      <dt><code>creationTime</code></dt>
      <dd>A readonly representation of the time this checkpoint was
        created. The time is specified in seconds since the Epoch,
        UTC (i.e. Unix time).
      </dd>
      <dt><code>parent</code></dt>
      <dd>Readonly, present if this checkpoint has a parent. The
        parent name is given by the sub-element <code>name</code>. The
        parent relationship allows tracking a list of related checkpoints.
      </dd>
      <dt><code>domain</code></dt>
      <dd>A readonly representation of the
        inactive <a href="formatdomain.html">domain configuration</a>
        at the time the checkpoint was created. This element may be
        omitted for output brevity by supplying
        the <code>VIR_DOMAIN_CHECKPOINT_XML_NO_DOMAIN</code> flag, but
        the resulting XML is no longer viable for use with
        the <code>VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE</code> flag
        of <code>virDomainCheckpointCreateXML()</code>. The domain
        will have security-sensitive information omitted unless the
        flag <code>VIR_DOMAIN_CHECKPOINT_XML_SECURE</code> is provided
        on a read-write connection.
      </dd>
    </dl>

    <h2><a id="example">Examples</a></h2>

    <p>Using this XML to create a checkpoint of just vda on a qemu
      domain with two disks and a prior checkpoint:</p>
    <pre>
&lt;domaincheckpoint&gt;
  &lt;description&gt;Completion of updates after OS install&lt;/description&gt;
  &lt;disks&gt;
    &lt;disk name='vda' checkpoint='bitmap'/&gt;
    &lt;disk name='vdb' checkpoint='no'/&gt;
  &lt;/disks&gt;
&lt;/domaincheckpoint&gt;</pre>

    <p>will result in XML similar to this from
      <code>virDomainCheckpointGetXMLDesc()</code>:</p>
    <pre>
&lt;domaincheckpoint&gt;
  &lt;name&gt;1525889631&lt;/name&gt;
  &lt;description&gt;Completion of updates after OS install&lt;/description&gt;
  &lt;parent&gt;
    &lt;name&gt;1525111885&lt;/name&gt;
  &lt;/parent&gt;
  &lt;creationTime&gt;1525889631&lt;/creationTime&gt;
  &lt;disks&gt;
    &lt;disk name='vda' checkpoint='bitmap' bitmap='1525889631'/&gt;
    &lt;disk name='vdb' checkpoint='no'/&gt;
  &lt;/disks&gt;
  &lt;domain type='qemu'&gt;
    &lt;name&gt;fedora&lt;/name&gt;
    &lt;uuid&gt;93a5c045-6457-2c09-e56c-927cdf34e178&lt;/uuid&gt;
    &lt;memory&gt;1048576&lt;/memory&gt;
    ...
    &lt;devices&gt;
      &lt;disk type='file' device='disk'&gt;
        &lt;driver name='qemu' type='qcow2'/&gt;
        &lt;source file='/path/to/file1'/&gt;
        &lt;target dev='vda' bus='virtio'/&gt;
      &lt;/disk&gt;
      &lt;disk type='file' device='disk' snapshot='external'&gt;
        &lt;driver name='qemu' type='raw'/&gt;
        &lt;source file='/path/to/file2'/&gt;
        &lt;target dev='vdb' bus='virtio'/&gt;
      &lt;/disk&gt;
      ...
    &lt;/devices&gt;
  &lt;/domain&gt;
&lt;/domaincheckpoint&gt;</pre>

    <p>With that checkpoint created, the qcow2 image is now tracking
      all changes that occur in the image since the checkpoint via
      the persistent bitmap named <code>1525889631</code>.
    </p>
  </body>
</html>