Bug 1169390

Summary:	content host reported by virt-who does not coincide with content host of hypervisor
Product:	Red Hat Satellite	Reporter:	David Juran <djuran>
Component:	Subscription Management	Assignee:	Michael Stead <mstead>
Status:	CLOSED DUPLICATE	QA Contact:	Katello QA List <katello-qa-list>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	Unspecified	CC:	ahumbe, bbuckingham, bkearney, cwelton, dgoodwin, fdeutsch, tomckay
Target Milestone:	Unspecified	Keywords:	Reopened, Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
URL:	http://projects.theforeman.org/issues/9383
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-04-08 17:46:02 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:

Description David Juran 2014-12-01 14:27:29 UTC

Description of problem:
We are running RHEV with RHEL hosts as hypervisors. The RHEL hosts are registered in the Satellite 6, so they have associated content_host records named after their host names. 
When connecting virt-who to probe this RHEV installation, virt-who will create an additional set of content_hosts, this time named with a UUID. This second set of content hosts should in my opinion not be created but virt-who should rather fold in it's findings into the existing content_hosts.

Version-Release number of selected component (if applicable):
Satellite-6.0.6 on RHEL7

How reproducible:
Every time

Steps to Reproduce:
1. Register a RHEL host acting as a RHEV hypervisor into a satellite 6
2. Enable virt-who
3. Do note how an extra content host has shown up.

Expected results:
virt-who should add it's findings into the already existing content host

Comment 1 RHEL Program Management 2014-12-01 14:53:47 UTC

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 4 Tom McKay 2015-02-13 20:55:50 UTC

@dgoodwin - is this fixed in a newer version of virt-who?

Comment 5 Tom McKay 2015-02-13 20:56:11 UTC

Created redmine issue http://projects.theforeman.org/issues/9383 from this bug

Comment 6 Devan Goodwin 2015-02-19 19:44:13 UTC

I'm afraid I'm not sure how this is supposed to work with virt-who. Radeck: is this a situation where virt-who should be running on each individual hypervisor?

The bulk update virt-who mode is assumed to be running in an environment where the hosts are third-party and not already registered to Satellite afaik.

Comment 7 Devan Goodwin 2015-02-27 13:51:37 UTC

I think we can probably close this, I believe the solution here is to install and start virt-who service on each hypervisor host. No configuration should be necessary for virt-who, out of the box it should know how to just report guest IDs for that hypervisor.

The mode in use in original report is (I believe) intended for deployments where the hypervisors are not registered to the entitlement platform. (ESX, presumably some RHEV installs as well) If they are registered, virt-who service knows how to report for just the host it's running on.

Tentatively closing, Radeck may be able to confirm but this is the best information I have available right now.

Comment 8 Devan Goodwin 2015-03-02 19:43:02 UTC

Reopening, it appears virt-who is not installed on RHEVB hypervisors. (via Thomas Dosek) We need to either install virt-who there, and verify it is capable of reporting the hypervisors ID, or find a way to implement some magic in virt-who to merge consumer records reported by virt-who with those actually registered. (which seems like it will be quite challenging)

Adding Fabian Duetsch, Fabian could you help us confirm if this could/should be done?

Comment 9 Devan Goodwin 2015-04-08 17:46:02 UTC


*** This bug has been marked as a duplicate of bug 1209608 ***