[adding libvirt, to make sure I capture a design idea] On 06/18/2015 06:36 AM, Eric Blake wrote:

On 06/18/2015 06:07 AM, Alberto Garcia wrote:

...

On Thu 18 Jun 2015 01:47:20 PM CEST, Kevin Wolf wrote:

...

...

...

I believe our conclusion from an earlier version of the series was that we need QAPI introspection so that libvirt can detect the presence of the feature.

Detecting the presence of a feature allows libvirt the luxury of giving its own error message, rather than relying on the qemu message. But that's not to say libvirt HAS to use its own error message, and therefore being unable to detect the feature may not be the end of the world.

...

That said, I would prefer a way to detect the feature that does not involve testing commands for their error codes, but is there any? What does libvirt generally do in order to detect new features that don't depend on API changes?

But libvirt has not yet set up node name management (I'm about to revive Jeff's patch for auto-node-naming simultaneously with a libvirt patch series that proves that it helps libvirt), and libvirt will need a new API to allow users a way to request streams to an intermediate image. So anything libvirt does to interact with the new stream-to-intermediate will have to be new code, and I can worry about whether the qemu error message is good enough, or whether I have to contrive some probing test to see if it even works; but my initial thought is that merely probing to see if auto-node-naming is in place is a good approximation filter (if libvirt isn't managing its own node names, then the only way to use stream-to-intermediate is via a node name automatically supplied by qemu, especially nice if both features land in 2.4).

Actually, in thinking more about it, libvirt won't need a new API; the existing virDomainBlockPull() and virDomainBlockRebase() are sufficient, if I allow libvirt to treat "vda[1]" as a destination (which is the first backing image of disk vda; pretty much similar to how qemu is adding node names rather than device names as a way to make the existing block-stream now stream to intermediate). And that is consistent with the way we have been retrofitting other existing libvirt API to refer to specific backing images. On libvirt's front, I may want to add a new flag (where the flag must be present to make it clear that stream-to-intermediate is desired, so that upper level applications can use the absence of the libvirt flag as their feature probe), but that has no bearing on what qemu has to do to turn on the feature. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org