Re: [Qemu-devel] Re: [libvirt] Libvirt debug API

[Avi Kivity]

On 04/23/2010 09:29 PM, Anthony Liguori wrote:
> > Maybe.  We'll still have issues.  For example, sVirt: if a QMP 
> > command names a labeled resource, the non-libvirt user will have no 
> > way of knowing how to label it.
>
>
> This is orthogonal to QMP and has to do strictly with how libvirt 
> prepares a resource for qemu.


It's not orthogonal.  If you allow qmp access behind libvirt's back, 
it's a problem that you will have.

> > Much better to exact a commitment from libvirt to track all QMP (and 
> > command line) capabilities.  Instead of adding cleverness to QMP, add 
> > APIs to libvirt.
>
> Let's step back for a minute because I think we're missing the forest 
> through the trees.
>
> We're trying to address a few distinct problems:
>
> 1) Allow libvirt users to access features of qemu that are not exposed 
> through libvirt

That's an artificial problem.  If libvirt exposes all features, you 
don't need to solve it.

> 2) Provide a means for non-libvirt users to interact with qemu

We have qmp.  It doesn't do multiple guest management.  I think it's 
reasonable to have a qemud which does (and also does sVirt and the 
zillion other things libvirt does) provided we remove them from libvirt 
(long term).  The only problem is that it's a lot of effort.

> 3) Provide a unified and interoperable view of the world for 
> non-libvirt and libvirt users

This problem can be solved by the non-libvirt users adopting libvirt, or 
the libvirt users dropping libvirt.  I don't understand why we need to 
add interoperability between users who choose an interoperability 
library and users who don't choose an interoperability library.

> For (1), we all agree that the best case scenario would be for libvirt 
> to support every qemu feature.  I think we can also all agree though 
> that this is not really practical and certainly not practical for 
> developers since there is a development cost associated with libvirt 
> support (to model an API appropriately).

All except me, perhaps.

We already have two layers of feature modeling: first, we mostly emulate 
real life, not invent new features.  PCI hotplug existed long before 
qemu had support for it.  Second, we do give some thought into how we 
expose it through QMP.  libvirt doesn't have to invent it again, it only 
has to expose it through its lovely xml and C APIs.

> The new API proposed addresses (1) by allowing a user to drill down to 
> the QMP context.  It's a good solution IMHO and I think we all agree 
> that there's an inherent risk to this that users will have to evaluate 
> on a case-by-case basis.  It's a good stop-gap though.

Agree.

> (2) is largely addressed by QMP and a config file.  I'd like to see a 
> nice C library, but I think a lot of other folks are happy with JSON 
> support in higher level languages.

I agree with them.  C is a pretty bad choice for managing qemu (or even, 
C is a pretty bad choice).

> (3) is the place where there are still potential challenges.  I think 
> at the very least, our goal should be to enable conversion from (2) 
> and (1) to be as easy as possible.  That's why I have proposed 
> implementing a C library for the JSON transport because we could plumb 
> that through the new libvirt API.  This would allow a user to very 
> quickly port an application from QMP to libvirt.  In order to do this, 
> we need the libvirt API to expose a dedicated monitor because we'll 
> need to be able to manipulate events and negotiate features.

Most likely any application that talks QMP will hide the protocol behind 
a function call interface anyway.

> Beyond simple porting, there's a secondary question of having 
> non-libvirt apps co-exist with libvirt apps.  I think it's a good long 
> term goal, but I don't think we should worry too much about it now.

libvirt needs to either support all but the most esoteric use cases, or 
to get out of the way completely.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.