converging around a single guest agent

[Perry Myers]

On 11/15/2011 12:24 PM, Barak Azulay wrote:
> Hi,
> 
> One of the breakout sessions during the ovirt workshop [1] was about the guest 
> tools, and focused mainly on the ovirt-guest-agent [2]. 
> 
> One of the issues discussed there, was the various existing guest agents out 
> there, and the need to converge the efforts to a single agent that will serve 
> all. 
> 
> while 4 agents were mentioned (Matahari, vdagent, qemu-ga & ovirt-guest-agent) 
> during that discussion, we narrowed it down to 2 candidates:  
> 
> qemu-ga (aka virt-agent):
> -------------------------
> - Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest 
> I/O)
> - Communicates directly with qemu  (not implemented yet) 
> - Supports ? 
> - So far linux only
> - written in C
> 
> Ovirt-guest-agent:
> ------------------
> - Has been around for a long time (~5 years) - considered stable
> - Started as rhevm specific but evolved a lot since then
> - Currently the only fully functional guest agent available for ovirt
> - Written in python 
> - Some VDI related sub components are written in C & C++
> - Supports a well defined list of message types / protocol [3]
> - Supports the folowing guest OSs
>   Linux: RHEL5, RHEL6 F15, F16(soon) 
>   Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
> 
>   
> The need to converge is obvious, and now that ovirt-guest-agent is opensourced 
> under the ovirt stack, and since it already produces value for enterprise 
> installations, and is cross platform, I offer to join hands around ovirt-
> guest-agent and formalize a single code base that will serve us all.
> 
> git @ git://gerrit.ovirt.org/ovirt-guest-agent
> 
> Thoughts ?

+1

The only downside that I concretely heard from folks re:
ovirt-guest-agent was that it is written in Python.  Two thoughts there:

1. On Windows it is compiled to an executable, so no separate python
   stack needed

2. ovirt-guest-agent is not very large and does not bring in a lot
   (any?) additional python class dependencies above/beyond the core
   language and interpreter.  Given this, the chances of dealing with
   python stack issues are probably minimal and also the overhead of
   including _just_ the base python interpreter in a given guest OS is
   very lightweight.  Core python RPM in F16 is about 80k.

Perry