converging around a single guest agent

[Subhendu Ghosh]

On 11/15/2011 01:01 PM, Perry Myers wrote:
> 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

If you needed WMI enablement on Windows - could you support that with this arch?