From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQeLb-0007Xs-VH for qemu-devel@nongnu.org; Wed, 16 Nov 2011 07:12:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQeLV-0003ZU-Hx for qemu-devel@nongnu.org; Wed, 16 Nov 2011 07:12:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQeLV-0003ZG-Al for qemu-devel@nongnu.org; Wed, 16 Nov 2011 07:12:05 -0500 From: Barak Azulay Date: Wed, 16 Nov 2011 14:13:20 +0200 References: <201111151924.41357.bazulay@redhat.com> <201111160905.23316.bazulay@redhat.com> <724C1350-38D1-4EE2-AC7B-27666B7710A1@suse.de> In-Reply-To: <724C1350-38D1-4EE2-AC7B-27666B7710A1@suse.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111161413.21026.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 10:16:57 Alexander Graf wrote: > On 16.11.2011, at 08:05, Barak Azulay wrote: > > 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. > > If we keep the protocol well-defined, we can get that for free. Just have > every command carry its own size and a request id shich the reply also > contains and suddenly you get asynchronous proxyable communication. > Sure we can keep commands synchronized in various ways the question is do we want that, there are a few down sides for that: 1 - VDSM will have to pass through 2 proxies (libvirt & qemu) in order to deliver a message to the guest, this byiself is not such a big disadvantage but will force us to handle much more corner-cases. 2 - looking at the qemu-ga functionality (read & write ...) do we really want to let a big chunk of data through both qemu & libvirt rather than directtly to the comsumer (VDSM) 3 - When events are fired from the guest agent, the delay of passing it through a double proxy will have it's latency penalty (as we have experianced in the client disconnect spice event) > > I envision the agent will have 2 separate ports to listen to, one to > > communicate to qemu and one for VDSM. > > Ugh, no, I'd much prefer a single 'bus' everyone attaches to. why? I'm thinking on situation we'll need to priorities commands arriving from qemu over "management standard commands" & info gathering, sure there are number of mechanisms to do that but it seems to me that a separation is the best way. e.g. I think we need to priorities a quiesce command from qemu over any other info/command from VDSM. > > Alex > > > Barak > > > >> Alex