Re: [Qemu-block] [Qemu-devel] [PATCH v10 09/16] block: Add QMP support for streaming to an intermediate layer

[Kevin Wolf]

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