Hide Forgot
Description of problem: 2 latest version of virt-who ignore the -c option when run in -o mode. Version-Release number of selected component (if applicable): 0.17.9, 0.17.10 How reproducible: Every time we run virt-who -o -c /etc/virt-who.d/<file> Create 2 configuration files under /etc/virt-who.d/ (eg loc1.conf and loc2.conf) Steps to Reproduce: 1. Create a configuration file /etc/virt-who.d/loc1.conf 2. Create a second configuration file /etc/virt-who.d/loc2.conf 3. Use ESX mode for both sites 4. Execute virt-who -o -c /etc/virt-who.d/loc1.conf Actual results: virt-who **ingores** the -c option and process ALL files under /etc/virt-who.d directory Expected results: virt-who should process only the configuration file we set. Additional info: In version 0.14.9 works as expected. Severity is set to high because it can cause issues with subscriptions when ESXi hosts are added in the Satellite.
now virt-who will run all the configure files in /etc/virt-who.d/ by default, if the file is in /etc/virt-who.d/, with -c or without -c, this file will always be run, the -c option often be used for the files not in /etc/virt-who.d/, Hi Chris, do you think this is a bug?
Considering this worked differently in prior versions of virt-who, I would say that this is a bug. The current behaviour seems to be to add the configuration specified using -c but not to limit the configs used to only those specified using the cli options. Is the desired behaviour to ignore all configuration in the /etc/virt-who.d directory if given at least one -c option?
Hello, Even if -c was designed to use files outside of /etc/virt-who.d, it's not documented. And in any case, we need to have a way to run virt-who for only one configuration file. It's not a option to remove unwanted files from /etc/virt-who.d, run the command and then place the rest of the files back in /etc/virt-who.d.
It still exist on virt-who-0.21.0-1.el7.noarch
I would say this looks like a duplicate of [0] which has a better status report [0] https://bugzilla.redhat.com/show_bug.cgi?id=1542652 *** This bug has been marked as a duplicate of bug 1542652 ***