Lines Matching full:image
15 be used to manipulate disk image chains to accomplish certain tasks,
17 disk image chains by merging data from overlays into backing files; live
18 synchronize data from a disk image chain (including current active disk)
19 to another target image; and point-in-time (and incremental) backups of
34 Disk image backing chain notation
37 A simple disk image chain. (This can be created live using QMP
49 The arrow can be read as: Image [A] is the backing file of disk image
50 [B]. And live QEMU is currently writing to image [B], consequently, it
54 files in a disk image backing chain:
56 (1) Directional: 'base' and 'top'. Given the simple disk image chain
57 above, image [A] can be referred to as 'base', and image [B] as
62 simple disk image chain from the above, disk image [A] is referred
63 to as the backing file, and image [B] as overlay.
100 (i.e. merge the current active layer into the base image).
119 disk to another image.
144 parameter that is used to refer to the disk image a.qcow2 ('node-A') --
145 this is a cleaner way to refer to a disk image (as opposed to referring
147 ``node-name`` to each further disk image created (either via
149 image chain, and continue to refer to the disks using their
171 Example disk image chain
174 We will use the below disk image chain (and occasionally spelling it
179 Where [A] is the original base image; [B] and [C] are intermediate
180 overlay images; image [D] is the active layer -- i.e. live QEMU is
182 to the rightmost image in a disk image chain.)
184 The above image chain can be created by invoking
186 creation of overlay image [B]) using the ``qmp-shell`` (our invocation
201 image [A] -- it is the backing file, based on which the overlay image,
214 In our disk image chain::
241 Given our original example disk image chain from earlier::
245 The disk image chain can be shortened in one of the following different
251 the base image, [A], and overlay images, [B] and [C], into [D],
253 standalone image, [D] -- with contents from [A], [B] and [C] merged
260 (2) Taking the same example disk image chain mentioned earlier, merge
263 backing file pointer of image [D] will be adjusted to point to image
271 with the original example disk image chain, with a total of four
272 images, it is possible to copy contents from image [B] into image
273 [C]. Once the copy is finished, image [B] can now be (optionally)
274 discarded; and the backing file pointer of image [C] will be
276 streaming" of [B] into [C], the resulting image chain will be (where
286 active layer, where 'node-D' is the current active image (by default
300 image [D] ends up referring to image [A] as its backing file::
306 image::
333 image in a disk image chain where live QEMU will be writing to, into the
334 base image). This is analogous to ``block-stream``, but in the opposite
337 Again, starting afresh with our example disk image chain, where live
338 QEMU is writing to the right-most image in the chain, [D]::
342 The disk image chain can be shortened in one of the following ways:
346 (1) Commit content from only image [B] into image [A]. The resulting
347 chain is the following, where image [C] is adjusted to point at [A]
352 (2) Commit content from images [B] and [C] into image [A]. The
353 resulting chain, where image [D] is adjusted to point to image [A]
361 image [A]. The resulting chain (in this case, a consolidated single
362 image)::
366 (4) Commit content from image only image [C] into image [B]. The
371 (5) Commit content from image [C] and the active layer [D] into image
381 image [B] into image [A], the invocation is as follows::
396 required. As the end result, the backing file of image [C] is adjusted
397 to point to image [A], and the original 4-image chain will end up being
403 The intermediate image [B] is invalid (as in: no more further
406 Reasoning: An intermediate image after a 'stream' operation still
408 However, an intermediate image after a 'commit' operation no longer
415 is copied into the backing file (also called the base image). In the
416 second phase, adjust the said backing file as the current active image
428 convert a disk image chain such as this::
506 Synchronize a running disk image chain (all or part of it) to a target
507 image.
509 Again, given our familiar disk image chain::
514 allows you to copy data from the entire chain into a single target image
539 image chain (or only the top-most image, depending on the ``sync``
540 mode), contained in the target image [E]. One use case for this is
545 QEMU) to point to the target image, [E], causing all the new writes
549 *which* part of the disk image chain will be copied to the target.
552 (1) ``full`` -- Synchronize the content of entire disk image chain to
555 (2) ``top`` -- Synchronize only the contents of the top-most disk image
565 backup, and in the background the whole image is copied
581 To copy the contents of the entire disk image chain, from [A] all the
629 the following being: the target image, [E], will be populated with
650 can be discarded. However, with 'commit', the *existing* base image
652 the case of 'mirror', a *new* target image is populated with the data
653 from the disk image chain.
664 Given the disk image chain::
669 contents of the *top*-most disk image (i.e. the active layer), [D], to a
679 the "active layer", and not the rest of the image chain, is copied to
689 destination host, let's create a target overlay image (with the image
691 of image [D] (from the source QEMU) will be mirrored to::
711 Given the disk image chain on source QEMU::
717 the content of image [D].
737 (2) [On *destination* QEMU] And export the destination disk image using
807 Also: for ``blockdev-mirror``, the 'target' image needs to be explicitly
812 entire disk image chain, to a target, using ``blockdev-mirror`` would be:
817 (1) Create the target image (using ``qemu-img``), say, ``e.qcow2``
835 (7) Then, finally, compare the contents of the disk image chain, and
843 Given the disk image chain::
847 To copy the contents of the entire disk image chain, from [A] all the
856 Create the target image, [E]::
860 Add the above created target image to QEMU, via ``blockdev-add``::
950 Yet again, starting afresh with our example disk image chain::
954 To create a target image [E], with content populated from image [A] to
956 image does not exist, ``drive-backup`` will create it)::
993 of an entire disk image chain, to a target, using ``blockdev-backup``
999 (1) Create the target image (using ``qemu-img``), say, ``e.qcow2``
1011 (5) Then, finally, compare the contents of the disk image chain, and
1021 Given a disk image chain of depth 1 where image [B] is the active
1027 to a target image (say, [E]), which has the full content from [A] and
1044 Create a target image that will contain the copy::
1064 image chain, consisting of images [A] and [B] to the target image
1103 ``qemu-img compare`` to verify the integrity of the disk image
1107 The end result will be the image 'e.qcow2' containing a
1108 point-in-time backup of the disk image chain -- i.e. contents from
1112 One way to confirm the backup disk image contains the identical content
1113 with the disk image chain is to compare the backup and the contents of
1119 Warning: Image size mismatch!
1122 NOTE: The "Warning: Image size mismatch!" is expected, as we created the
1123 target image (e.qcow2) with 39M size.