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

[Michael Roth]

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