Re: [libvirt] Libvirt debug API

On 04/09/2010 10:27 AM, Daniel P. Berrange wrote: >> 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); > > > For an add-on library > > libvirt-qemu.so > > I don't think there's much to be gained from having an XML element to > turn on/off use of these APIs. If an app doesn't want to use them, it > can simply not link to libvirt-qemu.so The reason I wanted to do this was mostly for debug/support reasons. That is, with this element in place we can easily tell from the dumpxml output whether a person was using the "unreliable" API's, and thus we can tell them to try and reproduce without that in place.