Bug 1383436

Summary:	virt-who is flooding the task list of Satellite 6
Product:	Red Hat Satellite	Reporter:	Kenny Tordeurs <ktordeur>
Component:	Other	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED ERRATA	QA Contact:	jcallaha
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	6.2.2	CC:	abalakht, aperotti, bbuckingham, bkearney, csnyder, cwelton, dcaplan, ehelms, jcallaha, ktordeur, mlele, ovasik
Target Milestone:	Unspecified	Keywords:	PrioBumpGSS, PrioBumpPM
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	virt-who-0.17-10	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1405618 (view as bug list)		Environment:
Last Closed:	2017-01-26 10:42:53 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1405618

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