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