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