Lines Matching refs:A
37 A simple disk image chain. (This can be created live using QMP
45 [A] <----- [B]
49 The arrow can be read as: Image [A] is the backing file of disk image
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
138 node-name=node-A,driver=qcow2,file.driver=file,file.node-name=file,file.filename=./a.qcow2 \\
139 -device virtio-blk,drive=node-A,id=virtio0 \\
144 parameter that is used to refer to the disk image a.qcow2 ('node-A') --
177 [A] <-- [B] <-- [C] <-- [D]
179 Where [A] is the original base image; [B] and [C] are intermediate
189 …(QEMU) blockdev-snapshot-sync node-name=node-A snapshot-file=b.qcow2 snapshot-node-name=node-B for…
193 "node-name": "node-A",
200 Here, "node-A" is the name QEMU internally uses to refer to the base
201 image [A] -- it is the backing file, based on which the overlay image,
211 A note on points-in-time vs file names
216 [A] <-- [B] <-- [C] <-- [D]
220 - Point 1: Guest state when [B] was created is contained in file [A]
221 - Point 2: Guest state when [C] was created is contained in [A] + [B]
223 [A] + [B] + [C]
224 - Active layer: Current guest state is contained in [A] + [B] + [C] +
243 [A] <-- [B] <-- [C] <-- [D]
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
264 [A]. The resulting chain will be::
266 [A] <-- [D]
275 adjusted to point to [A]. I.e. after performing "intermediate
279 [A] <-- [C] <-- [D]
300 image [D] ends up referring to image [A] as its backing file::
302 (QEMU) block-stream device=node-D base-node=node-A job-id=job0
305 images [B] into [C], where [C] ends up referring to [A] as its backing
308 (QEMU) block-stream device=node-C base-node=node-A job-id=job0
340 [A] <-- [B] <-- [C] <-- [D]
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]
350 [A] <-- [C] <-- [D]
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]
356 [A] <-- [D]
361 image [A]. The resulting chain (in this case, a consolidated single
364 [A]
369 [A] <-- [B] <-- [D]
374 [A] <-- [B]
381 image [B] into image [A], the invocation is as follows::
397 to point to image [A], and the original 4-image chain will end up being
400 [A] <-- [C] <-- [D]
430 [A] <-- [B] <-- [C] <-- [D]
434 [A]
437 the active layer, [D], is committed back to [A] -- which is where live
511 [A] <-- [B] <-- [C] <-- [D]
581 To copy the contents of the entire disk image chain, from [A] all the
630 content from the entire chain, [A] to [D])::
666 [A] <-- [B] <-- [C] <-- [D]
674 chain, involving images [A], [B], and [C], visible via other means
687 chain -- from images [A] to [C] -- are already expected to exist in some
688 form (e.g. in a file called, ``Contents-of-A-B-C.qcow2``). Now, on the
690 ``Contents-of-A-B-C.qcow2`` as its backing file), to which the contents
693 $ qemu-img create -f qcow2 -b ./Contents-of-A-B-C.qcow2 \
713 [A] <-- [B] <-- [C] <-- [D]
716 ``[A] <-- [B] <-- [C]`` are *already* present, and therefore copy *only*
845 [A] <-- [B] <-- [C] <-- [D]
847 To copy the contents of the entire disk image chain, from [A] all the
852 …(QEMU) blockdev-snapshot-sync node-name=node-A snapshot-file=b.qcow2 snapshot-node-name=node-B for…
952 [A] <-- [B] <-- [C] <-- [D]
954 To create a target image [E], with content populated from image [A] to
1024 [A] <-- [B]
1027 to a target image (say, [E]), which has the full content from [A] and
1032 …(QEMU) blockdev-snapshot-sync node-name=node-A snapshot-file=b.qcow2 snapshot-node-name=node-B for…
1036 "node-name": "node-A",
1064 image chain, consisting of images [A] and [B] to the target image
1109 images [A] and [B] at the time the ``blockdev-backup`` command was