[Qemu-devel] converging around a single guest agent

Alon Levy alevy at redhat.com
Wed Nov 16 12:07:22 UTC 2011


On Wed, Nov 16, 2011 at 08:53:45AM +0100, Hans de Goede wrote:
> 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
> 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)
> 
As long as we are collecting requirements, even if as Ayal said merging
spice requirements is not the OP's intent:

 5) Window management - Agent can set location of windows, report
 existing running applications and locations, get notified when a new
 window is created. For exposing individual applications, this is a
 future requirement.

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

> Regards,
> 
> Hans
> 



More information about the Arch mailing list