[Qemu-devel] converging around a single guest agent

[Alexander Graf]

On 16.11.2011, at 08:05, Barak Azulay <bazulay at 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