[Top][All Lists]

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

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

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1
Date: Tue, 08 Mar 2011 19:44:46 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

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

reply via email to

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