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<bazu...@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.
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.
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.
> 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.
> 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.
>>> 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.
> 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.
Do you mean prioritize in terms of order of delivery? Best way to do
that is a single protocol with state-tracking, otherwise we're just racing.
vdsm-devel mailing list