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
