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: 2938 bytes --]

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.

>>>
>>> The initial version of this series had an extra 'top' parameter to
>>> decide what image to stream data into. [...] That was later removed
>>> when we agreed that we could just reuse the 'device' parameter to
>>> refer to either a device or a node name.
>>>
>>> I don't think that introspection support would make a difference in
>>> this case, or am I missing anything?
>>
>> Hm, yes, probably not. But how would libvirt detect the feature then?
> 
> One possibility is to try to stream to an intermediate node and see if
> it fails.
> 
> Example: in a chain like [A] <- [B] <- [C], streaming to [B] using [A]
> as the 'base' parameter is a no-op (there's even a test for that in
> iotest 030).
> 
> If QEMU does support streaming to [B], the operation will succeed but do
> nothing. Otherwise the operation will fail with a DeviceNotFound error.
> 
> 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).

In general, if a feature addition doesn't change API, but merely
converts what was previously an error into something that works, then
libvirt is probably okay with just trying the feature, and reporting the
error message if it fails (assuming the qemu error message is sane).

-- 
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 --]