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

[Luiz Capitulino]

On Thu, 17 Nov 2011 19:09:10 +0200
Barak Azulay <address@hidden> wrote:

> On Wednesday 16 November 2011 22:24:51 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.  
> 
> 
> Not exactly what I meant, but the above is also a factor that needs to be 
> taken into account.

Maybe not, but I share Adam's impression.

> to be on the safe side I'll add:
> 
> 1 - true we want the ovirt-guest-agent to be widly adopted.
> 2 - we are willing to do major changes in it to fit all (let's discuss it in 
>     details)

We should be willing to make major changes in qemu-ga too. Actually, it
seems to me that the best way to handle most of what has been discussed
in this thread is to submit patches to qemu-ga and make it do what you
need it to do.

I don't see problems in having many different guest agents out there, as
long as they serve different purposes. If there's feature overlap, then let's
start adding what's missing to qemu-ga (of course we want to keep it kvm
centric though).

> 3 - one can not ignore the:
>     * maturity of the 2 components 
>     * capabilities

This is subjective, let's talk about concrete things.

>     when considering a convergence into a single agent

I don't think we should be considering choosing one or another agent,
at least not as a first step. That's why people are interpreting you
the wrong way.

IMHO, the first thing to do is to define what qemu's agent should provide,
and then check what's missing in qemu-ga and possibly implement it.

For what's worth, Adam's idea on API and making qemu-ga provide the basic
infrastructure seems quite reasonable to me.

> 
> 
> 
> 
> > 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).
> 
> 
> the ovirt-guest-agent functions well when the SSO if not installed, so no 
> need 
> to install it if one does not wish to enjoy it 
> 
> 
> > 
> > 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).
> 
> 
> This is what we have been doing for the last few years (with the entire ovirt 
> stack). so we are basing our approach on that experiance.
> In the session I gave I tried to touch the way we handle deployment of the 
> packages (both linux & windows guests), but it was a too large subject to 
> contain in that session.
> 
> deploying and  upgrading the agent was one of the issues handled.
> I can elaborate more on the isse if required. 
> 
> I'm not sure that the deployment/upgrade of guest agent should be done 
> through 
> the monitor, I think it should be left for a higher management layer. 
> 
> 
> > 
> > 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.
> 
> 
> I'm not sure this approach will pass common-criteria review.  
> 
> 
> > 
> > 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?
> 
> 
> When thinking on various guest OSs, I think the approach of a well defined 
> API 
> is much more appealing. The reason is that the implementation is contained 
> within the specific OS implementation of the guest-agent, and not left to a 
> person coding this from the high level management system.
> e.g. on the SSO example you gave all the coding of the seaquence of login 
> needs to be done on the management system and needs to first check what OS it 
> is and only than execute the relevant code  (which is much harder for error 
> handling in that situation), while when using a well defined interface all 
> you 
> need to do is call the "Login(<args>)" API.
> 
> 
> I agree that from development point of view the flexible approach of "I can 
> do 
> anything in the guest" is much more appiling, I don't think this is the case 
> for enterprise virtualization system that needs to manage thousands of VMs 
> with different OS types
> 
> Thanks
> Barak Azulay
> 
> 
> 
> 
> 
> 
>