From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RR3QD-00036x-GN for qemu-devel@nongnu.org; Thu, 17 Nov 2011 09:58:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RR3Q7-00081E-Sg for qemu-devel@nongnu.org; Thu, 17 Nov 2011 09:58:37 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:59879) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RR3Q7-00080x-L2 for qemu-devel@nongnu.org; Thu, 17 Nov 2011 09:58:31 -0500 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 17 Nov 2011 09:58:27 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAHEwOZj2166812 for ; Thu, 17 Nov 2011 09:58:24 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAHEwNn6005183 for ; Thu, 17 Nov 2011 09:58:23 -0500 Message-ID: <4EC52108.7040606@linux.vnet.ibm.com> Date: Thu, 17 Nov 2011 08:58:16 -0600 From: Michael Roth MIME-Version: 1.0 References: <78db1bdf-6440-4808-9658-19fe0e7043ea@zmail07.collab.prod.int.phx2.redhat.com> In-Reply-To: <78db1bdf-6440-4808-9658-19fe0e7043ea@zmail07.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=UTF-8; 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: Ayal Baron Cc: Barak Azulay , Gal Hammer , vdsm-devel@lists.fedorahosted.org, qemu-devel@nongnu.org, Adam Litke , arch@ovirt.org On 11/17/2011 02:46 AM, Ayal Baron wrote: > > > ----- Original Message ----- >> 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. > > What we're suggesting is let's drop *one* of the two agents (obviously it would be easier for us to drop qemu-ga, but we'd rather reach consensus and unite behind one agent regardless of which agent it is). > >> 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). > > I totally agree, but that could easily be resolved using the plugin architecture suggested before. > >> >> 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). > > Using plugins, you just deploy the ones you need, keeping the attack surface / #bugs / need to update lower But you still need to deploy those plugins somehow, so the logistics of distributing this code to multiple types/levels of guests remains, and plugins are insufficient to handle security fixes in the core code (however small that attack surface may be). Eventually you'll need a newer version of the guest agent installed. qemu-ga could be the vehicle for delivering those ovirt plugins/updates, and qemu-ga can upgrade itself to handle it's own security fixes/updates. With this model you can keep your agent functionality closely tied to the high-level management infrastructure, take liberties in what features/changes you need to add/make, and push-deploy those changes through qemu-ga. Low-level primitives to build high-level interfaces higher up the stack has always been a primary design goal so this all fits together fairly well from a QEMU perspective. The extra orchestration required is worth it, IMO, as the alternative is limiting customers to a particular distro, installing a similar backend, or shooting out emails to everyone asking them to update their guest agent so you can leverage feature X. > >> >> 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 > > The guest can run on any number of hosts. currently, the guest tools contain all the relevant logic installed (specifically for the guest os version). > What you're suggesting here is that we keep all the relevant guest-agent variants code on the host, automatically detect the guest os version and inject the correct file (e.g. SSO on winXP and on win2k8 is totally different). > In addition, there might be things requiring boot for example. So to solve that we would instead need to install a set of tools on the guest like we do the guest agent today (it would be a separate package because it's management specific). And then we would tell the guest-agent to run tools from that set? Sounds overly complex to me. > The nature of the tools is more an implementation detail. It could also be distributed the same way it is now, except with a CLI interface or something rather than via virtio-serial. Going even further, I posted another approach where ovirt-guest-agent just speaks to a local pipe, and qemu-ga execs ovirt-guest-agent and proxies RPCs via it's existing file-read/file-write interfaces. With a small amount work we could even provide an ovirt-exec command that automatically does the setup if required and takes "native" ovirt-guest-guest agent JSON requests/responses and nests them with a qemu-ga JSON request/response. So you get instant all the benefits of using the same transport as QMP, and QMP users get easy access to ovirt-guest-agent features. Not saying that's a better approach than deploying sets of scripts, but there's a lot of flexibility here with at least a couple that have virtually no negative impact to how extensible or consumable ovirt-guest-agent is at the high-level management level. >> >> 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? >> >> -- >> Adam Litke >> IBM Linux Technology Center >> >> _______________________________________________ >> Arch mailing list >> Arch@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch >> >