[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [libvirt] [PATCH] libxl: open libxl log stream with libvirtd log_level
On Wed, Nov 11, 2015 at 04:04:22PM +0000, Daniel P. Berrange wrote: > On Wed, Nov 11, 2015 at 04:57:59PM +0100, Marek Marczykowski-GÃrecki wrote: > > On Tue, Sep 15, 2015 at 11:21:00AM -0600, Jim Fehlig wrote: > > > Daniel P. Berrange wrote: > > > > On Tue, Sep 15, 2015 at 10:57:50AM -0600, Jim Fehlig wrote: > > > > > > > >> Daniel P. Berrange wrote: > > > >> > > > >>> On Tue, Sep 15, 2015 at 09:26:23AM -0600, Jim Fehlig wrote: > > > >>> > > > >>> > > > >>>> Instead of a hardcoded DEBUG log level, use the overall > > > >>>> daemon log level specified in libvirtd.conf when opening > > > >>>> a log stream with libxl. libxl is very verbose when DEBUG > > > >>>> log level is set, resulting in huge log files that can > > > >>>> potentially fill a disk. Control of libxl verbosity should > > > >>>> be placed in the administrator's hands. > > > >>>> > > > >>>> Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx> > > > >>>> --- > > > >>>> src/libxl/libxl_conf.c | 18 +++++++++++++++++- > > > >>>> 1 file changed, 17 insertions(+), 1 deletion(-) > > > >>>> > > > >>>> > > > >>> ACK, this makes sense as default behaviour. As a future enhancement > > > >>> you might also consider supporting a config setting in > > > >>> /etc/libvirt/libxl.conf > > > >>> to explicitly control the libxl library logging behaviour > > > >>> independantly. > > > >>> > > > >>> > > > >> I had actually thought of adding it there first, but then took this > > > >> approach assuming it would be more receptive upstream :-). Personally, > > > >> I'm on the fence. I like the idea of a single knob to control log level > > > >> throughout the daemon, making it a bit easier on admins. On the other > > > >> hand, individual knobs are more friendly to those pouring through logs. > > > >> I can add a knob in libxl.conf if preferred. > > > >> > > > > > > > > After thinking about it some more, I could actually see value in > > > > create a dedicated virLogSource() instance, solely for libxl > > > > library messages. If we then created a virLogSourceGetPriority() > > > > method, you could query that to see if to turn on logging for > > > > the libxl library. That would ultimately allow you to turn on > > > > debug for just the libxl library if desired, eg > > > > > > > > static virLogSource virLogLibXL = { > > > > .name = "libxl.libxl_library", > > > > .... > > > > } > > > > > > > > LIBVIRT_LOG_FILTERS="1:libxl_library" > > > > > > > > > > Ah, good idea. I'll look into it. > > > > Is it done anywhere? If not, how can I help? > > > > This the above change (setting libxl log level to libvirtd global one), > > makes almost impossible to get libxl debug, because the rest of libvirtd > > trashes the logs (hundreds virEvent* and virObject* messages, at > > "info"(!) level). > > Presumably that's because you are using LIBVIRT_DEBUG=1 or setting > log_debug=1 in /etc/libvirt/libvirtd.log. That is generally discouraged > because it turns on all logging, which is essentially unusably verbose. > > It is also better to use more specific log settings, eg when I debug > the QEMU driver I usually use > > log_filters="1:qemu 1:security 3:event 3:object 1:util" > log_outputs="1:file:/var/log/libvirt/libvirtd.log" > > This generates log messages from every source file in qemu and > security directories, and also log messages from every file > in the util/ directory *except* for event & object files. > So it is much more managable to read. Ok, I'll try with "3:event 3:object", thanks! > The log filter strings just do a wildcard match against the > VIR_LOG_INIT("...."); lines in each source file, so you can > make things more or less specific as you desire. > > Regards, > Daniel -- Best Regards, Marek Marczykowski-GÃrecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? Attachment:
pgpU0brcyFFjK.pgp _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |