On 10/11/21 14:38, Olaf Hering wrote:
Am Mon, 11 Oct 2021 13:25:20 -0600
schrieb Jim Fehlig <jfeh...@suse.com>:
I think it is wrong to use internal libvirt values for internal libxentoollog
values.
What is gained over the sparse mapping? Are values not covered actually useful
in practice? Also, how are the values specified when using the xl tool? A quick
peek at the code seems to imply using more 'v' options. E.g. 'xl -vvvv ...'.
Since libvirt has no control about what libxentoollog values the authors
use, it should provide a simple way to request a specific loglevel.
xl decided to use the number of v's for it.
How does one correlate a specific log level to the correct number of 'v'? :-)
IMO the sparse mapping we currently have is more intuitive.
If such a setting is actually needed, then the proper place would be
/etc/libvirt/libxl.conf. And IMO we should avoid creating a new name that could
potentially confuse users. If 'xentoollog_level' is the common jargon in xen, we
should stick with the same name.
If that is an acceptable approach I will try to prepare a patch.
I must admit I'm not fond of another log level knob. For many classes of bugs,
users would then need to tweak libvirtd.conf and libxl.conf to collect
appropriate debug info. That said, there is prior art. Going back to your
snipped question
>> I guess no other used library provides similar internal logging, this
requirement is unique to libxenlight.so.
Sorry for not looking closer earlier, but the qemu driver has a similar setting
in qemu.conf for the gluster libgfapi log level
https://gitlab.com/libvirt/libvirt/-/commit/a944bd925902d9ecce81e08900ad6a1adee06c6c
Jim
