|
From: | Michael Roth |
Subject: | Re: [Qemu-devel] converging around a single guest agent |
Date: | Thu, 17 Nov 2011 08:58:16 -0600 |
User-agent: | Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 |
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 "<exec-dir>/sso-package.bin" "w" file-write<fh> <buf> file-close<fh> file-open "<exec-dir>/sso-package.bin" "x" file-exec<fh> <args> file-close<fh>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 "<exec-dir>/sso/do-user-sso" "x" exec<fh> <args> file-close<fh> 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<address@hidden> IBM Linux Technology Center _______________________________________________ Arch mailing list address@hidden http://lists.ovirt.org/mailman/listinfo/arch
[Prev in Thread] | Current Thread | [Next in Thread] |