Changing component to Red Hat Satellite 6 for further examination, virt-who should be fairly ready to be deployed on Sat 6.

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.

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.

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.

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.

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.

Hi,

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:

/etc/virt-who.d/test.conf
~~~~~~~~~~~~~~~~~~~~~~~~~
[test-esx]
type=esx
server=vcenter.example.com
username=admin
encrypted_password=b7f6e174d6fd5121706786aa4fe91189
owner=ORG
env=ENV
rhsm_hostname=satellite61.example.com
rhsm_username=admin
rhsm_encrypted_password=fabf652ff4b3f6945f352bad94a1ff93
rhsm_prefix=/rhsm

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

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 
[test-esx]
type=esx
server=<REDACTED>
username=root
password=<REDACTED>
owner=Default_Organization
env=Library
rhsm_hostname=sat-snap-rhel7.example.com
rhsm_username=admin
rhsm_encrypted_password=<REDCATED>
rhsm_prefix=/rhsm

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

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-2016:1501