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

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On 11/16/2011 02:16 AM, Ayal Baron wrote:
>
>
> ----- 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.
>

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.

>>
>> Regards,
>>
>> Hans
>>
>