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

[Michael Roth]

On 01/18/2011 08:13 AM, Anthony Liguori wrote:
> On 01/18/2011 08:02 AM, Gerd Hoffmann wrote:
> > On 01/17/11 15:53, Michael Roth wrote:
> > > On 01/17/2011 07:53 AM, Gerd Hoffmann wrote:
> > > > 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.
> >
> > One option would be to have two virtio-serial channels, one for the
> > system and one for the user stuff. gdm could grant the desktop user
> > access to the user channel like it does with sound devices and simliar
> > stuff, so the user agent has access to it.
> >
> > Another option is to have some socket where the user agent can talk to
> > the system agent and have it relay the requests.
>
> I think this is the best approach. One requirement we've been working
> with is that all actions from guest agents are logged. This is to give
> an administrator confidence that the hypervisor isn't doing anything
> stupid. If you route all of the user traffic through a privileged
> daemon, you can log everything to syslog or an appropriate log file.

A brain-dump on how we're planning to do this. I tried to keep it 
concise, but that only went so far :)

We extend qemu-va, the virtagent guest agent, to be able to create a 
unix socket in the guest that listens for connections.

We also extend qemu-va so that it can run as a user-level daemon that 
can connect to the aforementioned socket.

  root: qemu-va -c virtio-serial -p 
/dev/virtio-ports/org.qemu.virtagent 
--user-socket=/var/run/virtagent.user.sock

  user: qemu-va -c unix-connect -p /var/run/virtagent.user.sock 
[--username=user] --user-daemon

The user-level daemon will drop priviledges to specified username if 
necessary, or run as the invoking user. User->daemon mappings will be 
determined by the system-level agent using getsockopt on new connections.

The user-level daemon operates in the same manner as the system-level 
daemon: it can execute RPCs in the host, and the host can execute RPCs 
it implements. This should theoretically make it capable of vdagent-like 
functionality by adding the appropriate host/guest-side RPCs. We would 
have to incorporate the X11 fd into the main select() for events and 
such, but that should be fairly straight-forward.

User-specific host->guest RPCs will add an http header, 
"X-Virtagent-Username", specifying the intended recipient. If that 
recipient has no associated running user-level daemon, an error will be 
returned by the system-level daemon. An RPC may be provided so the host 
can query the system-level agent for connected users.

User-generated guest->host RPCs will be routed directly to the host, 
with the same "X-Virtagent-Username" http header inserted by the 
system-level agent. The host will re-insert this header field in it's 
responses so the system-level agent can route the responses back to the 
user.

We will only allow one daemon per user at a time, and enforce this with 
a pid/lock file. If this is circumvented somehow (or we allow a 
user-specifiable pid file), a new connection specifying a user that's 
already been mapped to a user-level daemon will overwrite the existing 
mapping, and the old connection will be closed by the system-level 
daemon if it is still active.

Some caveats to consider however:

1) There may be user-level RPCs that are generally desirable...such as 
being able to execute a script as an unpriveledged user, or access a 
file in the same way. So it makes sense to invoke user-level agent 
startup with a login script. But for X-related things like Spice, an 
.xsession hook makes more sense. If we do both, the .xsession-spawned 
daemon will "take over", but any existing stateful interactions with 
that user will be effectively reset. This may be undesirable. One option 
is to XOpenDisplay() "on demand", rather than at startup. We won't know 
what $env{DISPLAY} is then, however, and there could be multiple 
displays for that user. I'm not sure if there's a reliable way to query 
such a thing, but assuming you can...we could implement stateful RPCs so 
establish a connection later: There could be multiple displays as well. 
My first inclination would be to have something like:

on host:
query_displays(user)
connect_display(user, display_name)
query_screens(user, display_name)
etc..

This requires either the host to poll for displays, or for the guest 
agent to do it and then notify the host, however. The only way I see 
around this is to only start the user-level daemon via .xsession or similar.

2) Pulling X11 dependencies into virtagent...I'm not sure how well this 
would go over. We may end up needing to move qemu-va into a seperate 
repo that pulls in deps from qemu.git

-Mike