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

Daniel P. Berrange berrange at redhat.com
Mon Apr 12 14:18:00 UTC 2010

On Mon, Apr 12, 2010 at 09:56:50AM -0400, Chris Lalancette wrote:
> On 04/12/2010 08:41 AM, Daniel P. Berrange wrote:
> >>> 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. 
> The problem with logging a message is that it is easy to lose it.  What I'm
> trying to avoid here is debugging somebody's setup for hours only to find
> out that they did a "pci_del" behind libvirt's back.  Maybe we can just make the
> <monitorpassthrough/> a read-only flag; it is ignored in the parsing, but
> it is set by "GetXMLDesc" when it detects that the virDomainQemuInvokeMonitor
> has been called.

If the logging message is at level 'WARN' it will be included in syslog
for libvirtd by default, which is basic support  data always collected.
The guest XML is a description of the guest configuration, which is not 
a place for ad-hoc flags related to API usage.

|: 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 :|

More information about the libvir-list mailing list