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

[Michael Roth <mdroth@linux.vnet.ibm.com>]

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)

Won't be implemented until we finish the QMP conversion to QAPI since 
that's a prereq to implementing a QMP server with proper async support 
(needed for communication with a potentially non-responsive guest 
agent). But once it's in guest extensions are completely transparent to 
QMP/libvirt, which is highly desirable from a management perspective 
since you're coding against a single API/transport.

> - Supports ?

Documented in qemu.git/qapi-schema.json:

mdroth@illuin:~/w/qemu.git$ grep command qapi-schema-guest.json
# Such clients should also preceed this command
{ 'command': 'guest-sync'
{ 'command': 'guest-ping' }
{ 'command': 'guest-info',
{ 'command': 'guest-shutdown', 'data': { '*mode': 'str' } }
{ 'command': 'guest-file-open',
{ 'command': 'guest-file-close',
{ 'command': 'guest-file-read',
{ 'command': 'guest-file-write',
{ 'command': 'guest-file-seek',
{ 'command': 'guest-file-flush',
{ 'command': 'guest-fsfreeze-status',
{ 'command': 'guest-fsfreeze-freeze',
{ 'command': 'guest-fsfreeze-thaw',

There's a wiki page with additional details:

> - So far linux only

Windows port is *almost* there. I have patches to build/run it on 
windows but there are some remaining bugs, and guest-fsfreeze* and 
guest-shutdown* are gonna need windows-specific command implementations.

> - 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)
>

In terms of completeness/support for ovirt (and node/cluster-level 
management frameworks in general), the ovirt-guest-agent certainly seems 
like a win. The main problem with convergence within the qemu space is 
that we can't have guest extensions to qemu-driven guest events like, 
say, hotplug or shutdown be managed by an external agent: the 
functionality, specificity, and assurances required are not things that 
are necessarily suited for ovirt-guest-agent; the scope is very different.

And the same holds true in the other direction: I don't, personally at 
least, foresee qemu-ga ever doing things like providing a list of logged 
in users on a system or handling SSO, though if there are those who'd 
like to take qemu-ga in that direction I think that's fine.

But practically-speaking, it's unavoidable that qemu-specific management 
tooling will need to communicate with qemu (via QMP/libqmp/HMP/etc, or 
by proxy via libvirt). It's through those same channels that the qemu-ga 
interfaces will ultimately be exposed, so the problem of qemu-ga vs. 
ovirt-guest-agent isn't really any different than the problem of QMP's 
system_powerdown/info_balloon/etc vs. ovirt-guest-agent's 
Shutdown/Available_Ram/etc: it's a policy decision rather than argument 
for choosing one project over another.

>
> 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 ?
>
> Thanks
> Barak Azulay
>
> [1] http://www.ovirt.org/news-and-events/workshop
> [2] http://www.ovirt.org/wiki/File:Ovirt-guest-agent.odp
> [3] http://www.ovirt.org/wiki/Ovirt_guest_agent
>