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

[Adam Litke <agl@us.ibm.com>]

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?

-- 
Adam Litke <agl@us.ibm.com>
IBM Linux Technology Center