Hide Forgot
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): virt-who-0.12-2.el6_6sat.noarch
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