qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: KVM call agenda for May 18


From: Markus Armbruster
Subject: Re: [Qemu-devel] Re: KVM call agenda for May 18
Date: Tue, 18 May 2010 17:44:40 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

"Daniel P. Berrange" <address@hidden> writes:

> On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
>> On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
>> >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
>> >   
>> >>On 05/17/2010 10:23 PM, Chris Wright wrote:
>> >>     
>> >>>Please send in any agenda items you are interested in covering.
>> >>>
>> >>>If we have a lack of agenda items I'll cancel the week's call.
>> >>>
>> >>>       
>> >>- Slipping 0.13 release out to July 1st.
>> >>     
>> >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
>> >existing monitor commands converted to QMP?
>> 
>> No.  I don't think our goal is to ever fully convert monitor commands to 
>> QMP.  Some commands simply don't make sense as QMP commands (like x and xp).
>
> We're a really long way from a complete conversion even  ignoring 
> commands which don't make sense in QMP. The current state almost 
> covers the commands libvirt currently uses, but there's much more 
> beyond that.
>
>> Is there a set of commands that you think need to be converted that 
>> currently aren't?
>
> Notable outstanding commands that libvirt has a non-negligable
> chance of wanting to use in the not too distant future
>
>  - blockdev_add/del (to replace drive_add/del)

Working on it.  It's hairy.

>  - commit/delvm/loadvm/savevm

Luiz posted an RFC patch.  It's hairy.

>  - screendump

Haven't looked into it.

>  - set_link

Patch posted weeks ago, still not merged.

>  - mouse_{move,button,set}
>  - sendkey
>  - acl_{add,remove,policy,reset,show}
>  - boot_set
>  - watchdog_action

Same as screendump.

> The full list of unconverted commands though is much long:
[...]
> I don't think we can claim all those are irrelevant for QMP.
>
> So are we still targetting complete conversion of relevant commands
> for 0.13, or is it just going to be a stepping stone where declare 
> QMP stable, but known to be incomplete for coverage of commands ?

Completeness and stability are mostly orthogonal.  If we get the
fundamentals right, we can add missing stuff without destabilizing
existing stuff.  To get them right, we need to cover enough material to
develop our understanding of the problems, and to enable real use.
Until libvirt can use QMP, we fail on "real use".



reply via email to

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