Previously, vdsm.log did not report the correct VDSM release for Red Hat Enterprise Virtualization 3.1 installations.
This was problematic for people remotely troubleshooting customer installations: it was not possible to determine which version of VDSM if you used the log files as your only source of information.
vdsm-4.10.2-18.0.el6ev reports the correct VDSM release in the log files.
Description of problem:
In a RHEV 3.1 environment, the vdsm release being used on a RHEV host is (currently) 4.9.6. The release is reported in the 'vdsm.log' as "I am the actual vdsm 4.9-x.x", as opposed to "I am the actual vdsm 4.9.6-x.x".
This is somewhat trivial. In the RHEV-M GUI the vdsm release is identified as "vdsm-4.9.6-44.1.el6_3", so there is a way of quickly determining the version of vdsm. However, when troubleshooting a customer's problem remotely, if you only have specific log files, then a quick way of determining the vdsm release is by analysing the "I am the actual vdsm" line. Also, when a LogCollector is captured, this apparently doesn't have an rpm listing included for each host. It does however contain a YUM log, which would hopefullu contain the rpm version for vdsm. So, there are ways of determining the correct release of vdsm, other than relying on the vdsm log itself. However, seeing as the vdsm log is most likely going to be one of the first places to look for a RHEV host problem, then having the correct release/version information in it would facilitate troubleshooting. As I said, this is trivial, but if it's simple to address (see 'Additional info' below) then why not fix it.
Version-Release number of selected component (if applicable):
RHEV 3.1
VDSM 4.9.6
How reproducible:
When the vdsm service is restarted the message "I am the actual vdsm" is written to the 'vdsm.log' file.
Steps to Reproduce:
1. Start vdsm service on a RHEV host.
2. Look at the 'vdsm.log'.
Actual results:
$ rpm -q vdsm
vdsm-4.9.6-44.1.el6_3.x86_64
$ grep software /usr/share/vdsm/dsaversion.py |grep '='
software_version = "4.9"
software_revision = "44.1"
$ grep 'I am' /var/log/vdsm/vdsm.log
:MainThread::INFO::2012-12-21 09:21:09,141::vdsm::70::vds::(run) I am the actual vdsm 4.9-44.1
Expected results:
:MainThread::INFO::2012-12-21 09:21:09,141::vdsm::70::vds::(run) I am the actual vdsm 4.9.6-44.1
Additional info:
The 'vdsm.spec.in' file contains the following lines;
# Setting software_version and software_revision in dsaversion.py
baserelease=`echo "%{release}" | sed 's/\([0-9]\+\(\.[0-9]\+\)\?\).*/\1/'`
baseversion=`echo "%{version}" | sed 's/\([0-9]\+\(\.[0-9]\+\)\?\).*/\1/'`
sed -i -e 's/^software_version =.*/software_version = "'"${baseversion}"'"/' \
-e 's/^software_revision =.*/software_revision = "'"${baserelease}"'"/' vdsm/dsaversion.py
The 'vdsm/dsaversion.py.in' file contains;
software_version = "@PACKAGE_VERSION@"
software_revision = "@PACKAGE_RELEASE@"
If the 'baseversion' line in the 'vdsm.spec.in' file above is changed to;
baseversion=`echo "%{version}" | sed 's/\([0-9]\+\(\.[0-9]\+\)\?\).*/\0/'`
then the following lines get generated in '/usr/share/vdsm/dsaversion.py';
software_version = "4.9.6"
software_revision = "44.1"
which in turn would result in 'vdsm' reporting "I am the actual vdsm 4.9.6-44.1" on a subsequent restart.
However, that seems too easy. Is there some case where this wouldn't work ??? Just me second-guessing myself.
Comment 7Douglas Schilling Landgraf
2013-04-17 14:14:23 UTC
*** Bug 950677 has been marked as a duplicate of this bug. ***
Correct version of vdsm in vdsm.log
###
rpm -q vdsm
vdsm-4.10.2-19.0.el6ev.x86_64
###
grep 'I am' /var/log/vdsm/vdsm.log
MainThread::INFO::2013-05-16 06:50:53,737::vdsm::88::vds::(run) I am the actual vdsm 4.10.2-19.0.el6ev aqua-vds10.qa.lab.tlv.redhat.com (2.6.32-358.6.1.el6.x86_64)
Verified on:
vdsm-4.10.2-19.0.el6ev.x86_64
libvirt-0.10.2-18.el6_4.4
sf16
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHSA-2013-0886.html
Description of problem: In a RHEV 3.1 environment, the vdsm release being used on a RHEV host is (currently) 4.9.6. The release is reported in the 'vdsm.log' as "I am the actual vdsm 4.9-x.x", as opposed to "I am the actual vdsm 4.9.6-x.x". This is somewhat trivial. In the RHEV-M GUI the vdsm release is identified as "vdsm-4.9.6-44.1.el6_3", so there is a way of quickly determining the version of vdsm. However, when troubleshooting a customer's problem remotely, if you only have specific log files, then a quick way of determining the vdsm release is by analysing the "I am the actual vdsm" line. Also, when a LogCollector is captured, this apparently doesn't have an rpm listing included for each host. It does however contain a YUM log, which would hopefullu contain the rpm version for vdsm. So, there are ways of determining the correct release of vdsm, other than relying on the vdsm log itself. However, seeing as the vdsm log is most likely going to be one of the first places to look for a RHEV host problem, then having the correct release/version information in it would facilitate troubleshooting. As I said, this is trivial, but if it's simple to address (see 'Additional info' below) then why not fix it. Version-Release number of selected component (if applicable): RHEV 3.1 VDSM 4.9.6 How reproducible: When the vdsm service is restarted the message "I am the actual vdsm" is written to the 'vdsm.log' file. Steps to Reproduce: 1. Start vdsm service on a RHEV host. 2. Look at the 'vdsm.log'. Actual results: $ rpm -q vdsm vdsm-4.9.6-44.1.el6_3.x86_64 $ grep software /usr/share/vdsm/dsaversion.py |grep '=' software_version = "4.9" software_revision = "44.1" $ grep 'I am' /var/log/vdsm/vdsm.log :MainThread::INFO::2012-12-21 09:21:09,141::vdsm::70::vds::(run) I am the actual vdsm 4.9-44.1 Expected results: :MainThread::INFO::2012-12-21 09:21:09,141::vdsm::70::vds::(run) I am the actual vdsm 4.9.6-44.1 Additional info: The 'vdsm.spec.in' file contains the following lines; # Setting software_version and software_revision in dsaversion.py baserelease=`echo "%{release}" | sed 's/\([0-9]\+\(\.[0-9]\+\)\?\).*/\1/'` baseversion=`echo "%{version}" | sed 's/\([0-9]\+\(\.[0-9]\+\)\?\).*/\1/'` sed -i -e 's/^software_version =.*/software_version = "'"${baseversion}"'"/' \ -e 's/^software_revision =.*/software_revision = "'"${baserelease}"'"/' vdsm/dsaversion.py The 'vdsm/dsaversion.py.in' file contains; software_version = "@PACKAGE_VERSION@" software_revision = "@PACKAGE_RELEASE@" If the 'baseversion' line in the 'vdsm.spec.in' file above is changed to; baseversion=`echo "%{version}" | sed 's/\([0-9]\+\(\.[0-9]\+\)\?\).*/\0/'` then the following lines get generated in '/usr/share/vdsm/dsaversion.py'; software_version = "4.9.6" software_revision = "44.1" which in turn would result in 'vdsm' reporting "I am the actual vdsm 4.9.6-44.1" on a subsequent restart. However, that seems too easy. Is there some case where this wouldn't work ??? Just me second-guessing myself.