On Fri, 9 Apr 2010 15:27:17 +0100
"Daniel P. Berrange" <berrange@xxxxxxxxxx> 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?
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list