From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQz1Q-00060L-6E for qemu-devel@nongnu.org; Thu, 17 Nov 2011 05:16:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQz1P-00039q-0m for qemu-devel@nongnu.org; Thu, 17 Nov 2011 05:16:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQz1O-00039m-OC for qemu-devel@nongnu.org; Thu, 17 Nov 2011 05:16:42 -0500 Date: Thu, 17 Nov 2011 12:16:33 +0200 From: Alon Levy Message-ID: <20111117101633.GC12180@garlic.tlv.redhat.com> References: <4EC36C09.5060805@redhat.com> <20111116120722.GZ7140@garlic.redhat.com> <4EC3BEF2.9060805@codemonkey.ws> <4EC3F8FA.7010100@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC3F8FA.7010100@redhat.com> 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 Cc: Barak Azulay , Gal Hammer , vdsm-devel@lists.fedorahosted.org, qemu-devel@nongnu.org, Ayal Baron , arch@ovirt.org 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: > >>>> > >>> > >>> > >>> > >>>>>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. > > 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 >