Bug 1254843 - virt-who still can work normally if no "env" option in /etc/virt-who.d/ config file
virt-who still can work normally if no "env" option in /etc/virt-who.d/ confi...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who (Show other bugs)
7.2
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Radek Novacek
xingge
:
: 1263093 1263119 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-18 23:22 EDT by Eko
Modified: 2016-11-30 19:34 EST (History)
9 users (show)

See Also:
Fixed In Version: virt-who-0.14-9.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-19 06:57:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eko 2015-08-18 23:22:54 EDT
Description of problem:
If no "env" option in /etc/virt-who.d/ config file, virt-who still can work normally. 

If I disable VIRTWHO_ESX_ENV in /etc/sysconfig/virt-who, virt-who will feedback some error message

If I run virt-who CLI without --esx-env option, virt-who also can feedback the error message

Version-Release number of selected component (if applicable):
 - RHEL7.2-20150806.1-Server + ESXi6.0 against stage candlepin
 - virt-who-0.14-3.el7.noarch
 - subscription-manager-1.15.9-2.el7.x86_64
 - python-rhsm-1.15.4-2.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. create the config fie in /etc/virt-who.d, make sure without env option
[test-esx]
type=esx
server=10.66.78.89
username=administrator@vsphere.local
password=qwer1234P!
owner=7652501

2. restart virt-who service and check ther rhsm.log
2015-08-19 11:14:16,465 [DEBUG]  @virtwho.py:126 - Using config named 'test-esx'
2015-08-19 11:14:16,465 [INFO]  @virtwho.py:662 - Using configuration "test-esx" ("esx" mode)
2015-08-19 11:14:16,465 [DEBUG]  @virtwho.py:209 - Starting infinite loop with 10 seconds interval
2015-08-19 11:14:16,495 [DEBUG]  @esx.py:55 - Log into ESX
2015-08-19 11:14:16,675 [DEBUG]  @esx.py:58 - Creating ESX event filter
2015-08-19 11:14:16,743 [DEBUG]  @esx.py:142 - Waiting for ESX changes
2015-08-19 11:14:16,746 [DEBUG]  @subscriptionmanager.py:112 - Authenticating with certificate: /etc/pki/consumer/cert.pem
2015-08-19 11:14:18,394 [DEBUG]  @subscriptionmanager.py:146 - Checking if server has capability 'hypervisor_async'
2015-08-19 11:14:20,031 [DEBUG]  @subscriptionmanager.py:158 - Server does not have 'hypervisors_async' capability
2015-08-19 11:14:20,031 [INFO]  @subscriptionmanager.py:165 - Sending update in hosts-to-guests mapping: {
    "aee4ff00-8c33-11e2-994a-6c3be51d959a": [
        {
            "guestId": "564d3964-c083-deba-55f9-000279dd82f9", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "esx"
            }
        }
    ], 
    "b081ac44-e247-2c82-4fea-825c08228288": [
        {
            "guestId": "4239b745-4369-40fd-569c-ba0d396654e9", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "virtWhoType": "esx"
            }
        }
    ]
}
2015-08-19 11:14:26,768 [DEBUG]  @esx.py:142 - Waiting for ESX changes

========== without env option, virt-who still can work normally =========

3. config virt-who in /etc/sysconfig/virt-who and make sure VIRTWHO_ESX_ENV disabled
VIRTWHO_ESX_OWNER=7652501
#VIRTWHO_ESX_ENV=7652501
VIRTWHO_ESX_SERVER=10.66.78.89
VIRTWHO_ESX_USERNAME=administrator@vsphere.local
VIRTWHO_ESX_PASSWORD=qwer1234P!

