From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQgyX-0005F8-Gd for qemu-devel@nongnu.org; Wed, 16 Nov 2011 10:00:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQgyT-0005dV-1B for qemu-devel@nongnu.org; Wed, 16 Nov 2011 10:00:33 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:51053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQgyS-0005d7-Qv for qemu-devel@nongnu.org; Wed, 16 Nov 2011 10:00:28 -0500 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 Nov 2011 10:00:25 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAGExh81293380 for ; Wed, 16 Nov 2011 09:59:44 -0500 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAGExdk7010802 for ; Wed, 16 Nov 2011 07:59:39 -0700 Message-ID: <4EC3CFD7.7070504@linux.vnet.ibm.com> Date: Wed, 16 Nov 2011 08:59:35 -0600 From: Michael Roth MIME-Version: 1.0 References: <488c9fd7-8a5b-4f1c-a3bd-cb750f5769c4@zmail07.collab.prod.int.phx2.redhat.com> In-Reply-To: <488c9fd7-8a5b-4f1c-a3bd-cb750f5769c4@zmail07.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=UTF-8; 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: Ayal Baron Cc: Barak Azulay , Gal Hammer , vdsm-devel@lists.fedorahosted.org, qemu-devel@nongnu.org, Hans de Goede , arch@ovirt.org On 11/16/2011 02:16 AM, Ayal Baron wrote: > > > ----- Original Message ----- >> 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 > > 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 >> >