On Thu, 25 Mar 2010 08:55:42 -0500 Anthony Liguori <anthony@codemonkey.ws> wrote:
On 03/25/2010 08:23 AM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 16:40:18 -0500 Anthony Liguori<anthony@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.
Okay, I fully agree here.
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:
Having the wrappers is one of the points we disagree, but as we have agreed on starting with the core only, I don't see why keep arguing here. If, in the near feature, the need of having wrappers become evident I'll be all for it (this statement is a bit dangerous though, as this need can be subjective). [...]
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".
Depends, if you mean that we should be involved with libvirt development, than I completely agree. On the other hand, if you mean than qemu should provide its own management API, than I tend to disagree. And I think this is a very important point of the whole discussion, if you think this way I guess we should start a new thread to collect feedback, listing pros and cons.
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.
libqemu is fine.