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. > > 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. Alex > > Barak > >> >> Alex
