From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQlK7-0001eA-8c for qemu-devel@nongnu.org; Wed, 16 Nov 2011 14:39:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQlK4-0005EL-ND for qemu-devel@nongnu.org; Wed, 16 Nov 2011 14:39:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57102) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQlK4-0005Ds-Fg for qemu-devel@nongnu.org; Wed, 16 Nov 2011 14:39:04 -0500 From: Barak Azulay Date: Wed, 16 Nov 2011 19:53:11 +0200 References: <201111151924.41357.bazulay@redhat.com> <201111161413.21026.bazulay@redhat.com> <4EC3D690.2020609@linux.vnet.ibm.com> In-Reply-To: <4EC3D690.2020609@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201111161953.12503.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: Michael Roth Cc: Gal Hammer , "qemu-devel@nongnu.org" , "arch@ovirt.org" , Alexander Graf , "vdsm-devel@lists.fedorahosted.org" On Wednesday 16 November 2011 17:28:16 Michael Roth wrote: > 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 sa= me > >>>>> 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/e= tc > >>>>> vs. ovirt-guest-agent's > >>>>> Shutdown/Available_Ram/etc: it's a policy decision rather than > >>>>> argument for choosing one project over another. > >>>>=20 > >>>> 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. > >>>=20 > >>> 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?). > >>>=20 > >>> There is a big advantage on direct communication (VDSM<-> agent), th= at > >>> way features can be added to the ovirt stack without the need to add = it > >>> to the qemu. > >>=20 > >> 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. > >=20 > > 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. >=20 > 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. >=20 > Implementation-wise, just to give you an idea of the work involved if we > took this route: >=20 > 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. ovirt-guest-agent already uses JSON for communication with VDSM=20 >=20 > 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. >=20 > 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. >=20 The issue is not whether it's possible or not or the amount of efforts need= to=20 be done for that to happen, either for qemu-ga or ovirt-guest-agent this wo= rk=20 needs to be done. the question is whether all comminication should go through the monitor (he= nce=20 double proxy) or ... only a subset of the commands that are closly related = to=20 hypervisor functionality and separate it from general management-system=20 related actions (e.g. ovirt or any other management system that wants to=20 communicate to the guest). > > 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) >=20 > VDSM isn't the only consumer however, HMP/QMP and libvirt are consumers > in and of themselves. This is not the claim it was just an example, it may as well be any other=20 management system. The question still remains, if we want to pass a big chunk of data, do we w= ant=20 it to be passed through this double proxy layer ? personally I think it doe= s=20 not belong to core hypervisor management interface. >=20 > > 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) >=20 > 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. >=20 =46rom our experiance in the last 3 years this latency (passing a single pr= oxy=20 layer, libvirt) , affected the overall functionality & behaviour. However=20 using libvirt as a monitor proxy also gave us some advantages, the question= is=20 what are the advantages of passing ALL guest-agent protocol through qemu ? > >>> I envision the agent will have 2 separate ports to listen to, one to > >>> communicate to qemu and one for VDSM. > >>=20 > >> Ugh, no, I'd much prefer a single 'bus' everyone attaches to. > >=20 > > why? > >=20 > > I'm thinking on situation we'll need to priorities commands arriving fr= om > > 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. > >=20 > > e.g. I think we need to priorities a quiesce command from qemu over any > > other info/command from VDSM. >=20 > 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 racin= g. >=20 > >> Alex > >>=20 > >>> Barak > >>>=20 > >>>> Alex