[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [libvirt] Libvirt debug API
From: |
Daniel P. Berrange |
Subject: |
[Qemu-devel] Re: [libvirt] Libvirt debug API |
Date: |
Mon, 12 Apr 2010 13:41:10 +0100 |
User-agent: |
Mutt/1.4.1i |
On Fri, Apr 09, 2010 at 02:16:06PM -0400, Chris Lalancette wrote:
> 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.
That doesn't tell you whether they have actually used any API or not.
It is also inconvenient if you start a guest without it, and only later
realize you want to use the extra APIs. If we want to track the actual
usage, then the first time a direct monitor command is issued, we should
simply log a warning message.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
- [Qemu-devel] Libvirt debug API, Chris Lalancette, 2010/04/09
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Jamie Lokier, 2010/04/09
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Richard W.M. Jones, 2010/04/11
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Jamie Lokier, 2010/04/11
- Message not available
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, Jamie Lokier, 2010/04/12
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, Daniel P. Berrange, 2010/04/12
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, Anthony Liguori, 2010/04/22