Re: [Qemu-devel] converging around a single guest agent

[Barak Azulay <bazulay@redhat.com>]

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