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.
DescriptionAnand Jambhulkar
2019-09-04 01:29:05 UTC
Q1 - What is the exact version of Satellite Server that you are using?
A1 - This doesn't matter which version of Satellite Server I am running, it doesn't make it that far. virt-who-0.24.7-1.el7.noarch is part of the OS and not Satelilte. @rhel-7-server-rpms
Q2 - What is the version of "virt-who" that is causing this issue?
A2 - This is pretty much any version of virt-who. virt-who-0.24.7-1.el7.noarch This has been going on for as long as I can remember.
Q3 - Do you see any error message that is being presented to you on the screen?
A3 -
# virt-who -d -o -c 24.conf
2019-09-03 12:31:01,187 [virtwho.rhsm_log INFO] MainProcess(48577):MainThread @config.py:init_config:1465 - Using configuration passed in by -c/--configs; ignoring configuration files in '/etc/virt-who.d/'
2019-09-03 12:31:01,189 [virtwho.rhsm_log INFO] MainProcess(48577):MainThread @executor.py:__init__:54 - Using config named 'apsep9169'
2019-09-03 12:31:01,190 [virtwho.rhsm_log INFO] MainProcess(48577):MainThread @main.py:main:162 - Using configuration "apsep9169" ("esx" mode)
2019-09-03 12:31:01,190 [virtwho.rhsm_log INFO] MainProcess(48577):MainThread @main.py:main:164 - Using reporter_id='apsrp09228-b6ef2a6a5df846b6b31943daaa99835a'
2019-09-03 12:31:01,197 [rhsm.https DEBUG] MainProcess(48577):MainThread @https.py:<module>:56 - Using standard libs to provide httplib and ssl
2019-09-03 12:31:01,206 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @virt.py:run:407 - Thread 'apsep9169' started
2019-09-03 12:31:01,207 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_prepare:130 - Log into ESX
2019-09-03 12:31:01,561 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_prepare:133 - Creating ESX event filter
Control C was pressed, but it never returns, yo
2019-09-03 12:31:18,766 [virtwho.main DEBUG] MainProcess(48577):MainThread @executor.py:terminate:225 - virt-who is shutting down
2019-09-03 12:31:18,818 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_prepare:130 - Log into ESX
2019-09-03 12:31:19,111 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_prepare:133 - Creating ESX event filter
2019-09-03 12:32:19,192 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_run:181 - Wait for ESX event finished, timeout
2019-09-03 12:33:19,282 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_run:181 - Wait for ESX event finished, timeout
2019-09-03 12:34:19,369 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_run:181 - Wait for ESX event finished, timeout
Q4 - If yes to Q3, then please attach the screenshot of the error message.
Q5 - Since when did you start observing this issue?
A5 - This happens whenever our VMWare team moves things around and we are left with an empty vCenter. This has been going on for years.
Q6 - Did you upgrade the Satellite Server after which this issue started to appear? or was it present even before the upgrade?
A6 - Again this doesn't matter what version of Satellite, it never gets far enough to even talk to Satellite.
Is there ever a point at which there are systems that could be reported on in the vCenter? Is virt-who running at these points? If so does the existing virt-who process successfully report those systems?
From what's been described it seems like the answer is no, but I'd like to confirm before we begin work so we might come up with the best solution.
Thanks!
What is the behavior when virt-who is run as a service as intended? Does it timeout before the next cycle?
If you start the service against the empty vCenter and then add a hypervisor, does it start reporting again?
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://access.redhat.com/errata/RHBA-2020:1592
Q1 - What is the exact version of Satellite Server that you are using? A1 - This doesn't matter which version of Satellite Server I am running, it doesn't make it that far. virt-who-0.24.7-1.el7.noarch is part of the OS and not Satelilte. @rhel-7-server-rpms Q2 - What is the version of "virt-who" that is causing this issue? A2 - This is pretty much any version of virt-who. virt-who-0.24.7-1.el7.noarch This has been going on for as long as I can remember. Q3 - Do you see any error message that is being presented to you on the screen? A3 - # virt-who -d -o -c 24.conf 2019-09-03 12:31:01,187 [virtwho.rhsm_log INFO] MainProcess(48577):MainThread @config.py:init_config:1465 - Using configuration passed in by -c/--configs; ignoring configuration files in '/etc/virt-who.d/' 2019-09-03 12:31:01,189 [virtwho.rhsm_log INFO] MainProcess(48577):MainThread @executor.py:__init__:54 - Using config named 'apsep9169' 2019-09-03 12:31:01,190 [virtwho.rhsm_log INFO] MainProcess(48577):MainThread @main.py:main:162 - Using configuration "apsep9169" ("esx" mode) 2019-09-03 12:31:01,190 [virtwho.rhsm_log INFO] MainProcess(48577):MainThread @main.py:main:164 - Using reporter_id='apsrp09228-b6ef2a6a5df846b6b31943daaa99835a' 2019-09-03 12:31:01,197 [rhsm.https DEBUG] MainProcess(48577):MainThread @https.py:<module>:56 - Using standard libs to provide httplib and ssl 2019-09-03 12:31:01,206 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @virt.py:run:407 - Thread 'apsep9169' started 2019-09-03 12:31:01,207 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_prepare:130 - Log into ESX 2019-09-03 12:31:01,561 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_prepare:133 - Creating ESX event filter Control C was pressed, but it never returns, yo 2019-09-03 12:31:18,766 [virtwho.main DEBUG] MainProcess(48577):MainThread @executor.py:terminate:225 - virt-who is shutting down 2019-09-03 12:31:18,818 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_prepare:130 - Log into ESX 2019-09-03 12:31:19,111 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_prepare:133 - Creating ESX event filter 2019-09-03 12:32:19,192 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_run:181 - Wait for ESX event finished, timeout 2019-09-03 12:33:19,282 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_run:181 - Wait for ESX event finished, timeout 2019-09-03 12:34:19,369 [virtwho.main DEBUG] MainProcess(48577):Thread-2 @esx.py:_run:181 - Wait for ESX event finished, timeout Q4 - If yes to Q3, then please attach the screenshot of the error message. Q5 - Since when did you start observing this issue? A5 - This happens whenever our VMWare team moves things around and we are left with an empty vCenter. This has been going on for years. Q6 - Did you upgrade the Satellite Server after which this issue started to appear? or was it present even before the upgrade? A6 - Again this doesn't matter what version of Satellite, it never gets far enough to even talk to Satellite.