From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQrQS-0006QX-Bg for qemu-devel@nongnu.org; Wed, 16 Nov 2011 21:10:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQrQQ-0003HJ-Pr for qemu-devel@nongnu.org; Wed, 16 Nov 2011 21:10:04 -0500 Received: from e38.co.us.ibm.com ([32.97.110.159]:38321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQrQQ-0003Gd-CH for qemu-devel@nongnu.org; Wed, 16 Nov 2011 21:10:02 -0500 Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 Nov 2011 19:09:57 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAH29m7P145796 for ; Wed, 16 Nov 2011 19:09:48 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAH29lio011661 for ; Wed, 16 Nov 2011 19:09:47 -0700 Message-ID: <4EC46CEA.4030009@linux.vnet.ibm.com> Date: Wed, 16 Nov 2011 20:09:46 -0600 From: Michael Roth MIME-Version: 1.0 References: <201111151924.41357.bazulay@redhat.com> <20111116202451.GI2726@us.ibm.com> In-Reply-To: <20111116202451.GI2726@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] converging around a single guest agent List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Adam Litke Cc: Gal Hammer , Barak Azulay , arch@ovirt.org, qemu-devel@nongnu.org, vdsm-devel@lists.fedorahosted.org On 11/16/2011 02:24 PM, Adam Litke wrote: > I have been following this thread pretty closely and the one sentence summary of > the current argument is: ovirt-guest-agent is already featureful and tested, so > let's drop qemu-ga and have everyone adopt ovirt-guest-agent. Unfortunately, > this track strays completely away from the stated goal of convergence. I have > at least two examples of why the greater KVM community can never adopt > ovirt-guest-agent as-is. To address this, I would like to counter with an > example on how qemu-ga can enable the deployment of ovirt-guest-agent features > and satisfy the needs of the whole community at the same time. > > 1) Scope: The ovirt-guest-agent contains functionality that is incredibly > useful within the context of oVirt. Single Sign-on is very handy but KVM users > outside the scope of oVirt will not want this extra complexity in their agent. > For simplicity they will probably just write something small that does what they > need (and we have failed to provide a ubiquitous KVM agent). > > 1) Deployment complexity: The more complex the guest agent is, the more often it > will need to be updated (bug/security fixes, distro compatibility, new > features). Rolling out guest agent updates does not scale well in large > environments (especially when the guest and host administrators are not the same > person). > > For these reasons (and many others), I support having an agent with very basic > primitives that can be orchestrated by the host to provide needed functionality. > This agent would present a low-level, stable, extensible API that everyone can > use. Today qemu-ga supports the following verbs: sync ping info shutdown > file-open file-close file-read file-write file-seek file-flush fsfreeze-status > fsfreeze-freeze fsfreeze-thaw. If we add a generic execute mechanism, then the > agent can provide everything needed by oVirt to deploy SSO. > > Let's assume that we have already agreed on some sort of security policy for the > write-file and exec primitives. Consensus is possible on this issue but I > don't want to get bogged down with that here. > > With the above primitives, SSO could be deployed automatically to a guest with > the following sequence of commands: > > file-open "/sso-package.bin" "w" > file-write > file-close > file-open "/sso-package.bin" "x" > file-exec > file-close > > At this point, the package is installed. It can contain whatever existing logic > exists in the ovirt-guest-agent today. To perform a user login, we'll assume > that sso-package.bin contains an executable 'sso/do-user-sso': > > file-open "/sso/do-user-sso" "x" > exec > file-close > > At this point the user would be logged in as before. > > Obviously, this type of approach could be made easier by providing a well > designed exec API that returns command exit codes and (optionally) command > output. We could also formalize the install of additional components into some > sort of plugin interface. These are all relatively easy problems to solve. > > If we go in this direction, we would have a simple, general-purpose agent with > low-level primitives that everyone can use. We would also be able to easily > extend the agent based on the needs of individual deployments (not the least of > which is an oVirt environment). If certain plugins become popular enough, they > can always be promoted to first-order API calls in future versions of the API. > > What are your thoughts on this approach? > Another possibility, for functionality that may be more suited for a daemon that needs to maintain a lot of state, would be modifying the ovirt-guest-agent code to read/write to a (guest-local) named pipe. We can could then deploy the daemon via file-write+exec (assuming we provide a fork/detach flag), and the management tool could do request/response via file-write/file-read. It's almost equivalent to reading/writing directly to a virtio-serial channel, except there'd need to be a translation (base64decode(qmp_json_response.payload)->oga_json_response, and vice-versa) at the ovirt management layer. And we still reduce the deployment complexity since we can deploy/upgrade via a hypervisor push. There's actually so many ways this could be done with exec support... What's being lost in both approaches are ovirt-guest-agent-provided events, however. We'd either need to subsume those into qemu-ga, or provide a proxying mechanism on the guest-side for event reporting, which is something we've discussed in the past with the Spice folks with regard to support for session-level agents.