docs/interop/live-block-operations.rst

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 \\
143 QEMU 2.9 onwards.  In the above invocation, notice the ``node-name``
144 parameter that is used to refer to the disk image a.qcow2 ('node-A') --
147 ``node-name`` to each further disk image created (either via
150 ``node-name`` (where possible, because ``block-commit`` does not yet, as
151 of QEMU 2.9, accept ``node-name`` parameter) when performing various
189 …(QEMU) blockdev-snapshot-sync node-name=node-A snapshot-file=b.qcow2 snapshot-node-name=node-B for…
193             "node-name": "node-A",
196             "snapshot-node-name": "node-B"
200 Here, "node-A" is the name QEMU internally uses to refer to the base
207 …(QEMU) blockdev-snapshot-sync node-name=node-B snapshot-file=c.qcow2 snapshot-node-name=node-C for…
208 …(QEMU) blockdev-snapshot-sync node-name=node-C snapshot-file=d.qcow2 snapshot-node-name=node-D for…
286 active layer, where 'node-D' is the current active image (by default
290     (QEMU) block-stream device=node-D job-id=job0
294             "device": "node-D",
302     (QEMU) block-stream device=node-D base-node=node-A job-id=job0
308     (QEMU) block-stream device=node-C base-node=node-A job-id=job0
383     (QEMU) block-commit device=node-D base=a.qcow2 top=b.qcow2 job-id=job0
387             "device": "node-D",
442     (QEMU) block-commit device=node-D base=a.qcow2 top=d.qcow2 job-id=job0
446             "device": "node-D",
585     (QEMU) drive-mirror device=node-D target=e.qcow2 sync=full job-id=job0
589             "device": "node-D",
706 …node-name=node-TargetDisk,driver=qcow2,file.driver=file,file.node-name=file,file.filename=./target…
707     -device virtio-blk,drive=node-TargetDisk,id=virtio0 \\
740         (QEMU) nbd-server-add device=node-TargetDisk writable=true
744                 "device": "node-TargetDisk"
754 …(QEMU) drive-mirror device=node-D target=nbd:localhost:49153:exportname=node-TargetDisk sync=top m…
758                 "device": "node-D",
761                 "target": "nbd:localhost:49153:exportname=node-TargetDisk",
805 ``drive-mirror``, except that it operates at node-level in a BDS graph.
809 ``blockdev-add``, which assigns a name to the to-be created target node.
852 …(QEMU) blockdev-snapshot-sync node-name=node-A snapshot-file=b.qcow2 snapshot-node-name=node-B for…
853 …(QEMU) blockdev-snapshot-sync node-name=node-B snapshot-file=c.qcow2 snapshot-node-name=node-C for…
854 …(QEMU) blockdev-snapshot-sync node-name=node-C snapshot-file=d.qcow2 snapshot-node-name=node-D for…
862     (QEMU) blockdev-add driver=qcow2 node-name=node-E file={"driver":"file","filename":"e.qcow2"}
866             "node-name": "node-E",
877     (QEMU) blockdev-mirror device=node-B target=node-E sync=full job-id=job0
881             "device": "node-D",
883             "target": "node-E",
958     (QEMU) drive-backup device=node-D sync=full target=e.qcow2 job-id=job0
962             "device": "node-D",
979 as a target.  Instead you use ``node-name`` of existing block node,
982 ``format`` arguments which don't apply to an existing block node. See
989 The ``blockdev-backup`` command operates at node-level in a Block Driver
1032 …(QEMU) blockdev-snapshot-sync node-name=node-A snapshot-file=b.qcow2 snapshot-node-name=node-B for…
1036             "node-name": "node-A",
1039             "snapshot-node-name": "node-B"
1050     (QEMU) blockdev-add driver=qcow2 node-name=node-E file={"driver":"file","filename":"e.qcow2"}
1054             "node-name": "node-E",
1067     (QEMU) blockdev-backup device=node-B target=node-E sync=full job-id=job0
1071             "device": "node-B",
1073             "target": "node-E",