From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQfpx-000893-4M for qemu-devel@nongnu.org; Wed, 16 Nov 2011 08:47:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQfpw-0006w0-0C for qemu-devel@nongnu.org; Wed, 16 Nov 2011 08:47:37 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:55597) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQfpv-0006vw-TO for qemu-devel@nongnu.org; Wed, 16 Nov 2011 08:47:35 -0500 Received: by iakk32 with SMTP id k32so654627iak.4 for ; Wed, 16 Nov 2011 05:47:35 -0800 (PST) Message-ID: <4EC3BEF2.9060805@codemonkey.ws> Date: Wed, 16 Nov 2011 07:47:30 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4EC36C09.5060805@redhat.com> <20111116120722.GZ7140@garlic.redhat.com> In-Reply-To: <20111116120722.GZ7140@garlic.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] converging around a single guest agent List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede , Ayal Baron , Barak Azulay , Gal Hammer , qemu-devel@nongnu.org, vdsm-devel@lists.fedorahosted.org, arch@ovirt.org 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: >>> >> >> >> >>>> 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) >>> >> >> >> >> 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. >> 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? Regards, Anthony Liguori >> 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) >> > As long as we are collecting requirements, even if as Ayal said merging > spice requirements is not the OP's intent: > > 5) Window management - Agent can set location of windows, report > existing running applications and locations, get notified when a new > window is created. For exposing individual applications, this is a > future requirement. > >> 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. >> > >> Regards, >> >> Hans >> >