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

[Anthony Liguori]

On 03/25/2010 08:23 AM, Luiz Capitulino wrote:
> On Wed, 24 Mar 2010 16:40:18 -0500
> Anthony Liguori<anthony at codemonkey.ws>  wrote:
>
>    
>>>> We need to have a common management interface for third party tools.
>>>>
>>>>          
>>>    QMP? :-)
>>>        
>> Only if QMP is compatible with libvirt.  I don't want a user to have to
>> choose between QMP and libvirt.
>>      
>   Why not? If all they want is a simple qemu session, they can use
> QMP directly, on the other hand if what they want is more complex,
> what's the problem of using a management API like libivrt?
>    

My point is that libvirt should not be a separate management API but 
effectively an add-on API that provides higher level features, better 
integration with Linux host services, etc.
You mentioned dynamic dispatch, but this is useful only for C clients right?

>>> If so, what C clients you expected beyond libvirt?
>>>        
>> Users want a C API.  I don't agree that libvirt is the only C interface
>> consumer out there.
>>      
>   Actually, I do agree. Maybe, we don't have other C consumers because they
> weren't crazy enough to parse the crap of the user Monitor (or they do,
> but for simple things).
>
>   One possible future client is perf, for example.
>
>   Here is my solution (actually it's not mine, you have suggested
> it some time ago): let's provide a convenient way for C clients to
> use QMP. That is, let's have an overly simple library which takes
> QDitcs, sends them to qemu through QMP and returns others QDicts.
>
>   Something like the _sketch_ below:
>
> // Open a connection
> int qmp_open(..., QDict **greeting);
>
> // Register a callback for async messages, BUT note that the async message
> // object is passed verbatim
> void qmp_async_mes_handler(..., void (*async_mes_handler)(QDict *mes));
>
> // Send a QMP command
> int qmp_send(..., const char *command, QDict *params, QDict **res);
>    

Yes, this is the core API.  It's missing a mechanism to create a 
QMPContext.  I'll also argue that we want a set of auto generated 
wrappers like:

QError *qmp_last_error(QMPContext *context);
int qmp_set_link(QMPContext *context, const char *name, bool up);

That's a thin wrapper around qmp_send().  You can autogenerate this 
fairly easy with an IDL like:

None:qmp_set_link:String:name,Boolean:up

Which is fairly easy to output using introspection on a QMP session.

>   Obviously that we'll need a QMPContext and maybe additional functions,
>    

And for a QMPContext, we need functions like:

/* use qemu's default advertisement mechanism to find a guest */
QMPContext *qmp_context_new_by_uuid(uuid_t uuid);
QMPContext *qmp_context_new_by_name(const char *name);

/* connect to an already established QMP session */
QMPContext *qmp_context_new_by_fd(int fd);
QMPContext *qmp_context_new_by_iops(QMPIOOps *ops);

libvirt could use qmp_context_new_by_iops() to implement a 
virQemuGetQMP().  It can support this either by having a second QMP 
connection or even by parsing the QMP traffic and relaying commands over 
it QMP session (which gives it a chance to snoop on anything it's 
interested in).  I think the former approach is less difficult technically.

We can certainly make it easier to create dynamic QMP sessions.

> but the two main ideas are:
>
> 1. We don't do management
>    

I really believe we need to stop thinking this way.  I'm not saying that 
qemu-devel is the place where we design virt-manager, but we ought to 
consider the whole stack as part of "we".

>> I really think what we want is for a libvirt user to be able to call
>> libqemu functions directly.  There shouldn't have to be libvirt specific
>> functions for every operation we expose.
>>      
>   Not sure if this is too crazy but, considering this user wants to
> use qemu features not implemented by libvirt yet, what about using both
> libqmp (above) and libvirt at the same time?
>    

Yes, that's *exactly* what I want.  Except I want to call it libqemu 
because qmp is an implementation detail.

Regards,

Anthony Liguori