Re: [Qemu-devel] wiki summary

[Daniel P. Berrange]

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|