[Qemu-devel] converging around a single guest agent

[Michael Roth]

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<bazulay at 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.
>
> 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.

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.

>
>
>
>>
>> Alex
>>
>>> Barak
>>>
>>>> Alex
>