Protocol 'node-name' vs format 'node-name'
-----------------------------------------

[Discussion with Eric Blake on #qemu IRC, OFTC.]

There are (at least) two named nodes per element in the backing chain
(the protocol driver, like 'file', and the format driver, like 'qcow2').

[kashyap] 

    One last question to round up that last topic: what QMP commands
    would take the protocol 'node-name'?

[eblake] 

    These days, most QMP commands dealing with blocks (anything in
    qapi/block-core.json) _should_ take node names, and document that.
    Although the parameter naming isn't always obvious (sometimes its
    'node', sometimes 'node-name', sometimes 'device')

[kashyap] 

    Note how I said _protocol_ 'node-name', you just explained that
    _format_ 'node-name' is what we use for streaming (also for commit,
    etc) operation.

[eblake]

Our [QEMU's] goal has been that you can refer to a node by the device
that is using the node, or by the node name itself.

One particular use for the protocol 'node-name' is with the high-level
watermarking (also just recently added in libvirt 3.2):

If you back a qcow2 file by a block device, then it's useful to know how
much of the block device you are actually using.  It's always been
possible to poll QEMU to ask, but it's more efficient to get an event.

QEMU added an event BLOCK_WRITE_THRESHOLD that fires when the block
device exceeds a watermark, but to _set_ the event, you have to register
a threshold that you are interested in by using the protocol
'node-name'.  (Hence why libvirt just learned how to reverse-engineer
node names - even if you set the node name for the format driver, it is
the node-name of the protocol driver that matt ers for the write
threshold.)

The QMP 'block-set-threshold' command is the one that sets the
threshold.

You're right that most interesting node operations are on the format
layer, not the protocol layer.

But it is also possible in the future that more throttling operations
will be done via a filter node (in other words, instead of just
format/protocol, we would now have forma t/filter/protocol nodes), and
that's also an interesting place where node names may prove useful.

One of the reasons that filtering should be its own node is that there
are cases where you want to filter low-level operations (the guest
cannot write more than X bytes/secon d, regardless of how many
additional bytes Y are written in metadata in parallel).

And sometimes high-level operations (I want to restrict my qcow2 image
to X bytes per second, even if that further restricts the guest to
X-overhead bytes per second) you'd express the first via
format/filter/protocol, the second via filter/format/protocol.
~
~
~
~