Description of problem: When a RHEV-H 6.5 host containing vdsm-4.14.x is booted, the '/usr/libexec/ovirt-init-functions.sh' (part of 'ovirt-early') removes the active 'log_filters' line from '/etc/libvirt/libvirtd.conf'; start_ovirt_early () { { log "Starting ovirt-early" _start_ovirt_early RETVAL=$? # TEMP fix broken libvirtd.conf sed -c -i '/^log_filters=/d' /etc/libvirt/libvirtd.conf echo "GFW: log_filters removed" log "Completed ovirt-early" } >> $OVIRT_LOGFILE 2>&1 return $RETVAL } This results in libvirtd not logging any vdsm-related entries in its log file, whether that it '/var/log/libvirtd.log' or '/var/log/libvirt/libvirtd.log'. In versions prior to RHEV-H 6.5 '20140725', vdsm would then run 'vdsm-tool' and try to "configure libvirt", which would fail due to the problem described in BZ 1133955 if the system had been upgraded from a version running vdsm-4.13.0. If, on the other hand, this were a cold install, then on the initial boot a 'log_filters' line would get added to '/etc/libvirt/libvirtd.conf', plus the following entries; ## beginning of configuration section by vdsm-4.13.0 ## end of configuration section by vdsm-4.13.0 However, on a subsequent boot, '/usr/libexec/ovirt-init-functions.sh' will remove the 'log_filters' line from '/etc/libvirt/libvirtd.conf' and again, due to BZ 1133955, VDSM would not be able to add it back in. With RHEV-H 6.5 '20140725','/usr/libexec/ovirt-node/hooks/on-boot/01-vdsm-configure' now calls 'vdsm-tool' to 'configure libvirt". However, if this host has been upgraded from a version running vdsm-4.13.0 then again BZ 1133955 comes into play and nothing will get updated in '/etc/libvirt/libvirtd.conf', If BZ 1133955 were addressed such that 'BY_VDSM_VERS' in '/usr/libexec/vdsm/libvirt_configure.sh' were to contain something like "4.14.x" then when '/usr/libexec/ovirt-node/hooks/on-boot/01-vdsm-configure' called 'vdsm-tool' it would be able to update '/etc/libvirt/libvirtd.conf' and add a 'log_filters' line. However, again '/usr/libexec/ovirt-init-functions.sh' then removes this line. So, on face value, it would seem that if removing the "TEMP fix broken libvirtd.conf" from '/usr/libexec/ovirt-init-functions.sh' were to be the solution to this from the RHEV-H/ovirt-node standpoint then this would also depend upon BZ 1133955, i.e. modifying 'BY_VDSM_VERS' in '/usr/libexec/vdsm/libvirt_configure.sh'. Version-Release number of selected component (if applicable): - RHEV-H 6.5 hosts containing vdsm-4.14.x How reproducible: Steps to Reproduce: 1. Boot a RHEV-H 6.5 host containing vdsm-4.14.x 2. Check '/etc/libvirt/libvirtd.conf'. No active 'log_filters' line will exist. 3. Check '/var/log/libvirtd.log'. It will not record any vdsm-related entries. Actual results: Expected results: Additional info:
I could reproduce this bug in the follow version: rhev-hypervisor6-6.5-20140821.1.el6ev.iso vdsm-4.14.13-2.el6ev.x86_64 Steps to Reproduce: 1. Clean install rhev-hypervisor6-6.5-20140821.1.el6ev.iso and configure network up 2.Register RHEV-H to RHEV-M 3.Check /var/log/libvirt/libvirtd.log 4.Check /etc/libvirt/libvirtd.conf 5.Clean up /var/log/libvirt/libvirtd.log 6.reboot rhevh 7.Check /var/log/libvirt/libvirtd.log and /etc/libvirt/libvirtd.conf again Test result: After step 3, could see vdsm-related entries log info in '/var/log/libvirt/libvirtd.log'. After step4, could see "log_filters="3:virobject 3:virfile 2:virnetlink 3:cgroup 3:event 3:json 1:libvirt 1:util 1:qemu"" in "/etc/libvirt/libvirtd.conf" .... ## beginning of configuration section by vdsm-4.13.0 listen_addr="0.0.0.0" unix_sock_group="qemu" unix_sock_rw_perms="0770" auth_unix_rw="sasl" host_uuid="345a6214-5887-428e-bfe9-e9d0c0befc30" keepalive_interval=-1 log_outputs="1:file:/var/log/libvirt/libvirtd.log" log_filters="3:virobject 3:virfile 2:virnetlink 3:cgroup 3:event 3:json 1:libvirt 1:util 1:qemu" ca_file="/etc/pki/vdsm/certs/cacert.pem" cert_file="/etc/pki/vdsm/certs/vdsmcert.pem" key_file="/etc/pki/vdsm/keys/vdsmkey.pem" ## end of configuration section by vdsm-4.13.0 ..... after step7, check that no vdsm-related entries log info in '/var/log/libvirt/libvirtd.log', and "log_filters="3:virobject 3:virfile 2:virnetlink 3:cgroup 3:event 3:json 1:libvirt 1:util 1:qemu"" has been removed from "/etc/libvirt/libvirtd.conf"
(In reply to Gordon Watson from comment #0) > Description of problem: > > When a RHEV-H 6.5 host containing vdsm-4.14.x is booted, the > '/usr/libexec/ovirt-init-functions.sh' (part of 'ovirt-early') removes the > active 'log_filters' line from '/etc/libvirt/libvirtd.conf'; > > start_ovirt_early () { > { > log "Starting ovirt-early" > _start_ovirt_early > RETVAL=$? > # TEMP fix broken libvirtd.conf > sed -c -i '/^log_filters=/d' /etc/libvirt/libvirtd.conf > echo "GFW: log_filters removed" > log "Completed ovirt-early" > } >> $OVIRT_LOGFILE 2>&1 > return $RETVAL > } > > This results in libvirtd not logging any vdsm-related entries in its log > file, whether that it '/var/log/libvirtd.log' or > '/var/log/libvirt/libvirtd.log'. > > In versions prior to RHEV-H 6.5 '20140725', vdsm would then run 'vdsm-tool' > and try to "configure libvirt", which would fail due to the problem > described in BZ 1133955 if the system had been upgraded from a version > running vdsm-4.13.0. If, on the other hand, this were a cold install, then > on the initial boot a 'log_filters' line would get added to > '/etc/libvirt/libvirtd.conf', plus the following entries; > > ## beginning of configuration section by vdsm-4.13.0 > ## end of configuration section by vdsm-4.13.0 > > However, on a subsequent boot, '/usr/libexec/ovirt-init-functions.sh' will > remove the 'log_filters' line from '/etc/libvirt/libvirtd.conf' and again, > due to BZ 1133955, VDSM would not be able to add it back in. > > > With RHEV-H 6.5 > '20140725','/usr/libexec/ovirt-node/hooks/on-boot/01-vdsm-configure' now > calls 'vdsm-tool' to 'configure libvirt". However, if this host has been > upgraded from a version running vdsm-4.13.0 then again BZ 1133955 comes into > play and nothing will get updated in '/etc/libvirt/libvirtd.conf', > > If BZ 1133955 were addressed such that 'BY_VDSM_VERS' in > '/usr/libexec/vdsm/libvirt_configure.sh' were to contain something like > "4.14.x" > then when '/usr/libexec/ovirt-node/hooks/on-boot/01-vdsm-configure' called > 'vdsm-tool' it would be able to update '/etc/libvirt/libvirtd.conf' and add > a 'log_filters' line. However, again '/usr/libexec/ovirt-init-functions.sh' > then removes this line. > > So, on face value, it would seem that if removing the "TEMP fix broken > libvirtd.conf" from '/usr/libexec/ovirt-init-functions.sh' were to be the > solution to this from the RHEV-H/ovirt-node standpoint then this would also > depend upon BZ 1133955, i.e. modifying 'BY_VDSM_VERS' in > '/usr/libexec/vdsm/libvirt_configure.sh'. > > > > Version-Release number of selected component (if applicable): > > - RHEV-H 6.5 hosts containing vdsm-4.14.x > > > > How reproducible: > > > Steps to Reproduce: > > 1. Boot a RHEV-H 6.5 host containing vdsm-4.14.x > 2. Check '/etc/libvirt/libvirtd.conf'. No active 'log_filters' line will > exist. > 3. Check '/var/log/libvirtd.log'. It will not record any vdsm-related > entries. > Hi Fabian, Looking into ovirt node git log is not helpful why we need such change (remove log_filters). Might be an old (2012) change not needed at this moment? Any thought? Thanks!
It looks like an old workaround which was added some time back. We can give it a go to remove that hack (the lines in ovirt-early), and see if it addresses this issue and also works well with other situations.
According to Bug 1125237 - Use libvirt default logging parameters to reduce cost of starting multiple VMs, In order to resolve the follow issue: Default logging level configuration of VDSM and libvirt is DEBUG which leads to increase of log files size and impact on performance. so the follow lines: 'log_outputs': ( '"1:file:/var/log/libvirt/libvirtd.log"'), 'log_filters': ( '"3:virobject 3:virfile 2:virnetlink ' '3:cgroup 3:event 3:json 1:libvirt ' '1:util 1:qemu"'), won't add into "/etc/libvirt/libvirtd.conf" default by vdsm, see pacth http://gerrit.ovirt.org/#/c/31135/ to get more details. this means now it's design that /var/log/libvirtd.log will not record vdsm-related messages. so this bug should be marked as "NOTABUG"