On 04/12/2010 10:20 AM, Luiz Capitulino wrote:
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.
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.
Regards,
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?
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list