qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alon Levy
Subject: Re: [Qemu-devel] converging around a single guest agent
Date: Thu, 17 Nov 2011 12:16:33 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Nov 16, 2011 at 06:55:06PM +0100, Hans de Goede wrote:
> 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.

We do want to allow multiple heads on a single qxl device, since it
would make RandR work.

This only relates to the second point, Hans first point is still valid.
> 
> Regards,
> 
> Hans
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]