4. restart virt-who service and check service status
# systemctl  restart  virt-who.service 
# systemctl  status  virt-who.service 
● virt-who.service - Daemon for reporting virtual guest IDs to subscription-manager
   Loaded: loaded (/usr/lib/systemd/system/virt-who.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2015-08-19 11:17:54 CST; 12s ago
  Process: 2021 ExecStart=/usr/bin/virt-who (code=exited, status=1/FAILURE)
 Main PID: 2021 (code=exited, status=1/FAILURE)

Aug 19 11:17:54 dhcp-129-10.nay.redhat.com systemd[1]: Started Daemon for reporting virtual guest IDs to subscription-manager.
Aug 19 11:17:54 dhcp-129-10.nay.redhat.com systemd[1]: Starting Daemon for reporting virtual guest IDs to subscription-manager...
Aug 19 11:17:54 dhcp-129-10.nay.redhat.com virt-who[2021]: Option --esx-env (or VIRTWHO_ESX_ENV environment variable) needs to be set
Aug 19 11:17:54 dhcp-129-10.nay.redhat.com systemd[1]: virt-who.service: main process exited, code=exited, status=1/FAILURE
Aug 19 11:17:54 dhcp-129-10.nay.redhat.com systemd[1]: Unit virt-who.service entered failed state.
Aug 19 11:17:54 dhcp-129-10.nay.redhat.com systemd[1]: virt-who.service failed.

======= virt-who can't be started, feedback " Option --esx-env (or VIRTWHO_ESX_ENV environment variable) needs to be set" =======

5. run virt-who CLI without --esx-env
# virt-who --esx --esx-owner=7652501 --esx-server=10.66.78.89 --esx-username=Administrator@vsphere.local --esx-password=qwer1234P!  -o -d
Option --esx-env (or VIRTWHO_ESX_ENV environment variable) needs to be set

======= virt-who can't be started, feedback " Option --esx-env (or VIRTWHO_ESX_ENV environment variable) needs to be set" =======


Actual results:
If no "env" option in /etc/virt-who.d/ config file, virt-who can be started and no any error message feedback

Expected results:
virt-who shouldn't be started if no "env" option in /etc/virt-who.d/ config file, such as the step 4 and 5. 

Additional info:
Comment 2 Radek Novacek 2015-08-25 13:11:55 EDT
Fixed in virt-who-0.14-5.el7.
Comment 4 Liushihui 2015-09-05 23:35:11 EDT
Verified it on virt-who-0.14-7.el7.noarch since virt-who won't start when env isn't exist. Therefore, verify it.

Verified version:
virt-who-0.14-7.el7.noarch
subscription-manager-1.15.9-7.el7.x86_64
python-rhsm-1.15.4-4.el7.x86_64

Verified process:
1. Register system to stage candlepin
2. Configure virt-who run at esx mode and "env" isn't exist.
[root@hp-z220-06 ~]# cat /etc/virt-who.d/virt
[test-esx]
type=esx
server=10.66.78.2
username=administrator@vsphere.local
password=qwer1234P!
owner=7652501
3. Restart virt-who service and check virt-who's log
[root@hp-z220-06 ~]# systemctl restart virt-who
[root@hp-z220-06 ~]# systemctl status virt-who
● virt-who.service - Daemon for reporting virtual guest IDs to subscription-manager
   Loaded: loaded (/usr/lib/systemd/system/virt-who.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2015-09-06 11:27:11 CST; 52s ago
  Process: 16581 ExecStart=/usr/bin/virt-who (code=exited, status=1/FAILURE)
 Main PID: 16581 (code=exited, status=1/FAILURE)

Sep 06 11:27:11 hp-z220-06.qe.lab.eng.nay.redhat.com virt-who[16581]: File "/usr/share/virt-who/config.py", line 96, in checkOptions
Sep 06 11:27:11 hp-z220-06.qe.lab.eng.nay.redhat.com virt-who[16581]: raise InvalidOption("Option `env` needs to be set in config `%s`" % (self.name))
Sep 06 11:27:11 hp-z220-06.qe.lab.eng.nay.redhat.com virt-who[16581]: InvalidOption: Option `env` needs to be set in config `test-rhevm1`
Sep 06 11:27:11 hp-z220-06.qe.lab.eng.nay.redhat.com python[16581]: Fatal error:
Sep 06 11:27:11 hp-z220-06.qe.lab.eng.nay.redhat.com python[16581]: Fatal error:
Sep 06 11:27:11 hp-z220-06.qe.lab.eng.nay.redhat.com virt-who[16581]: Fatal error:
Sep 06 11:27:11 hp-z220-06.qe.lab.eng.nay.redhat.com virt-who[16581]: Option `env` needs to be set in config `test-rhevm1`
Sep 06 11:27:11 hp-z220-06.qe.lab.eng.nay.redhat.com systemd[1]: virt-who.service: main process exited, code=exited, status=1/FAILURE
Sep 06 11:27:11 hp-z220-06.qe.lab.eng.nay.redhat.com systemd[1]: Unit virt-who.service entered failed state.
Sep 06 11:27:11 hp-z220-06.qe.lab.eng.nay.redhat.com systemd[1]: virt-who.service failed.
[root@hp-z220-06 ~]# tail -f /var/log/rhsm/rhsm.log
2015-09-06 11:24:28,027 [ERROR]  @virtwho.py:304 - Sending data failed 5 times, report skipped
2015-09-06 11:27:11,278 [ERROR]  @virtwho.py:747 - Fatal error:
Traceback (most recent call last):
  File "/usr/share/virt-who/virtwho.py", line 741, in <module>
    main()
  File "/usr/share/virt-who/virtwho.py", line 670, in main
    virtWho = VirtWho(logger, options)
  File "/usr/share/virt-who/virtwho.py", line 130, in __init__
    self.configManager = ConfigManager(self.logger, config_dir, smType=options.smType)
  File "/usr/share/virt-who/config.py", line 352, in __init__
    self._readConfig(parser)
  File "/usr/share/virt-who/config.py", line 359, in _readConfig
    config.checkOptions(self.smType, self.logger)
  File "/usr/share/virt-who/config.py", line 96, in checkOptions
    raise InvalidOption("Option `env` needs to be set in config `%s`" % (self.name))
InvalidOption: Option `env` needs to be set in config `test-rhevm1`
Comment 5 Eko 2015-09-08 06:00:29 EDT
if set the type to libvirt mode and them delete the env option, this issue still can be duplicated.

on the other hand, if set an wrong env, the mapping info still can be updated to server, there is bug about it: 
https://bugzilla.redhat.com/show_bug.cgi?id=1235980
Comment 6 Radek Novacek 2015-09-08 07:01:08 EDT
Eko,

do you mean that virt-who should show warning when `env` option is supplied in local libvirt mode?
Comment 7 Eko 2015-09-09 02:49:34 EDT
hi radek,
When we create a config file in /etc/virt-who.d/, there are three testcases to verify the env option
1). a right env value [pass]

2). an wrong env value [failed]
virt-who shouldn't work normally with an wrong env value, such as:
[test-libvirt]
type=libvirt
server=10.66.129.10
username=root
password=redhat
owner=7661967
env=xxxxxxx

