On Wed, Jun 16, 2021 at 12:19:16PM +0200, Olaf Hering wrote:
> In src/libxl/libxl_conf.c:libxlDriverConfigInit, virLogGetDefaultPriority
> is used to specify the (private) loglevel of an external library. This
> value could be controlled via "log_level=N" in libvirtd.conf. But doing
> it that way will affect libvirtd itself, instead of libxenlight.so as
> intended. There might be ways to suppress everything but libxl output
> via "log_filters=", but it is not clear what the syntax would be.
We support wildcards so probably:
log_filters="3:*"
> I wonder what the preferred way is to specify the desired loglevel for
> the external library. It seems a separate configuration setting is
> required so that each value of XTL_* from xentoollog.h can be specified.
In general I think the global log level concept in libvirt is flawed,
because libvirt has way too much logging present for it to be viable
to control level globally.
So the right answer is really to use the fine grained logging filters
which control logging per virLogSource object. Usually there is a single
virLogSource per file.
In the case of libxl, it provides callbacks that can be used to
receive the messages and then output them wherever is needed. The
libxl driver does this to write logs into the per-domain log file.
The problem is that the libvirt_vmessage method is filtering messages
based on the 'minLevel' field which is set from virLogGetDefaultPriority
I think the better solution is to filter based on a virLogSource object.
Two options in this respect. Either we can use the existing
VIR_LOG_INIT("libxl.libxl_logger") source from libxl_logger.c
Or we can define a second logging source manually
static virLogSource virLogLibXL = {
.name = "libxl.libxl_library",
.priority = VIR_LOG_ERROR,
.serial = 0,
}
The only complication here is that the 'priority' field is not valid
until we've called virLogVMessage with this virLogSource instance.
If we're reusing the existing virLogSource instance from libxl_logger.c
that's ok, as we have a VIR_DEBUG call that will trigger update of the
'priority' field.
If we're defining a custom virLogSource instance, then we need to make
the virLogSourceUpdate() method public from virlog.c, so that you can
call it to update 'priority'. eg libvirt_vmessage needs todo
if (source->serial < virLogFiltersSerial)
virLogSourceUpdate(source);
Anyway if you used a virLogSource object, then turning on debugging
exclusively for libxl library messages would be as simple as
log_filters="1:libxl.libxl_library"
without affecting the global libvirt logging behaviour
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
