Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/08/2011 11:44 AM, Avi Kivity wrote:
>>
>> I'm not sure I see this as all that critical though.  I sort of like 
>> the idea of it being transparent to the client whether a guest agent 
>> implements a command or QEMU does.
>
> A qemu command is guaranteed to be executed faithfully, modulo bugs 
> and runtime errors.  A guest command is guaranteed to be executed (or 
> not) in the most hostile way possible to the management agent.  It's 
> important to make that clear in the ABI.
>
> We should also have separate schemas, one including the other.  So we 
> can have a monitor channel that only executes guest commands, for 
> instance.

I need to think about about this a little more.  Since libqmp would hide 
most of this, the user-visible details wouldn't really change.  So while 
I understand and agree with your point, I don't think just changing the 
protocol like this is going to achieve the goal.

>>> In addition to commands we may also implement a key-value store.  A 
>>> large number of commands may be easy to implement using a single 
>>> key/value, and it's also easy to live migrate (key/values being 
>>> stored in but not understood by qemu).
>>
>> Do you mean the guest querying QEMU for key-values?  QMP doesn't have 
>> a reverse direction RPC.  It only has events which is one of the 
>> things that makes live migration work nicely.
>
> Both the guest and the management agent (and both can listen for 
> events).  I don't see why guest->qemu RPC is problematic for migration 
> - at least when qemu terminates it.

If it's terminated in QEMU, it's fine, but then it's not QMP anymore.  
Let me think about whether there's a way to achieve this without a 
guest->qemu RPC.

Regards,

Anthony Liguori