Bug 1169390 - content host reported by virt-who does not coincide with content host of hypervisor
Summary: content host reported by virt-who does not coincide with content host of hype...
Keywords:
Status: CLOSED DUPLICATE of bug 1209608
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Subscription Management
Version: Unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: Unspecified
Assignee: Michael Stead
QA Contact: Katello QA List
URL: http://projects.theforeman.org/issues...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-01 14:27 UTC by David Juran
Modified: 2017-02-23 20:45 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-08 17:46:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 9383 0 Normal Closed content host reported by virt-who does not coincide with content host of hypervisor 2020-07-01 15:21:46 UTC

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 ***


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