[Top][All Lists]

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

[Qemu-devel] Re: [RFC][PATCH v7 00/16] virtagent: host/guest communicati

From: Michael Roth
Subject: [Qemu-devel] Re: [RFC][PATCH v7 00/16] virtagent: host/guest communication agent
Date: Mon, 07 Mar 2011 18:11:21 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20101207 Thunderbird/3.1.7

On 03/07/2011 04:56 PM, Anthony Liguori wrote:
On 03/07/2011 04:49 PM, Michael Roth wrote:
It's not really inventing anything. We've always started off with
qobject params, which we then pulled apart and stuck into xmlrpc
params, which when then turned into xml for transport. Now we just
take the qobjects and covert them to json directly. We've only cut out
an intermediate library and switched to a different UTF8-based
encoding for transport.

With QAPI we'd have the extra step of pulling function parameters into
a qobjects. Not any different from what the situation would've been
using xmlrpc or any of the other binary encoding that were considered.

It does look more similar to what QMP/QAPI is doing than previously,
but it doesn't need to be all or nothing.

I think I have a Clever Idea here but hacking together a prototype.

Basic thinking is to make guest commands part of the QMP namespace such
that a guest command looks like any other QMP command. The only role
QEMU plays in this model is validating the commands inputs and outputs
and then passing the command to the guest agent.

Hmm...this does sound nice. But keep in mind that not all parameters passed in via QMP were intended solely for the guest. That just happens to be the case for the RPCs we have implemented in this RFC.

For instance, one of QMP commands we intended to add for the new getfile implementation, to address concerns over a hardcoded file size limit while avoiding large memory allocations on the host or guest, was chunked file transfer using a set of stateful RPCs, with a higher level QMP command to wrap them:

qmp.getfile <local file> <remote file>

Where <local file> could be a normal file, or "-" for direct output to monitor. Internally, the set of actual RPCs being executed are much lower level. Something like:

offset = 0
local_fd = open(<local file>)
remote_fd = va.open(<remote file>)
while (((read_count, buf) = va.read(remote_fd, offset, 512*1024)) > 0):
  write(local_fd, buf, read_count)
  offset += read_count

Any higher-level commands of this type would be still doable, but would need to be pushed all the way up to the management stack, or done programatically, so it does limit what can be done within an interactive shell. Some might argue that's for the best, but there may be more of a trade-off in other possible use cases.

Stay tuned.


Anthony Liguori


Anthony Liguori

reply via email to

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