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

[Anthony Liguori <aliguori@us.ibm.com>]

On 03/07/2011 06:11 PM, Michael Roth wrote:
> 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:

Just as HMP commands can be implemented in terms of QMP commands, QMP 
commands can be implemented in terms of QMP commands.

Regards,

Anthony Liguori

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