From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41116 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pjux6-0001Y6-Sp for qemu-devel@nongnu.org; Mon, 31 Jan 2011 09:42:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pjux2-0005MY-AO for qemu-devel@nongnu.org; Mon, 31 Jan 2011 09:42:00 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:38878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pjux2-0005M4-7N for qemu-devel@nongnu.org; Mon, 31 Jan 2011 09:41:56 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0VEI1Jc009723 for ; Mon, 31 Jan 2011 09:18:05 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id DFA8C728045 for ; Mon, 31 Jan 2011 09:41:51 -0500 (EST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0VEfpUF195016 for ; Mon, 31 Jan 2011 09:41:51 -0500 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0VEfo2C004424 for ; Mon, 31 Jan 2011 07:41:51 -0700 Message-ID: <4D46CA2D.5050807@linux.vnet.ibm.com> Date: Mon, 31 Jan 2011 08:41:49 -0600 From: Michael Roth 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> In-Reply-To: <4D359FED.6010209@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: Anthony Liguori 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, ryanh@us.ibm.com, Gerd Hoffmann , abeekhof@redhat.com 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