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

[Avi Kivity]

On 03/08/2011 05:03 PM, Anthony Liguori wrote:
> > We may want to use a different way of separating the namespaces - 
> > enacapsulation:
> >
> > {
> >   'command': 'guest-command',
> >    arguments: {
> >      'command': 'read-file',
> >      'arguments': {
> >          'path': '/var/log/messages'
> >      }
> >   }
> > }
> >
> > This serves to decouple the two protocols, which may have different 
> > support lifetimes (hopefully not).
>
>
> We could also have a more proper namespace in the protocol.  Like:
>
> { 'execute': { 'namespace': 'guest', 'command': 'read-file' }, 
> 'arguments': { 'path': '/var/log/messages' } }

Yeah, looks better.

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

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

--
error compiling committee.c: too many arguments to function