On 11/15/2011 04:39 PM, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> On 11/15/2011 11:24 AM, 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
>>
>> 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
>>>
>>> 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 guest agent we use in QEMU exists to implement QEMU specific
>> functionality.
>>    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
>>> 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.
>>
>> 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
>> around
>> collecting requirements.  We can then figure out if the two sets of
>> requirements
>> are strictly overlapping or if there are any requirements that are
>> fundamentally
>> in opposition.
>
> Agreed.
>
> 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?

Regards,

Anthony Liguori
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to