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

[Ayal Baron]

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

> 
> 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.

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