qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] converging around a single guest agent


From: Subhendu Ghosh
Subject: Re: [Qemu-devel] converging around a single guest agent
Date: Tue, 15 Nov 2011 13:08:32 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1 Thunderbird/3.1.16

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]