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
