Observe the following ('qmp-shell', for brevity) invocation of the four major types (stream, commit, mirror, backup) of live block operations:
(QEMU) block-stream device=node-D base=a.qcow2 job-id=job-block-stream (QEMU) block-commit device=node-D base=a.qcow2 top=b.qcow2 job-id=job-block-commit (QEMU) drive-mirror device=node-D target=e.qcow2 sync=full job-id=job-drive-mirror (QEMU) drive-backup device=node-D sync=full target=e.qcow2 job-id=job-drive-backup (QEMU) blockdev-backup device=node-B target=node-E sync=full job-id=job-blockdev-backup (QEMU) blockdev-mirror device=node-D target=node-E sync=full job-id=job-blockdev-mirror While we have `blockdev-{mirror, backup}` as 'node-name'-alternatives for `drive-{mirror, backup}`, as the eagle-eyed will, the `block-stream` and `block-commit` commands still operate on file names for parameters 'base' and 'top'. When I brought it up on #qemu, OFTC, where Max gave some context, and even said: "We just shouldn't use filenames there ['commit', 'stream'], simple as that". Does upstream have a plan here for 2.10 / 3.0? Will there be new `blockdev-stream`, and `blockdev-commit`, or will `block-{stream, commit}` will be adjusted to take 'node-name'? * * * Then I _vaguely_ remembered reading a thread on the upstream list about creating a new 'blockdev-stream' (but I didn't find anything about 'blockdev-commit'), even if a bit confusing. Sure enough, when I went digging the archives, I found, where Alberto extended the 'device' parameter to take 'node-name', and there was an ensuing discussion about a new 'blockdev-stream': https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg03236.html -- [PATCH v11 00/19] Support streaming to an intermediate layer And this patch had the said discussion: https://lists.gnu.org/archive/html/qemu-block/2016-10/msg00117.html tl;dr seemed to be: "add a new `blockdev-stream` [and `blockdev-commit`?] because it is easy to introspect, and is a 'saner' interface". To recap from that thread, Kevin wrote[1]: "Oh, we still have those filename-based parameters? :-/ "Should we introduce a new, clean blockdev-stream command that fixes this and matches the common name pattern? Of course, block-stream vs. blockdev-stream could be a bit confusing, too..." And, Eric seemed agreeable to a new command[2], saying, "a new command is easy to introspect". Markus chimed in[3] with some background context, and a design discussion aobut whether it makes sense to extend existing commands vs. adding new, giving pros / cons of both. Finally, Kevin concluded[4]: "It has never been a sane interface in the first place (identifying a backing file node by its filename). "We ended up having two versions of all block job commands anyway (one that creates an image file, and later one that just takes a node-name of an existing node), except for image streaming so far. So it would be consistent (and enable consistent naming for the preferred commands) to have it here, too." [1] https://lists.gnu.org/archive/html/qemu-block/2016-10/msg00319.html [2] https://lists.gnu.org/archive/html/qemu-block/2016-10/msg00328.html [3] https://lists.gnu.org/archive/html/qemu-block/2016-10/msg00333.html [4] https://lists.gnu.org/archive/html/qemu-block/2016-10/msg00354.html -- /kashyap