qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] KVM call minutes for 2013-04-23


From: Eric Blake
Subject: Re: [Qemu-devel] KVM call minutes for 2013-04-23
Date: Tue, 23 Apr 2013 10:06:41 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5

On 04/23/2013 08:45 AM, Juan Quintela wrote:
> 
> * 1.5 pending patches (paolo)
>   anthony thinks nothing big is outstanding
>   rdma: not probably for this release,  too big change on migration
>   cpu-hotplug: andreas expect to get it for 1.5
> 
> 
> * What can libvirt expect in 1.5 for introspection of command-line support?
>   command extensions?  libvirt want then
> * What are the rules for adding optional parameters to existing QMP
>   commands?  Would it help if we had introspection of QMP commands?
>   what are the options that each command support.
> 
>   command line could work for 1.5
>     if we got patches on the next 2 days we can get it.

Goal is to provide a QMP command that provides JSON representation of
command line options; I will help review whatever is posted to make sure
we like the interface.  Anthony agreed the implementation should be
relatively straightforward and okay to add after soft freeze (but must
be before hard freeze).  Libvirt has some code that would like to make
use of the new command-line introspection; Osier will probably be the
first libvirt developer taking advantage of it - if we can swing it,
we'd like libvirt 1.0.5 to use the new command (libvirt freezes this
weekend for a May 2 release).

>   rest of introspection need 1.6
>     it is "challenging"
>     we are interesting into feature introspection
>     and comand extensions?
>     one command to return the schema?

Anthony was okay with the idea of a full JSON introspection of all QMP
commands, but it is probably too big to squeeze into 1.5 timeframe.
Furthermore, while the command will be useful, we should always be
thinking about API - having to parse through JSON to see if a feature is
present is not always the nicest interface; when adding a new feature,
consider improving an existing query-* or adding a counterpart new
query-* command that makes it much easier to tell if a feature is
available, without having to resort to a QMP introspection.

>   if we change a command,  how we change the interface without
>   changing the c-api?

c-api is not yet a strong consideration (but see [1] below).  Also,
there may be ways to design a C api that is robust to extensions (but
that means designing it into the QMP up front when adding a new
command); there has been some list traffic on this thought.

More importantly, adding an optional parameter to an existing command is
not okay unless something else is also available to tell whether the
feature is usable - QMP introspection would solve this, but is not
necessarily the most elegant way.  For now, while adding QMP
introspection is a good idea, we still want case-by-case review of any
command extensions.

> 
>   we can change "drive_mirror" to use a new command to see if there
>   are the new features.

drive-mirror changed in 1.4 to add optional buf-size parameter; right
now, libvirt is forced to limit itself to 1.3 interface (no buf-size or
granularity) because there is no introspection and no query-* command
that witnesses that the feature is present.  Idea was that we need to
add a new query-drive-mirror-capabilities (name subject to bikeshedding)
command into 1.5 that would let libvirt know that buf-size/granularity
is usable (done right, it would also prevent the situation of buf-size
being a write-only interface where it is set when starting the mirror
but can not be queried later to see what size is in use).

Unclear whether anyone was signing up to tackle the addition of a query
command counterpart for drive-mirror in time for 1.5.

> 
>   if we have a stable c-api we can do test cases that work. 

Having such a testsuite would make a stable C API more important.

> 
> Eric will complete this with his undrestanding from libvirt point of
> view.

Also under discussion: the existing QMP 'screendump' command is not
ideal (not extensible, doesn't allow fd passing, hard-coded output
format).  This was used as an example command that should not be
extended until we have appropriate feature detection in place; probably
easier to add a new QMP command than to add parameters to the existing
one.  At any rate, we're late enough that 'screendump' probably won't be
improved in 1.5, so we have the full 1.6 cycle to get it right.

Not on the phone call, but a recent mail that is related to the topic -
feature detection of whether dump-guest-memory supports paging:
https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg04613.html

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