[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: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1
Date: Tue, 08 Mar 2011 13:19:16 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

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.


Anthony Liguori

reply via email to

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