On Wednesday 16 November 2011 10:16:57 Alexander Graf wrote: > On 16.11.2011, at 08:05, Barak Azulay <bazu...@redhat.com> 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