|
From: | Michael Roth |
Subject: | Re: [Qemu-devel] converging around a single guest agent |
Date: | Wed, 16 Nov 2011 09:28:16 -0600 |
User-agent: | Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 |
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.
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.
AlexBarakAlex
[Prev in Thread] | Current Thread | [Next in Thread] |