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

On Fri, 9 Apr 2010 15:27:17 +0100 "Daniel P. Berrange"<berrange(a)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?