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

[Michael Roth <mdroth@linux.vnet.ibm.com>]

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
va.close(remote_fd)

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.
>
> Regards,
>
> Anthony Liguori
>
>>
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>
>