From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50056 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pov4Q-0000nv-F5 for qemu-devel@nongnu.org; Mon, 14 Feb 2011 04:50:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pov4N-0000od-Ol for qemu-devel@nongnu.org; Mon, 14 Feb 2011 04:50:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pov4N-0000oB-CA for qemu-devel@nongnu.org; Mon, 14 Feb 2011 04:50:11 -0500 Message-ID: <4D58FAC7.8000407@redhat.com> Date: Mon, 14 Feb 2011 10:49:59 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent References: <1295270117-24760-1-git-send-email-mdroth@linux.vnet.ibm.com> <4D3449C5.1030006@redhat.com> <4D3457E2.8000603@linux.vnet.ibm.com> <4D359D8A.3000908@redhat.com> <4D359FED.6010209@linux.vnet.ibm.com> <4D46CA2D.5050807@linux.vnet.ibm.com> <4D4886B8.9070707@linux.vnet.ibm.com> In-Reply-To: <4D4886B8.9070707@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, markus_mueller@de.ibm.com, marcel.mittelstaedt@de.ibm.com, qemu-devel@nongnu.org, Jes.Sorensen@redhat.com, Anthony Liguori , ryanh@us.ibm.com, alevy@redhat.com, abeekhof@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.