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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Fri, 9 Apr 2010 15:27:17 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
> > Hello,
> >      In response to a lot of the talk of qemud lately on qemu-devel, the
> > libvirt community would like to put forward a proposal to help enable
> > debug/advanced options when using various hypervisors.  The goals of
> > this API are:
> > 
> > 1)  To enable more rapid access to hypervisor features before proper
> > libvirt API's are designed around them.
> > 2)  To facilitate debugging and access to advanced features that may
> > not fit into the normal libvirt world-view.
> > 
> > Caveats:
> > 1)  Unlike other libvirt API's, this one will explicitly *not* be
> > guaranteed ABI/API compatible between libvirt updates.
> 
> I think we'd still aim to keep the public API stable. The bit that we
> can't guarentee is the interactions with QEMU & the libvirt driver. 
> eg, if someone was using the API to send text monitor commands to
> QEMU, and the next libvirt release switched to JSON mode, that use
> would break. The API would still be valid, but the way they use it
> might not be. Similarly if they add some custom extra command line
> argument, this could potentially conflict with an extra command line
> arg a subsquent libvirt release used. eg, they used -device to add
> a PCI card with a specific PCI address. Then next libvirt release
> specifies this same PCI address and then you get a clash.

 Another problem is issuing Monitor commands that could confuse libvirt's
real API. Say, adding a device libvirt doesn't know about or stopping the VM
while libvirt thinks it's still running or anything like that.

 When I suggested the monitor passthrough idea, I thought it could be a
workaround for the feature time lag problem, but as stated by Avi, I'm
afraid that this can potentially cause more problems than it solves.

 It's very desirable for debugging (item 2 above) and maybe to try new
things, but people couldn't use it for anything serious, which is the
major issue in this subject (item 1 above).

 Now, Anthony's idea of having libqemu has the same issues, which seems
to mean that the only way to really fix the time lag is to fix the
time lag :)

> > Raw access to the qemu monitor will be disabled by default; the
> > <monitorpassthrough/> tag enables the ability to send QMP (or
> > text, if you are using older qemu) messages straight through to the
> > monitor.  To do this there will be an additional API entry point
> > named virDomainDebugCommand() which takes an arbitrary string
> > and passes it to the monitor, and returns an arbitrary string as
> > a result.  Thus you could pass in either "info cpus" if using the
> > text monitor or '{ "execute": "query-cpus" }' if using QMP.
> 
> Again the idea of a 'virDomainDebugCommand' API is QEMU specific, with
> other hypervisors have different approaches for low level extension/
> debug. For example, Xen would involve XenStore access, or XenD XMLRPC,
> etc. So this should really live in a separate API namespace which is
> specific to a hypervisor. For example, as a header file
> 
>   #include <libvirt/libvirt-qemu.h>
> 
> Containing APIs like
> 
>   int virDomainQEMUInvokeMonitor(virDomainPtr dom,
>                                  const char *command,
>                                  char **reply);
> 
>   typedef virConnectQEMUDomainEventCallback(virConnectPtr conn,
>                                             virDomainPtr dom, 
>                                             const char *eventname,
>                                             const char *data,
>                                             void *opaque)
>   int virConnectQEMUDomainEventRegister(virConnectPtr conn,
>                                         virDomainPtr dom,
>                                         const char *eventname,
>                                         virDomainQEMUMonitorCallback cb,
>                                         void *opaque);

 What about all the wonders of json? This will force clients to
have their own json <-> text converter, maybe we could provide two
APIs, just like qemu driver works internally?