On Wed, 24 Mar 2010 16:40:18 -0500 Anthony Liguori <anthony@xxxxxxxxxxxxx> 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? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list