From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQZXW-0000nf-5L for qemu-devel@nongnu.org; Wed, 16 Nov 2011 02:04:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQZXU-0002BR-Vt for qemu-devel@nongnu.org; Wed, 16 Nov 2011 02:04:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5760) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQZXU-0002BD-Mk for qemu-devel@nongnu.org; Wed, 16 Nov 2011 02:04:08 -0500 From: Barak Azulay Date: Wed, 16 Nov 2011 09:05:22 +0200 References: <201111151924.41357.bazulay@redhat.com> <4EC2EF2C.7010100@linux.vnet.ibm.com> <2954A154-7DB5-4F82-82C0-88289606B76A@suse.de> In-Reply-To: <2954A154-7DB5-4F82-82C0-88289606B76A@suse.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111160905.23316.bazulay@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: Alexander Graf Cc: Gal Hammer , vdsm-devel@lists.fedorahosted.org, arch@ovirt.org, Michael Roth , qemu-devel@nongnu.org On Wednesday 16 November 2011 02:42:30 Alexander Graf wrote: > On 16.11.2011, at 00:01, Michael Roth wrote: > > But practically-speaking, it's unavoidable that qemu-specific management > > tooling will need to communicate with qemu (via QMP/libqmp/HMP/etc, or > > by proxy via libvirt). It's through those same channels that the qemu-ga > > interfaces will ultimately be exposed, so the problem of qemu-ga vs. > > ovirt-guest-agent isn't really any different than the problem of QMP's > > system_powerdown/info_balloon/etc vs. ovirt-guest-agent's > > Shutdown/Available_Ram/etc: it's a policy decision rather than argument > > for choosing one project over another. > > I don't see why we shouldn't be able to just proxy whatever communication > happens between the guest agent and the management tool through qemu. At > that point qemu could talk to the guest agent just as well as the > management tool and everyone's happy. I'm not sure proxying all the requests to the guset through qemu is desirable, other than having single point of management, most of the calls will be pass throgh and has no interest to qemu (MITM?). There is a big advantage on direct communication (VDSM <-> agent), that way features can be added to the ovirt stack without the need to add it to the qemu. I envision the agent will have 2 separate ports to listen to, one to communicate to qemu and one for VDSM. Barak > > Alex