Re: [Qemu-devel] [Qemu-block] [PATCH v7 00/11] Support streaming to an intermediate layer

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]

[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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]