Bug 1367997

Summary: Failed to start virt-who when virt-who without env option against stage candlepin
Product: Red Hat Enterprise Linux 7 Reporter: Liushihui <shihliu>
Component: virt-whoAssignee: William Poteat <wpoteat>
Status: CLOSED CURRENTRELEASE QA Contact: Eko <hsun>
Severity: low Docs Contact:
Priority: medium    
Version: 7.3CC: khowell, ldai, sgao, wpoteat
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1409056 (view as bug list) Environment:
Last Closed: 2018-11-01 17:47:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1409056    

Description Liushihui 2016-08-18 05:43:19 UTC
Description of problem:
When It hasn't configured env option against stage candlepin, virt-who can't be started.

Version-Release number of selected component (if applicable):
virt-who-0.17-7.el7.noarch
subscription-manager-1.17.10-1.el7.x86_64
python-rhsm-1.17.6-1.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Register system to stage candlepin.

2. Start virt-who in CLI without env option.
# virt-who --xen --xen-owner=7970632 --xen-server=10.73.131.183 --xen-username=root --xen-password=Welcome1 -o -d
Option --xen-env (or VIRTWHO_XEN_ENV environment variable) needs to be set

3. Configure virt-who in /etc/virt-who.d/xxx or /etc/sysconfig/virt-who without env
# cat /etc/virt-who.d/virt
[xen]
type=xen
server=10.73.131.183
username=root
password=Welcome1
owner=7970632
env= 
# systemctl restart virt-who.service
Job for virt-who.service failed because the control process exited with error code. See "systemctl status virt-who.service" and "journalctl -xe" for details.

# 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 2016-08-17 14:37:04 EDT; 806ms ago
  Process: 18350 ExecStart=/usr/bin/virt-who (code=exited, status=1/FAILURE)
 Main PID: 18350 (code=exited, status=1/FAILURE)
   Status: "virt-who can't be started: Option --xen-env (or VIRTWHO_XEN_ENV environment variable) needs to be set"

Actual results:
Failed to start virt-who as it hasn't configure env.

Expected results:
Virt-who should be started normally although it hasn't configure env option when it work with stage candlepin Since "The thing is that *env switches are not handled by Candlepin itself. The env swiches are used to do authentication against other Sat 6 products (e.g. Katello)"(Refer to bug 1235980 comment 10).

Additional info:

Comment 1 Chris Snyder 2016-12-22 16:24:41 UTC
Proposed workaround:

Add any value for the environment. This will not impact how reports are processed in candlepin. This is due to the fact that candlepin does not use environments provided.

Comment 2 Liushihui 2017-11-02 02:32:53 UTC
It still exist on virt-who-0.20.4-1.el6sat.noarch against satellite6.3

Comment 3 Liushihui 2017-11-02 03:18:49 UTC
On virt-who-0.20.4-1.el6sat.noarch against satellite6.3, when disable "VIRTWHO_LIBVIRT_ENV" or "VIRTWHO_LIBVIRT_OWNER" in /etc/sysconfig/virt-who, restart virt-who, virt-who can't be started, this problem only exist on remote_libvirt mode on this version.

[NOTE]: Disable "VIRTWHO_XEN_ENV", "VIRTWHO_XEN_OWNER", "VIRTWHO_ESX_ENV", "VIRTWHO_ESX_OWNER","VIRTWHO_HYPERV_ENV", "VIRTWHO_HYPERV_OWNER" in /etc/sysconfig/virt-who, restart virt-who, virt-who can be restarted normally. therefore, xen, hyperv, esx mode hasn't this problem.

Comment 4 Kevin Howell 2018-06-13 15:21:04 UTC
Dev: we should figure out if Satellite is even using environment in this case, and if it's not being used, we should remove it. Otherwise, we want to determine if we need to use environment and either behave as currently, or not require it appropriately. We should warn if it's specified but not required.

Comment 5 William Poteat 2018-11-01 17:46:27 UTC
Upgrade to 0.21.0-1 to alleviate the problem.