3). no env option [failed]
if there is no env option in config file, virt-who should not work as comment4, but I checked this for libvirt remote mode as following cinfig, virt-who still can work normally, no any warning or error message like comment4

[test-libvirt]
type=libvirt
server=10.66.129.10
username=root
password=redhat
owner=7661967
Comment 8 Radek Novacek 2015-09-15 04:55:23 EDT
*** Bug 1263093 has been marked as a duplicate of this bug. ***
Comment 9 Radek Novacek 2015-09-15 10:27:29 EDT
The fis for this issue is applied upstream.
Comment 10 Radek Novacek 2015-09-15 11:12:29 EDT
Fixed in virt-who-0.14-8.el7.
Comment 12 Liushihui 2015-09-18 03:05:05 EDT
It still exist on virt-who-0.14-8.el7.noarch. If virt-who run at remote libvirt mode and fake mode, virt-who still can sent h/g mapping to server when env or owner have not been configured in /etc/virt-who.d/XXX. The phenomenon is the same as comment 7, Therefore, reopen it.

Checked version:
virt-who-0.14-8.el7.noarch
subscription-manager-1.15.9-10.el7.x86_64
python-rhsm-1.15.4-5.el7.x86_64
Comment 13 Radek Novacek 2015-09-22 09:35:06 EDT
*** Bug 1263119 has been marked as a duplicate of this bug. ***
Comment 14 Radek Novacek 2015-09-22 09:59:03 EDT
Fixed in virt-who-0.14-9.el7.
Comment 16 Eko 2015-09-25 01:34:53 EDT
check this issue on virt-who-0.14-9.el7
if no env or owner, fake mode still can send the mapping info

remote libvirt mode [ok]
esx mode [ok]
Comment 17 Radek Novacek 2015-09-29 02:02:13 EDT
In the fake mode, it depends on the is_hypervisor option.

If is_hypervisor is true, virt-who should require env and owner options. If is_hypervisor is false, the env and owner options are not used and warning should be printed.

Can you please check if virt-who behaves as I described?
Comment 18 Liushihui 2015-09-29 02:15:35 EDT
Verified it on virt-who-0.14-9.el7 since virt-who can check env and owner when is_hypervisor=true. Therefore, verify it.

It is true. when virt-who run at fake mode, if is_hypervisor=True, virt-who will check env and owner.
Comment 19 errata-xmlrpc 2015-11-19 06:57:53 EST
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.

https://rhn.redhat.com/errata/RHBA-2015-2370.html

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