[Qemu-devel] converging around a single guest agent

[Ayal Baron]

----- Original Message -----
> Hi,
> 
> On 11/15/2011 11:39 PM, Ayal Baron wrote:
> >
> 
> <snip>
> 
> >> 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)
> >
> 
> <snip>
> 
> If we're gathering requirements and trying to come up with one agent
> to rule them all, don't forget

I don't think we're trying to come up with one agent to rule them all, just avoid duplication of efforts if most of what the 2 agents are doing overlaps.
I think we can safely say that seeing as oVirt is KVM centric, ovirt-guest-agent wants to leverage qemu/kvm to the fullest which aligns with what qemu-guest-agent is doing.
However, ovirt-guest-agent is required to do a lot more, so we need to see if and how we resolve this.

> about VDI and the Spice agent. Currently the spice agent handles the
> following:
> 
> 1) Paravirtual mouse (needed to get mouse coordinates right with
> multi monitor setups)
> 2) Send client monitor configuration, so that the guest os can adjust
> its resolution
>     (and number and place of monitors) to match the client
> 3) Copy and paste in a platform neutral manner, if anyone wishes to
> add this to another agent
>     please, please contact us (me) first. This is easy to get wrong
>     (we went through 2 revisions
>     of the protocol for this).
> 4) Allow the client to request the guest to tone down the bling (for
> low spec clients)
> 
> Notes:
> 1) All of these are client <-> guest communication, rather then the
> host <-> guest communication
> which the other agents seem to focus on.
> 
> 2) Getting copy paste right requires a system level guest agent
> process as well as a per user
> session agent process.

Neither qemu-guest-agent nor ovirt-guest-agent is aligned with doing any of the above, so I'm not sure there is any justification in uniting the spice agent with the rest.

> 
> Regards,
> 
> Hans
>