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

[Anthony Liguori]

On 03/23/2010 01:07 PM, Daniel P. Berrange wrote:
> 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.
>    

We also provide an API for guest creation (the qemu command line).  When 
we create a guest, we don't integrate with things like cgroups and 
selinux and we probably never will.  This is a place where libvirt adds 
value.

The fundamental problem we have is that once you create a qemu instance, 
you cannot find it from a third party tool.  That's a problem we ought 
to solve and I'd like to see that be common across qemu and libvirt.  I 
don't see that as us growing our scope into libvirt's space.

I think libvirt does two things.  It provides a generic interface to 
hypervisors and if people write to this interface, they get better 
portability and the ability to management many platforms.  It also 
provides a certain amount of host services management that can include 
things not directly related to qemu (like network management) and 
services that further connect qemu to host services (like selinux 
labelling).

What I would like to see is that a user can write to the libvirt API and 
then call out to qemu specific functions when necessary.  I'd also like 
a user be able to interact directly with qemu without using the libvirt 
generic API.  The user should be able to still see the VMs and 
ultimately interact with them through libvirt.  The user should be able 
to use libvirt to deal with host services too (like storage and network 
pools).

The key is not to have two mutual exclusive management mechanisms but a 
set of complementary APIs.  The biggest obstacle I see is libvirt's 
remote management interface.  I think it's addressable though.  For 
instance, if libqemu.so provided a QMP IO interface, libvirt-qemu could 
basically provide an interface to create that context and otherwise have 
users use the libqemu.so interfaces directly.

IOW, libqemu.so would provide interfaces that looked like:

QMPContext *qemu_connect_by_name(const char *name);
int qemu_pci_add(QMPContext *ctxt, ...);

And libvirt would provide interfaces that looked like:

virQemuPtr *virDomainGetQemuPtr(virDomainPtr *ptr);
QMPContext *virQemuCreateQMPContext(virQemuPtr *ptr);

With respect to keep tracking of which operations are done through qemu, 
we should discuss the technical challenges of this and figure out how we 
can solve them.

> The libqmp.so&  libqdev.so could then be used both directly against a single
> QEMU process spawned manually, but also indirectly via libvirt.

That's not quite what I'm looking for because then it's really two 
separate interfaces.  I'd rather see complementary interfaces much like 
how Cairo integrates with GTK/GDK or even how GDK integrates with X11.

Regards,

Anthony Liguori