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. I envision the agent will have 2 separate ports to listen to, one to communicate to qemu and one for VDSM. Barak > > Alex
