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

Anthony Liguori anthony at codemonkey.ws
Thu Apr 22 18:49:31 UTC 2010

On 04/12/2010 10:20 AM, Luiz Capitulino wrote:
> On Fri, 9 Apr 2010 15:27:17 +0100
> "Daniel P. Berrange"<berrange at 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.

We need to make libvirt and qemu smarter.

We already face this problem today with multiple libvirt users.  This is 
why sophisticated management mechanisms (like LDAP) have mechanisms to 
do transactions or at least a series of atomic operations.


Anthony Liguori

>   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?

More information about the libvir-list mailing list