Bug 1367997 - Failed to start virt-who when virt-who without env option against stage candlepin
Summary: Failed to start virt-who when virt-who without env option against stage candl...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who
Version: 7.3
Hardware: x86_64
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: William Poteat
QA Contact: Eko
URL:
Whiteboard:
Depends On:
Blocks: 1409056
TreeView+ depends on / blocked
 
Reported: 2016-08-18 05:43 UTC by Liushihui
Modified: 2018-11-01 17:47 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1409056 (view as bug list)
Environment:
Last Closed: 2018-11-01 17:47:14 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


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