On Thu, Nov 24, 2011 at 02:40:07PM +0200, Dor Laor wrote:
On 11/17/2011 09:58 PM, Michael Roth wrote:
On 11/17/2011 10:34 AM, Barak Azulay wrote:
On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
I've tried to summarize the pros/cons, points, and proposals outlined in
this thread at the following wiki:
http://www.ovirt.org/wiki/Guest_agent_proposals
Please feel free to add/edit as needed. If you don't have an account on
ovirt.org let me know.
Thanks Michael, it's a good start.
A few questions about the qemu-ga's requirements:
#1
- same repo ? why is this a requirement ?
Or git submodule. Main reasons are that integration with QMP requires
that qemu be able to generate marshaling code from a guest agent schema
definition of commands/parameters, and that qemu needs to be able to
consume guest agent extensions internally. A few examples that came up
in this thread were opening new virtio-serial channel via agent calls,
and registering device callbacks/driving state machine changes for guest
agent events. Since we'd like to pursue a push-deployment model where
QEMU can deploy a specific, compatible version of the agent to a
bootstrapped guest (qemu-ga pre-installed via guest distro or ISO
package), having code changes in-sync with repo would be necessary.
VMware has a similar model for handling guest tools upgrades, where the
hypervisor pushes upgrades based on host hypervisor level:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008907
The alternative is strict APIs with backward-compatibility with
down-level agents, which complicates things tremendously on the QEMU
side, and pretty much everywhere in the stack. Just keeping libvirt in
sync with QMP has proven difficult and that's just on the host, with a
common distro and fairly close development communities. Extending this
kind of synchronization out to multiple guest distros with varying
levels of guest agents makes this far harder.
Using QMP is an advantage, I agree.
However it can be used by another option - move the QMP schema out
of qemu.git so all projects like libvirt, agents, vdsm, etc will be
able to consume it directly.
This way, adding a new (agent) command will immediately propagate to
all of the stack instead of each component to implement it
differently (while it would still be possible).
That's what libguestfs scheme do today.
That kind of idea doesn't really help much in practice, because it is
presuming that the API you want to expose is identical at every level
in the stack. If that were really the case, then you wouldn't really
have different levels in the stack in the first place. An API exposed
at the libvirt level may well map to multiple API calls at the QEMU
level, and and API call at the VDSM level may map to multiple API
calls at the libvirt level, etc.
libguestfs is doing something different here - they have one API and
they are exposed that API, at the same level of granularity in other
languages. That is very different from stacking APIs with different
levels of abstraction. When you're stacking APIs you cannot avoid the
fact that you need to create a design that is suitable for the level
of abstraction you need at each layer.