converging around a single guest agent

[Perry Myers]

On 11/15/2011 01:08 PM, Subhendu Ghosh wrote:
> 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?

I'm not a WMI expert, but google search first result on 'python WMI'
turned up:

http://timgolden.me.uk/python/wmi/index.html