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

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

On Mon, Mar 22, 2010 at 04:49:21PM -0500, Anthony Liguori wrote:
> On 03/22/2010 03:10 PM, Daniel P. Berrange wrote:
> >>This isn't necessarily libvirt's problem if it's mission is to provide a
> >>common hypervisor API that covers the most commonly used features.
> >>     
> >That is more or less our current mission. If this mission leads to QEMU
> >creating a non-libvirt based API&  telling people to use that instead,
> >then I'd say libvirt's mission needs to change to avoid that scenario !
> >I strongly believe that libvirt's strategy is good for application
> >developers over the medium to long term. We need to figure out how to
> >get rid of the short term pain from the feature timelag, rather than
> >inventing a new library API for them to use.
> >   
> 
> Well that's certainly a good thing :-)
> 
> >>However, for qemu, we need an API that covers all of our features that
> >>people can develop against.  The ultimate question we need to figure out
> >>is, should we encourage our users to always use libvirt or should we
> >>build our own API for people (and libvirt) to consume.
> >>
> >>I don't think it's necessarily a big technical challenge for libvirt to
> >>support qemu more completely.  I think it amounts to introducing a
> >>series of virQemuXXXX APIs that implement qemu specific functions.  Over
> >>time, qemu specific APIs can be deprecated in favour of more generic
> >>virDomain APIs.
> >>     
> >Stepping back a bit first, there are the two core areas in which people can
> >be limited by libvirt currently.
> >
> >  1. Monitor commands
> >  2. Command line flags
> >
> >Ultimately, IIUC, you are suggesting we need to allow arbitrary passthrough
> >for both of these in libvirt.
> >
> >At the libvirt level, we have 3 core requirements
> >
> >  1. The XML format is extend only (new elements allowed, or add attributes
> >     or children to existing elements)
> >  2. The C library API is append only (new symbols only)
> >  3. The RPC wire protocol is append only (maps 1-1 to the C API generally)
> >   
> 
> We have a slightly different mentality within QEMU I think.  Here's 
> roughly how I'd characterize our guarantees.
> 
> 1. For any two versions of QEMU, we try to guarantee that the same VM, 
> as far as the guest sees it, can be created.
> 2. We tend to avoid changing command line syntax unless the syntax was 
> previously undefined.
> 3. QMP supports enumeration and feature negotiation.  This enables a 
> client to discover which functions are supported.
> 4. We try to maintain monitor interfaces but provide no guarantees of 
> compatibility.

Points 2 & 4 make it very hard for libvirt to use any library API
that QEMU might expose. We need to support multiple concurrently
running versions of QEMU on a host, to cope with the package upgrade
scenario & adhoc testing of new versions. If a libqemu.so for talking 
to QEMU changed a monitor interface & didn't have backwards compatability
for older QEMU version, then it is not something we could use, because 
any particular libvirt build would be tied to only being able to talk 
to the specific QEMU version. Currently we internally deal with changes 
in syntax detecting which format/protocol we need to use at runtime and
need to maintain that ability.

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 :|