On 11/16/2011 02:24 PM, Adam Litke wrote:
> I have been following this thread pretty closely and the one sentence summary
> the current argument is: ovirt-guest-agent is already featureful and tested,
> 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
> 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
> need (and we have failed to provide a ubiquitous KVM agent).
> 1) Deployment complexity: The more complex the guest agent is, the more often
> 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
> 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
> 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
> 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
> 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-open "<exec-dir>/sso-package.bin" "x"
> file-exec<fh> <args>
> At this point, the package is installed. It can contain whatever existing
> 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>
> 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
> 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
> which is an oVirt environment). If certain plugins become popular enough,
> 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
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.
vdsm-devel mailing list