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
