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.
Bug 1748677 - virt-who hangs on empty vCenter
Summary: virt-who hangs on empty vCenter
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virt-who
Version: 8.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 8.2
Assignee: William Poteat
QA Contact: Eko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-04 01:29 UTC by Anand Jambhulkar
Modified: 2023-09-07 20:32 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 15:37:04 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github candlepin virt-who pull 240 0 'None' closed 1748677: Improved timeout for esx 2020-11-19 12:28:54 UTC
Red Hat Issue Tracker RHELPLAN-28472 0 None None None 2023-05-17 11:55:14 UTC
Red Hat Product Errata RHBA-2020:1592 0 None None None 2020-04-28 15:37:18 UTC

Description Anand 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.
Comment 4 Chris Snyder 2019-09-09 18:23:33 UTC 
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!
Comment 6 William Poteat 2019-09-12 17:30:30 UTC 
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?
Comment 13 errata-xmlrpc 2020-04-28 15:37:04 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.