Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent

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

On 01/17/2011 07:53 AM, Gerd Hoffmann wrote:
> Hi,
>
>> OVERVIEW:
>>
>> There are a wide range of use cases motivating the need for a guest
>> agent of some sort to extend the functionality/usability/control
>> offered by QEMU. Some examples include graceful guest shutdown/reboot
>> and notifications thereof, copy/paste syncing between host/guest,
>> guest statistics gathering, file access, etc.
>
> What is your plan to handle system-level queries+actions (such as
> reboot) vs. per-user stuff (such as cut+paste)?

This is an area that hasn't been well-defined yet and is definitely open 
for suggestions.

For host->guest RPCs the current plan is to always have the RPC executed 
at the system level, but for situations involving a specific user we 
fork and drop privileges with the RPC, and report back the status of the 
fork/exec. The fork'd process would then do what it needs to do, then if 
needed, communicate status back to the system-level daemon via some IPC 
mechanism (most likely a socket we listen to in addition to the serial 
channel) that can be used to send an event. The system-level daemon then 
communicates these events back to the host with a guest->host RPC.

Processes created independently of the system-level daemon could report 
events in the same manner, via this socket. I think this might suit the 
vdagent client model for Spice as well, things like resolutions changes 
and clipboard contents could be communicated as asynchronous events to 
virtagent via this socket, in place of a separate daemon, and virtagent 
could have RPCs that can route/translate host->guest calls to the 
user-level daemons.

Depending on the event, event-handling would either get consumed within 
virtagent, or punted to qemu's QMP event layer, which may need to be 
extended depending on the types of events we want to handle. The events 
would terminate within QEMU, but handlers could hook into external services.

So that's the rough plan, but would be happy to hear any other thoughts 
on how we might approach this.

>
> cheers,
> Gerd
>
>