Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
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?
Again, one important point of the this discussion is: what interfaces
should qemu provide and how/when should qemu rely on libvirt?
IMO, we should rely on libvirt for a management interface for all the
reasons that have already been exposed: it has a established community,
it provides a well tested and stable API, it does VM management, it
integrates with several other services like cgroups, SELinux, etc.
Now, regarding qemu:
> 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);
Obviously that we'll need a QMPContext and maybe additional functions,
but the two main ideas are:
1. We don't do management
2. QMP is our standard interface
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?