converging around a single guest agent

[Ayal Baron]

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

Assistance in VM life-cycle:
"desktopShutdown" - Shuts the VM down gracefully from within the guest.
"quiesce" - does not exist today.  This is definitely a requirement for us.

SSO support for spice sessions (automatically login into guest OS using provided credentials):
"desktopLock" - lock current session, used when spice session gets disconnected / before giving a new user access to spice session
"desktopLogin"
"desktopLogoff"
In addition, guest reports relevant info (currently active user, session state)

Monitoring and inventory:
currently agent sends info periodically, which includes a lot of info which should probably be broken down and served upon request. Info includes - 
- memory usage
- NICs info (name, hw, inet, inet6)
- appslist (list of installed apps / rpms)
- OS type
- guest hostname
- internal file systems info (path, fs type, total space, used space)

Personally I think the above should become more generic and support user defined counters (using WMI or collectd in the guest to collect the info and passing it via the guest agent), but that might be a different discussion.


>From qemu wiki, the following info about qemu guest agent:

It's purpose: "Implement support for QMP commands and events that terminate and originate respectively within the guest using an agent built as part of QEMU. "
- ties it directly to qemu, but not to specific functionality.  ovirt guest agent definitely would need to support this

In general, I would say ovirt-guest-agent is scoped to do everything the qemu-guest-agent is and then some, so there is definitely a lot of overlap.


> 
> Regards,
> 
> Anthony Liguori
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>