Bug 1369107 - RFE config files under /etc/virt-who.d/ are picked up no matter what the extension is
Summary: RFE config files under /etc/virt-who.d/ are picked up no matter what the exte...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who
Version: 7.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Patrick Creech
QA Contact: Eko
Jiri Herrmann
Depends On:
TreeView+ depends on / blocked
Reported: 2016-08-22 13:46 UTC by Kenny Tordeurs
Modified: 2018-02-28 11:34 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Release Note
Doc Text:
*virt-who* configuration files are easier to manage The *virt-who* service now only uses configuration files in the `/etc/virt-who.d/` directory that end with the `.conf` extension. This enables easier management of *virt-who* configuration files, for example for testing or backup purposes.
Clone Of:
Last Closed: 2017-08-01 19:24:47 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2084 normal SHIPPED_LIVE virt-who bug fix and enhancement update 2017-08-01 18:14:28 UTC
Github virt-who virt-who pull 39 None None None 2017-01-04 16:08:20 UTC
Github virt-who virt-who pull 66 None None None 2017-05-09 14:17:28 UTC

Description Kenny Tordeurs 2016-08-22 13:46:19 UTC
Description of problem:
If I modify a config file for virt-who under /etc/virt-who.d/ with a different extension then .conf it will still be considered as a config file.

[root@provisioning virt-who.d]# ll
total 16
-rw-r--r--. 1 root root  290 Jul 20 12:04 rhevm.conf
-rw-r--r--. 1 root root  306 Aug 22 15:40 satotest2.conf.bkp
-rw-r--r--. 1 root root  305 Feb 29 10:37 satotest.conf
-rw-r--r--. 1 root root 1212 May 24 12:19 template.conf

For example .bkp extension is still being picked up by virt-who:
# egrep -i "\[" *

If I restart the virt-who service:
# egrep -i "using configuration" /var/log/rhsm/rhsm.log
2016-08-22 15:41:08,247 [INFO]  @virtwho.py:697 - Using configuration "satotest" ("libvirt" mode)
2016-08-22 15:41:08,247 [INFO]  @virtwho.py:697 - Using configuration "rhevm" ("rhevm" mode)
2016-08-22 15:41:08,247 [INFO]  @virtwho.py:697 - Using configuration "satotest3" ("libvirt" mode)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Change extension of config file for virt-who under /etc/virt-who.d/

Actual results:
Old config is still being picked up by virt-who

Expected results:
Restrict the config file to only .conf or we need to provide better info to our customers as many people prefer to change file to .bkp or with a date then removing it immediately.

Additional info:

Comment 2 Radek Novacek 2016-08-23 11:54:33 UTC
Although I agree that virt-who shouldn't pickup all files in /etc/virt-who.d, I don't think we can change that. Our customer might have config files without extension (or with extension different from .conf) in /etc/virt-who.d and if we started to ignore them, it would break for them.

virt-who in RHEL-7.3 will at least ignore hidden files, so at least there will be a workaround for this. Or deleting (commenting out) the "[section]" line will make virt-who ignore the config file (but it creates a warning in the log).

I've added a note about the behavior to the man page (upstream only for now):


Comment 3 Chris Snyder 2017-01-04 16:08:20 UTC
This RFE has been implemented upstream in the PR added as an external tracker to this bug. As this has been merged upstream and will be included in the first build for rhel 7.4 I'm moving this bug to the MODIFIED state.

Comment 5 yuefliu 2017-03-31 01:26:28 UTC
Verified the bug with RHEL-7.4-20170324.n.0, virt-who will ignore the "xen" and "esx.conf.bkp" configuration files, just run the "esx.conf" and "xen.conf" file.

- virt-who-0.19-1.el7.noarch
- subscription-manager-1.19.4-1.el7.x86_64
- python-rhsm-1.19.2-1.el7.x86_64

Comment 6 Craig Donnelly 2017-05-08 20:32:48 UTC
There is some concern in CEE now for this BZ's changes that were recognized from testing in customer environments with a recent build of virt-who:

The message below depicts what it currently looks like when a config is not found:

2017-05-08 13:26:25,548 [INFO] @main.py:164 - No configurations found, using libvirt as backend

I know that the config bits are being reworked, but in the immediate case of this BZ being pushed out to customers via 7.4, our worry is that there are a rather large number of customers currently using the non-standard naming scheme for their configs inside the drop directory. (For example, 'one', 'two', etc..)

Customers that are using configurations that do not contain '.conf' are not getting any hints that this is suddenly a constraint since it has not been before now.

We would like to change this slightly to include a hint that they may have incorrect naming.

Something along the lines of:

2017-05-08 13:26:25,548 [INFO] @main.py:164 - No configurations found (are there any '.conf' files inside /etc/virt-who.d?), using libvirt as backend

You can make the wording however you see fit, as long as we try to key off customers into the change without necessarily needing to open a case for just simply updating virt-who and now it will not load my config files.

(Don't get me wrong, we /want/ the naming constraint. This makes it simply to rename configurations we don't want to currently use and prevent them from being loaded anyway without having to move them from the directory.)

It would be best to attempt to eliminate case-load via this INFO message rather than having to throw a KCS at each customer this occurs for.


Comment 7 Chris Snyder 2017-05-08 21:23:44 UTC
Comment 6 makes eminent sense to me.

I will modify the message as requested.

Comment 8 Chris Snyder 2017-05-09 14:17:28 UTC
Attaching a PR with the requested log changes. In addition, the virt-who-config man pages have been updated to indicate the requirement of config files ending in '.conf'.

Comment 9 errata-xmlrpc 2017-08-01 19:24:47 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.