Re: [libvirt] [PATCH] libxl: open libxl log stream with libvirtd log_level

On Sep 15, 2015, at 4:06 PM, John Ferlan <jferlan(a)redhat.com&gt; wrote: > On 09/15/2015 01:21 PM, 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(a)suse.com&gt; >>>>> --- >>>>> 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. > >> Regardless we should just merge your current patch right now. > > Thanks; done now. > > Regards, > Jim Looks like compilations on Fedora are 'unhappy':