Am 11.10.2016 um 16:30 hat Alberto Garcia geschrieben: > 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.
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... > 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'? I think that was the idea, though it was never used. If we had used it, I'm not sure how long the capabilities list would be today. :-) Kevin