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

[Gerd Hoffmann <kraxel@redhat.com>]

   Hi,

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

[ ... ]

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

I usually login via gdm, login and X session are not separate then.

>> 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 would make the user-agent just run without using X11 in case $DISPLAY 
is unset and be done with it.  I would also try hard to avoid adding any 
X11-specific stuff into the protocol.  The protocol for cut+paste and 
the other gui stuff should work equally well for non-linux guests 
(windows, macos?) and (when it hits mainstream some day) wayland.

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

Start via .xsession is the way to go IMHO.

> I'd like to move forward with this approach, but with the goal here
> being that we have one agent to rule them all, I'd like to know whether
> those of you involved with the spice vdagent work think this is a
> reasonable approach.

spice allows a single user-level agent today and also does only 
gui-stuff, so that approach works fine for us.

> Can spice do anything useful with more than 1 display per user?

multihead (one virtual desktop on multiple physical displays) yes.
Truely separate displays (aka separate X sessions) no.

I doubt running two X xessions on two displays on a single machine is a 
use case we need to worry about.  There where approaches to do that with 
physical machines, so you can have two people share one computer by 
hooking two displays, two keyboards and two mice.  It wasn't very 
successful.  And with virtual machines this doesn't make sense at all IMHO.

cheers,
   Gerd

PS: sorry for the delay, was sick for two weeks.