On 11/15/2011 04:39 PM, Ayal Baron wrote:
> ----- Original Message -----
>> On 11/15/2011 11:24 AM, Barak Azulay wrote:
>>> One of the breakout sessions during the ovirt workshop  was
>>> about the guest
>>> tools, and focused mainly on the ovirt-guest-agent .
>>> 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
>>> while 4 agents were mentioned (Matahari, vdagent, qemu-ga&
>>> 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
>>> - Communicates directly with qemu (not implemented yet)
>>> - Supports ?
>>> - So far linux only
>> But very easy to port. It also should work on just about any Unix
>> since its
>> only dependency is glib. Also:
>> - exists in the QEMU repository
>>> - written in C
>>> - 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
>>> - Written in python
>>> - Some VDI related sub components are written in C& C++
>>> - Supports a well defined list of message types / protocol 
>>> - Supports the folowing guest OSs
>>> Linux: RHEL5, RHEL6 F15, F16(soon)
>>> Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
>> The guest agent we use in QEMU exists to implement QEMU specific
>> I think one challenge that comes up here is that the ovirt guest
>> agent has a
>> very different scope than the QEMU agent. The ovirt guest agent has
>> a very
>> ovirt-engine centric scope.
>>> The need to converge is obvious, and now that ovirt-guest-agent is
>>> under the ovirt stack, and since it already produces value for
>>> installations, and is cross platform, I offer to join hands around
>>> guest-agent and formalize a single code base that will serve us
>> You are basically saying, stop what you guys are doing and work on
>> our code
>> because it's better. That's not really convergence.
>> If you want to talk about convergence, the discussion should start
>> collecting requirements. We can then figure out if the two sets of
>> are strictly overlapping or if there are any requirements that are
>> in opposition.
> So vdsm guest agent goal is to ease administration of VMs. This is not
> saying much as it is quite broad so I will list what is provided today and
> some things we need to add:
Is there a spec for the guest agent protocol?
What's the current policy on compatibility? How does the guest agent protocol
handle feature negotiation?
vdsm-devel mailing list