Hi,
On 11/16/2011 02:47 PM, Anthony Liguori wrote:
On 11/16/2011 06:07 AM, 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)
I thought there was wide agreement that pv mouse should be extracted from the
guest agent into its own driver.
Yes AFAIK there is, but no-one has done that yet. I was merely listening what
the spice
agent is doing today, hopefully tomorrow
2) Send client monitor configuration, so that the guest os can adjust its
resolution
(and number and place of monitors) to match the client
I also wonder if this should be part of QXL?
That is not really practically since this is something between the client and
the guest,
where as the QXL device does communication between the hypervisor (qemu) and
the guest.
Also there is a 1 head per QXL device relation, so that would mean that a
single qxl dev
needs to be aware of other QXL devices in order to communicate the relative
position of
its head to the other heads.
Regards,
Hans
