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

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/23/2010 09:51 AM, Daniel Veillard wrote:
> On Mon, Mar 22, 2010 at 02:25:00PM -0500, Anthony Liguori wrote:
>    
>> Hi,
>>      
>    Hi Anthony,
>
>    
>> I've mentioned this to a few folks already but I wanted to start a
>> proper thread.
>>
>> We're struggling in qemu with usability and one area that concerns
>> me is the disparity in features that are supported by qemu vs what's
>> implemented in libvirt.
>>      
>    If you could come up with a list, then I would have an easier job
> answering, honnestly I have the feeling we spent the last 6 months
> filling that gap in a really fast way.
>    

qemu-doc.texi is a list of most of the command line features we 
support.  The help output of the monitor shows what we support in that 
interface.  It doesn't take a lot to read through it and see the things 
not supported by libvirt.  libvirt supports a relatively small amount of 
our overall features (although a good chunk of the most common set).

>> 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.
>>      
> But one point of libvirt is that once an API is there we don't break it.
>
> 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.

Supporting legacy APIs forever is not a viable option for a project like 
qemu.  Things evolve quickly and we need a mechanism to deprecate APIs 
over time.

>> What's the feeling about this from the libvirt side of things?  Is
>> there interest in support hypervisor specific interfaces should we
>> be looking to provide our own management interface for libvirt to
>> consume?
>>      
>    The real question is what do you actually want to build.
>    

Any management application really.  Even with something like 
virt-manager, there's a ton of useful features that qemu supports (like 
migration status reporting) that libvirt doesn't support.

> Most of the feedback I have seen in this thread so far are mostly
> request to be able to hack on a qemu instance launched via libvirt.
>    

It's not about the "hacker" use-case.  It's about making sure that we've 
got 100% feature coverage in our management API.  All of the management 
tools that focus on KVM have had this problem that I am aware of.

We need to come up with a way that we can very easily plumb new qemu 
functions through the management interface.

Regards,

Anthony Liguori