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
> 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
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.
vdsm-devel mailing list