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).