On Mon 10 Oct 2016 09:09:25 PM CEST, Eric Blake wrote: >> # @job-id: #optional identifier for the newly-created block job. If >> # omitted, the device name will be used. (Since 2.7) >> # >> -# @device: the device name or node-name of a root node >> +# @device: the device or node name of the top image >> # >> # @base: #optional the common backing file name >> # >> -# @backing-file: #optional The backing file string to write into the active >> -# layer. This filename is not validated. >> +# @backing-file: #optional The backing file string to write into the top >> +# image. This filename is not validated. > > No change to the actual introspection. What's the easiest way for > libvirt to learn if the new style command will work, short of actually > trying it to see if it succeeds or fails? (That may be sufficient, > but the error message quality can often be improved in libvirt if it > is known up front if qemu is new enough rather than taking the 'try > and see' approach and getting stuck with qemu's error message)
I don't think there's any straightforward way. Some ideas: 1) Try to start a block-stream job that does nothing. When base == backing_bs(device) that's a no-op, but it fails if device is not the root node and intermediate block streaming is not supported. 2) We could add an extra parameter. For example 'base-node', which would be the same as 'base' but would take a node name instead of a file name. 3) QEMU could advertise that feature to the client. This is probably simpler than trying to figure it out from the API. I guess that's the idea of 'qmp_capabilities'? Berto