Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 08:23 AM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 16:40:18 -0500
Anthony Liguori<anthony(a)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