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

[Alon Levy]

On Wed, Nov 16, 2011 at 08:59:35AM -0600, Michael Roth wrote:
> 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.
> 

I think for large opaque copies in/out to the guest, like image copy
paste, or guest<->guest copy paste (word OLE) it would be nice to
implemant a side channel scheme:
 message to allocate a channel
 message to deallocate a channel and signal successfull completion or
 error
 the channel is just another virtio-serial that is used for this
 communication only

The benefits would be:
 no need to slow down other operations
 no base64 conversion (both sides)

This of course means that this data is not being parsed by qemu, so it
can't benefit from any whitelisting / schema description. That's why it
should only be used for data that is undescribable - like the
aformentioned image/guest copy case (for instance for text copy it makes
possibly less sense - although again that's completely unstructured
text, so perhaps it makes sense as well).


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