Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
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.
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.
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.