qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dor Laor
Subject: Re: [Qemu-devel] converging around a single guest agent
Date: Wed, 16 Nov 2011 15:45:12 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0

On 11/16/2011 02:07 PM, Alon Levy wrote:
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)

I suggest we'll have a single protocol and serialization means (JSON) plus a common framework that manages permissions within the guest. Beyond that, the agent should have various plugins for example the above spice related ones (could be also vnc ones) can be implemented as plugins that the ovirt agent will invoke.



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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]