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

[Alexander Graf]

On 22.03.2010, at 22:49, Anthony Liguori wrote:

> On 03/22/2010 03:10 PM, Daniel P. Berrange wrote:
>> 
>>   
>>> 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?
>>>     
>> Adding yet another library in the stack isn't really going to solve the
>> problem from the POV of libvirt users, but rather fork the community
>> effort which I imagine we'd all rather avoid. Having to tell people to
>> switch to a different library API to get access to a specific feature
>> is a short term win, but with a significant long term cost/burden. This
>> means we really do need to figure out how to better/fully support QEMU's
>> features in libvirt, removing the feature timelag pain.
>>   
> 
> I think what we need to do is find a way to more tightly integrate the QEMU 
> and libvirt communities in such a way that when a patch was submitted against 
> QEMU adding a new feature, we could ask that that feature was implemented in 
> libvirt.  I see two ways to do this.
> 
> One would be for libvirt to have a libvirt.so and libvirt-qemu.so.  The QEMU 
> community would have to be much more heavily involved in libvirt-qemu.so and 
> it probably suggests that libvirt-qemu.so should follow our release cycle.  
> libvirt would have to support using either libvirt.so or libvirt-qemu.so for 
> it's users.
> 
> The alternative would be for the QEMU community to produce a libqemu.so and 
> for libvirt.so to consume libqemu.so.  The libvirt community ought to be 
> heavily engaged in the development of libqemu.so and certainly, shared 
> maintainership would be appropriate.  A user using libvirt.so should see 
> guests created with either libqemu.so or libvirt.so although libqemu.so would 
> provide weaker long term compatibility guarantees (but more features).

I don't see why we shouldn't be able to automatically generate libqemu.so. We 
have the *.hx files that describe the syntax of parameters plus list all 
available options / commands. I'm not sure how exactly QMP works, but having a 
generic QMP command to list all available options would be handy too.

By then we could automate most of the library, making the glueing really easy. 
If libvirt doesn't properly link against libqemu anymore we also know why: The 
ABI changed.

All that's needed then is a common Qemu object that libvirt users can get 
access to as well. That object is the magic key to all libqemu functions. If 
users need functionality not exposed in libvirt, they can then use libqemu 
calls directly. If they don't care about all the awesomeness of libvirt and 
don't want to be hypervisor agnostic, they can stick to libqemu completely.


Alex