[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