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
