Bug 1383436 - virt-who is flooding the task list of Satellite 6
Summary: virt-who is flooding the task list of Satellite 6
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Other
Version: 6.2.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent vote
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: jcallaha
URL:
Whiteboard:
Depends On:
Blocks: 1405618
TreeView+ depends on / blocked
 
Reported: 2016-10-10 15:21 UTC by Kenny Tordeurs
Modified: 2020-04-15 14:43 UTC (History)
12 users (show)

Fixed In Version: virt-who-0.17-10
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1405618 (view as bug list)
Environment:
Last Closed: 2017-01-26 10:42:53 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0197 0 normal SHIPPED_LIVE Satellite 6.2.7 Async Bug Release 2017-01-26 15:38:38 UTC

Description Kenny Tordeurs 2016-10-10 15:21:47 UTC
Description of problem:
virt-who is flooding the task list of Satellite 6

Version-Release number of selected component (if applicable):
Satellite 6.2.2

How reproducible:
100%

Steps to Reproduce:
1. Configure virt-who to report to Satellite 
2.
3.

Actual results:
See many tasks by virt-who 

Expected results:
See only 1 task every 30minutes

Additional info:
~~~
Action	State	Result	▼ Started at	Ended at	User
Hypervisors	stopped	success	2016-10-10 15:07:52 UTC	2016-10-10 15:07:53 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 14:52:50 UTC	2016-10-10 14:52:52 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 14:44:33 UTC	2016-10-10 14:44:34 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 14:37:50 UTC	2016-10-10 14:37:51 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 14:22:49 UTC	2016-10-10 14:22:52 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 14:22:02 UTC	2016-10-10 14:22:04 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 14:21:56 UTC	2016-10-10 14:21:59 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 14:07:47 UTC	2016-10-10 14:07:48 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 14:06:34 UTC	2016-10-10 14:06:36 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 13:52:46 UTC	2016-10-10 13:52:49 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 13:44:28 UTC	2016-10-10 13:44:32 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 13:37:46 UTC	2016-10-10 13:37:48 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 13:22:43 UTC	2016-10-10 13:22:46 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 13:07:43 UTC	2016-10-10 13:07:45 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 13:06:35 UTC	2016-10-10 13:06:40 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 13:06:28 UTC	2016-10-10 13:06:32 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 13:06:23 UTC	2016-10-10 13:06:26 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 13:00:13 UTC	2016-10-10 13:00:17 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 13:00:02 UTC	2016-10-10 13:00:10 UTC	virtwho
Hypervisors	stopped	success	2016-10-10 12:52:41 UTC	2016-10-10 12:52:44 UTC	virtwho
~~~

virt-who should be running every 30min but in tasks it shows up way more often which is flooding the task queue with virt-who tasks.

# grep -v "#" /etc/sysconfig/virt-who 
~~~
VIRTWHO_DEBUG=0
VIRTWHO_INTERVAL=3600
~~~

Comment 2 Brad Buckingham 2016-10-13 13:44:17 UTC
The flooding of the tasks in Satellite appears to be a side-affect of the virt-who checkins.  

Is it possible that the user has multiple virt-who servers and they are all checking in at different intervals and times?  

Has it been confirmed that a specific virt-who server is checking in more frequently than expected?

Comment 12 jcallaha 2017-01-15 18:34:56 UTC
Verified in Satellite 6.2.7 Snap 1

The hypervisors tasks does appear to be linked to vm actions (create, destroy, etc). Below is a list of hypervisor tasks. These aren't kicked off due to the virt-who interval (set to 900), but the initial checkins and then vm actions.

-bash-4.2# hammer -u admin -p changeme task list | grep -i hypervisors
d56f6858-31e0-4e69-aee3-4e8fcb16fe59 |      | admin             | 2017/01/15 18:33:44 | 2017/01/15 18:33:45 | stopped | success | Hypervisors                                                                    |            
ba5351e4-41c4-4998-b15b-64d945088719 |      | admin             | 2017/01/15 18:31:00 | 2017/01/15 18:31:01 | stopped | success | Hypervisors                                                                    |            
640a793a-aa10-454c-a89c-f3d66d62480c |      | admin             | 2017/01/15 18:19:15 | 2017/01/15 18:19:16 | stopped | success | Hypervisors                                                                    |            
6d2e51a7-b382-4575-ad77-1dbe4fb406b1 |      | admin             | 2017/01/15 18:18:12 | 2017/01/15 18:18:14 | stopped | success | Hypervisors                                                                    |            
6c95d17b-3858-4eef-a3ee-099a11a7bb5c |      | admin             | 2017/01/15 17:29:50 | 2017/01/15 17:29:51 | stopped | success | Hypervisors                                                                    |            
604486a8-795c-40ed-89d1-e161afb95254 |      | admin             | 2017/01/15 16:57:01 | 2017/01/15 16:57:09 | stopped | success | Hypervisors

Comment 14 errata-xmlrpc 2017-01-26 10:42:53 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-2017:0197


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