[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] Support streaming to an intermediate layer

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 0/3] Support streaming to an intermediate layer
Date: Fri, 20 Feb 2015 15:49:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 02/20/2015 12:05 PM, Alberto Garcia wrote:
> On Fri, Feb 20, 2015 at 10:34:58AM -0700, Eric Blake wrote:
>>> I followed the proposed API from the wiki, which simply adds an
>>> additional 'top' parameter to block-stream specifying the image
>>> that data is written to:
>> How does one learn whether qemu is new enough to support this
>> mode? Until we add QMP introspection, learning whether an optional
>> parameter exists requires attempting the command and seeing a
>> different error depending on whether the argument is recognized.
> Isn't it possible to just check the QEMU version number?

Absolutely not.  Vendors are very likely to backport this to earlier
version numbers.  Feature probes are ALWAYS a better idea than version

> If not, what's the recommended way to do it?

Several design possibilities, but not all of them feasible at the moment.

1. implement QAPI introspection (we've been dreaming about this since
qemu 1.5 days), then the caller just queries to see if the version of
QMP has the optional 'top' parameter.

2. implement the new feature as a new command (then the existing
'query-commands' becomes an easy probe; but we have code duplication
with existing commands) (on the other hand, if we are going to frame
'stream' in terms of node operations instead of file name operations,
this may be the best idea after all)

3. guarantee that we have sane error messages for bogus commands used as
the probe. If {"execute":"block-stream",
"data":{"device":"no-such","top":"bogus"}} gives a reliable
DeviceNotFound error for qemu that supports optional 'top', and a
reliable GenericError about an unknown argument 'top' in older qemu,
then libvirt could use that as a poor-man's probe for the functionality
existing. (ugly, and only works if you can guarantee a difference in
error type between old and new qemu for a specific bogus command usage)
 Precedent: we do this sort of bogus command call on 'block-commit' to
learn if qemu is new enough to support active commit, and the comments
in the qemu code are explicit that a particular error message must not
be changed because libvirt depends on it.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]