On Wednesday 16 November 2011 17:28:16 Michael Roth wrote:
On 11/16/2011 06:13 AM, Barak Azulay wrote:
On Wednesday 16 November 2011 10:16:57 Alexander Graf wrote:
On 16.11.2011, at 08:05, Barak Azulay<address@hidden> 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.
Can't rule out the possibility of corner-cases resulting from this, but
the practical way to look at it is VDSM will need handle libvirt/QMP
protocols well. The implementation of the proxying mechanism is where
the extra challenge comes into play, but this should be transparent to
the protocols VDSM speaks.
Implementation-wise, just to give you an idea of the work involved if we
took this route:
1) ovirt-guest-agent would need to convert request/response payloads
from/to QMP payloads on the guest-side, which are JSON and should,
theoretically, mesh well with a python-based agent.
ovirt-guest-agent already uses JSON for communication with VDSM
2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json,
to describe the calls you're proxying. The existing infrastructure in
QEMU will handle all the work of marshalling/unmarshalling responses
back to the QMP client on the host-side.
It's a bit of extra work, but the benefit is unifying the
qemu/guest-level management interface into a single place that's easy
for QMP/libvirt to consume.
The issue is not whether it's possible or not or the amount of efforts need to
be done for that to happen, either for qemu-ga or ovirt-guest-agent this work
needs to be done.
the question is whether all comminication should go through the monitor (hence
double proxy) or ... only a subset of the commands that are closly related to
hypervisor functionality and separate it from general management-system
related actions (e.g. ovirt or any other management system that wants to
communicate to the guest).
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)
VDSM isn't the only consumer however, HMP/QMP and libvirt are consumers
in and of themselves.
This is not the claim it was just an example, it may as well be any other
management system.
The question still remains, if we want to pass a big chunk of data, do we want
it to be passed through this double proxy layer ? personally I think it does
not belong to core hypervisor management interface.
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)
Getting them out of the guest is probably the biggest factor, delivering
them between processes on the host is likely a small hit in comparison.
From our experiance in the last 3 years this latency (passing a single proxy
layer, libvirt) , affected the overall functionality& behaviour. However
using libvirt as a monitor proxy also gave us some advantages, the question is
what are the advantages of passing ALL guest-agent protocol through qemu ?