[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<agl at us.ibm.com>
>> IBM Linux Technology Center
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>