On 11/16/2011 02:16 AM, Ayal Baron wrote:
> ----- Original Message -----
>> On 11/15/2011 11:39 PM, Ayal Baron wrote:
>>>> If you want to talk about convergence, the discussion should start
>>>> collecting requirements. We can then figure out if the two sets
>>>> are strictly overlapping or if there are any requirements that are
>>>> in opposition.
>>> 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
>>> "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
>>> 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
>> 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
>> 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)
>> 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.
copy/paste was actually one of the initial use cases motivating qemu-ga;
it's just that the requirements (system+user-level agents) were so
different from the more pressing use cases of things like reliable
shutdown/reboot that it's been put off for now. At some point we had a
basic plan on how to approach it, but that needs to be re-assessed.
vdsm-devel mailing list