From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55763) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQhUH-000359-QG for qemu-devel@nongnu.org; Wed, 16 Nov 2011 10:33:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQhUG-0003ib-Ar for qemu-devel@nongnu.org; Wed, 16 Nov 2011 10:33:21 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:33840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQhUG-0003f9-6N for qemu-devel@nongnu.org; Wed, 16 Nov 2011 10:33:20 -0500 Received: from /spool/local by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 Nov 2011 10:33:15 -0500 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAGFU7i5237862 for ; Wed, 16 Nov 2011 10:30:07 -0500 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAGFU0Tm019254 for ; Wed, 16 Nov 2011 08:30:00 -0700 Message-ID: <4EC3D690.2020609@linux.vnet.ibm.com> Date: Wed, 16 Nov 2011 09:28:16 -0600 From: Michael Roth MIME-Version: 1.0 References: <201111151924.41357.bazulay@redhat.com> <201111160905.23316.bazulay@redhat.com> <724C1350-38D1-4EE2-AC7B-27666B7710A1@suse.de> <201111161413.21026.bazulay@redhat.com> In-Reply-To: <201111161413.21026.bazulay@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: Barak Azulay Cc: Gal Hammer , "qemu-devel@nongnu.org" , "arch@ovirt.org" , Alexander Graf , "vdsm-devel@lists.fedorahosted.org" On 11/16/2011 06:13 AM, Barak Azulay wrote: > 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. Can't rule out the possibility of corner-cases resulting from this, but the practical way to look at it is VDSM will need handle libvirt/QMP protocols well. The implementation of the proxying mechanism is where the extra challenge comes into play, but this should be transparent to the protocols VDSM speaks. Implementation-wise, just to give you an idea of the work involved if we took this route: 1) ovirt-guest-agent would need to convert request/response payloads from/to QMP payloads on the guest-side, which are JSON and should, theoretically, mesh well with a python-based agent. 2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json, to describe the calls you're proxying. The existing infrastructure in QEMU will handle all the work of marshalling/unmarshalling responses back to the QMP client on the host-side. It's a bit of extra work, but the benefit is unifying the qemu/guest-level management interface into a single place that's easy for QMP/libvirt to consume. > 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) VDSM isn't the only consumer however, HMP/QMP and libvirt are consumers in and of themselves. > 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) > Getting them out of the guest is probably the biggest factor, delivering them between processes on the host is likely a small hit in comparison. > >>> 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. Do you mean prioritize in terms of order of delivery? Best way to do that is a single protocol with state-tracking, otherwise we're just racing. > > > >> >> Alex >> >>> Barak >>> >>>> Alex >