Bug 1209467 - [RFE] Allow virt-who to be installed on a Satellite 6 instance
Summary: [RFE] Allow virt-who to be installed on a Satellite 6 instance
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Subscription Management
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
medium vote
Target Milestone: Unspecified
Assignee: Katello Bug Bin
QA Contact: Stephen Benjamin
Depends On:
TreeView+ depends on / blocked
Reported: 2015-04-07 12:32 UTC by Rich Jerrido
Modified: 2021-08-30 11:38 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
With this release, the virt-who agent can now be installed on the same machine where the main Satellite Server is hosted.
Clone Of:
Last Closed: 2016-07-27 09:15:00 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SAT-4757 0 None None None 2021-08-30 11:38:41 UTC
Red Hat Knowledge Base (Solution) 2109221 0 None None None 2016-01-06 05:41:48 UTC
Red Hat Product Errata RHBA-2016:1501 0 normal SHIPPED_LIVE Red Hat Satellite 6.2 Capsule and Server 2016-07-27 12:28:58 UTC

Description Rich Jerrido 2015-04-07 12:32:40 UTC
Description of problem:

As a user of Red Hat Satellite 6, I would like the ability to install virt-who on a Red Hat Satellite 6 instance, so that it can report the host-guest mappings of guests/hypervisors. 

Currently today, I have to provision a host that is registered to the Satellite 6 instance and configure virt-who there so that I can properly utilize VDC and unlimited subs. 

Ideally, I would like to have virt-who on the Satellite because:

* The Satellite usually has the required firewall ports opened between it and the virtualization platform (vSphere, RHEV, hyper-v), as this is needed for Satellite's compute providers. 

* It greatly simplifies the architecture. There are fewer steps required to allow the end-user to use their VDC subs. (Effectively, it becomes install Satellite, install & configure virt-who)

* Lastly, the virt-who package can be delivered in a Satellite tools repository or similar, so that it can be incremented out of band. 

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

Comment 1 Radek Novacek 2015-04-07 12:40:17 UTC
Changing component to Red Hat Satellite 6 for further examination, virt-who should be fairly ready to be deployed on Sat 6.

Comment 2 RHEL Program Management 2015-04-07 12:53:15 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 David Caplan 2015-04-07 14:37:17 UTC
The best path here is to incorporate virt-who directly into the VMware and RHEV compute resource. Virt-who requires credentials to interact with vCenter/RHEVM, so the workflow with a compute resource is more natural for Satellite UXD.

Comment 5 Rich Jerrido 2015-04-09 22:55:40 UTC
After working on this a bit more, I wanted to provide additional clarity as the the original request. 

Currently today, virt-who uses the identity certificate of the registered host AND the hostname specified in rhsm.conf to update host/guest mappings. In the case of Satellite 6, many Satellite 6 systems are registered via RHSM, so this points to subscription.rhn.redhat.com. Thus running virt-who on the Satellite doesn't work properly unless the Satellite is registered to itself. 

Providing the option to provide a user-specified hostname as part of the virt-who configuration would satisfy this request. Optimally, the hostname would be configurable in each stanza provided in /etc/virt-who.d/. In addition to the original request (allowing virt-who to run on a Satellite 6 instance), It will also allow:

* The ability to run virt-who on any RHEL host (if used in conjunction with the rhsm_username & rhsm_password directives), regardless of if it is registered (and how it is registered)
* The ability for a singular virt-who instance to report to multiple Satellites. 
* The ability for a singular virt-who instance to support multiple organizations on a single Satellite instance.

Comment 7 cyril.cordouibarzi 2015-06-02 09:30:43 UTC
Virt-who is currently unusable in our company, for security reasons and also because a single VM cannot handle the load of searching itself in hundreds of hosts containing thousands of guests …

The Satellite 6 server on another hand is generally sized for that kind of process and as David Caplan stated, it is only logical to use credentials and information from compute resources to find VM and handle subscriptions, which is one of its role after all.

As thing are handled now, it is impossible to use Satellite 6 without this feature for a large company.

Comment 8 David Juran 2015-06-04 11:58:45 UTC
Do note that if you register the satellite to itself, as described in https://access.redhat.com/articles/1452373 you can run virt-who on the the satellite host itself.

Comment 9 Ekin Meroglu 2015-08-25 21:34:28 UTC

As of virt-who 0.14, I was able to install and run virt-who on the satellite server, without registering satellite 6.1 to itself. The trick is to "tell" virt-who to report to the satellite itself, regardless of the systems original subscription - i.e. subscription.rhn.redhat.com:


Btw, virt-who 0.14 is a very big improvement: scanning/reporting speed is very good (compared to 0.11 which was available in Sat 6.0) and new options are very flexible. 

But still, I'm all for incorporating virt-who with the compute resources (comment 4) - right now we are simply duplicating vmware / rhev connection workflow, and most of the time not in the best way...

Comment 16 Stephen Benjamin 2016-07-11 18:15:00 UTC
Verified in Satellite 6.2 Snap 19.0.

My test Satellite is not registered to itself, and has a configuration for virt-who like this:

[root@sat-snap-rhel7 virt-who.d]# cat test.conf 

Running `virt-who -o` (one shot) results are successfully uploaded to the sat-snap-rhel7 server without it being registered to itself.

Comment 18 errata-xmlrpc 2016-07-27 09:15:00 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.


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