Re: [Qemu-devel] converging around a single guest agent

[Michael Roth <mdroth@linux.vnet.ibm.com>]

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 "<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>
>
> 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?
>

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.