Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Mar 23, 2010 at 11:06:20AM -0500, Anthony Liguori wrote:
> On 03/23/2010 10:57 AM, Paul Brook wrote:
> >>>I think there is a serious divergence of approach there, instanciating
> >>>API stating 'we are gonna deprecate them sooner or later' tell the
> >>>application developper 'my time is more important than yours' and not
> >>>really something I like to carry to the API users.
> >>>The main goal of libvirt remains to provide APIs needed to unify the
> >>>development of the virtualization layers. Having APIs which makes
> >>>sense only for one or 2 virtualization engines is not a problem in
> >>>itself, it just raises questions about the actual semantic of that API.
> >>>If that semantic is sound, then I see no reason to not add it, really
> >>>and we actually often do.
> >>>       
> >>Yeah, but the problem we're facing is, I want there to be an API added
> >>to the management layer as part of the feature commit in qemu.  If there
> >>has to be a discussion and decisions about how to model the API, it's
> >>not going to be successful.
> >>     
> >I thought the monitor protocol *was* our API. If not, why not?
> 
> It is.  But our API is missing key components like guest enumeration.  
> So the fundamental topic here is, do we introduce these missing 
> components to allow people to build directly to our interface or do we 
> make use of the functionality that libvirt already provides if they can 
> plumb our API directly to users.

There's two levels of API here

 - VM level API - essentially APIs for the QMP protocol & qdev ARGV format

 - Host level API - guest enumeration, integration with other OS services
                    like cgroups, selinux, etc

QEMU has historically only cared about the per-VM level, but has not
actually provided any formal library APIs even for the monitor protocol
or command line syntax.

libvirt has obviously focused on the host level APIs, and directly figured
out the implicit VM level "API" that was exposed from QEMU. I think this is
a good split to maintain, because when you get to the host level API you 
start interacting / integrating beyond just QEMU with OS services like
cgroups, selinux, iptables, host networking, etc. QEMU might start with
a simple daemon for enumerating VMs....but that's how libvirt's QEMU driver
started off. Over time that "simple" demon would grow to end up doing all 
the things that libvirt currently does. This duplication of functionality
doesn't seem like a good use of development resources to me. 

Now libvirt does not currently directly expose the two VM level APIs that
QEMU has (qdev ARGV, and QMP protocol), which is where our feature timelag
comes from. If we can figure out a way to expose those two, then there 
shouldn't be a need for QEMU to get into duplicate host-level APIs like
enumeration.

There could still be useful APIs that QEMU can expose those. For example,
consider if QEMU provided 

 - libqmp.so - API(s) for each monitor command that serialized to/from JSON
               format string
 - libqdev.so - API(s) for constructing qdev strings, that can then be used
                as ARGV values, or QMP parameter values.

Next consider if libvirt provided a way to pass extra ARGV down to QEMU, 
and also provided a way to send/recv JSON commands/events.

The libqmp.so & libqdev.so could then be used both directly against a single
QEMU process spawned manually, but also indirectly via libvirt. eg, to use 
snapshots with libvirt, an app would use libqmp.so to generate a QMP command
for snapshotting, send it to the VM via the libvirt API for monitor injection
and get the response. The nice aspect of this is that libvirt is actually
adding value to libqmp.so, because users would now have secure remote
access to the QEMU monitor, tunnelled via libvirtd. It also avoids adding an
arbitrary number of extra APIs to libvirt - we just need the API to send
and recv JSON in libvirt, and libqmp.so can then be used ontop of that

In ascii art you'd end up with two models

Interacting with a single VM directly:

  Application   -> libqmp.so/libqdev.so -> QEMU

Interacting with many VMs via libvirt

  Application -------------> libvirt API ----> libvirtd ----> QEMU
      |                       ^
      |                       |
      +--------> libqmp.so ---+
      +--------> libqdev.so --+

So primarily an app would still use libvirt as the host level management
API, but libqmp.so proxied via libvirt would also allow access to arbitrary
extra features. This avoids the big overlap in functionality between libvirt
& QEMU apis, which would occurr if QEMU started doing multiple VM mgmt too.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|