Red Hat Bugzilla – Bug 1158859
virt-who uses wrong server when connecting to satellite
Last modified: 2016-11-30 19:33:27 EST
virt-who uses value of --esx-server command line option instead of value of --satellite-server option. This causes that virt-who tries to report host/guest association to the esx server instead of satellite and naturally it fails. There is an upstream patch for this issue: https://git.fedorahosted.org/cgit/virt-who.git/commit/?id=ea34f2538726aa5b622eaab128edabc6c9feb77a
Fixed in virt-who-0.11-3.el7
We now handling this bug, but we did have a useable Satellite server, and we learning to install the server. Can someone give us a useable satellite server so that we can verify the bug?
Can we download virt-who-0.11-3.el7 package from a public repo? I can always try and report back, if you can supply the binaries including the fix.
Ekin, thanks for the offer, here is the latest virt-who package: https://rnovacek.fedorapeople.org/virt-who-0.11-4.el7.noarch.rpm Please try it and let me know if it fixes the issue. Disclaimer: this is not an official package and shouldn't be used in production environment.
Hi Radek, I tried with virt-who-0.11-4.el7.noarch.rpm you've provided, and I can confirm --satellite-server command line option works as intended: # virt-who -d -o --satellite --satellite-server=satellite.example.com --satellite-username=admin --satellite-password=PASS --esx --esx-owner=linuxera --esx-env=linuxera --esx-server=https://vcenter.example.com:443 --esx-username=administrator --esx-password=PASS INFO: Using commandline or sysconfig configuration ("esx" mode) DEBUG: Initializing satellite connection to https://satellite.example.com/XMLRPC INFO: Initialized satellite connection INFO: Sending update in hosts-to-guests mapping: ... ... ... ... Also the hypervisor entries in Satellite 5 server were created successfully. But we have another problem introduced with this update: ** In the previous version of virt-who (virt-who-0.8-15.el7_0.noarch), the hypervisors were named according to their type - e.g. "esx hypervisor ABCDE..." and "rhevm hypervisor FGHIJ...". Please see the name below - "esx hypervisor 30303...." and the attachment "virt-who-0.8-15.el7.png" for their naming convention in Satellite 5 GUI. ----8<---------- DEBUG: Sending plan: [[0, 'exists', 'system', {'uuid': '0000000000000000', 'identity': 'host'}], [0, 'crawl_began', 'system', {}], [0, 'exists', 'domain', {'state': 'running', 'memory_size': 0, 'name': u'VM from esx hypervisor 30303734-3536-5a43-3233-303130364c34' ... ----8<---------- ** When using this new version (virt-who-0.11-4.el7.noarch.rpm) both esx and rhevm hypervisors are named as "None hypervisor". Again, please see name below - "None hypervisor 30303...." and the attachment "virt-who-0.11-4.el7.png" for their naming convention in Satellite 5 GUI. ----8<---------- DEBUG: Sending plan: [[0, 'exists', 'system', {'uuid': '0000000000000000', 'identity': 'host'}], [0, 'crawl_began', 'system', {}], [0, 'exists', 'domain', {'state': 'running', 'memory_size': 0, 'name': u'VM from None hypervisor 30303734-3536-5a43-3233-303130364c34' ----8<---------- Also attached are the full debug logs for the both versions, esx and rhevm sessions. Please feel free to contact me for any extra info you may need - I have a mixed sat5 / sat6 + esx / rhevm environment for testing.
Created attachment 961284 [details] Debug log for 0.11-4.el7
Created attachment 961285 [details] Debug log for 0.8-15.el7_0
Created attachment 961286 [details] Satellite 5 screenshot with 0.8-15.el7
Created attachment 961287 [details] Satellite 5 screenshot with 0.11-4.el7
Hi Ekin, thanks for your report, I'm glad that new version of virt-who really fixes the issue. I've created a new bug for the issue you've reported: bug 1168122, to ensure it gets fixed in the RHEL-7.1 timeframe.
Can this fix please also be backported to the other versions of RHEL on which virt-who is used? Thanks in advance, Paul
According to comment 6 , it should have been fixed on virt-who-0.11-4.el7.noarch.rpm. Therefore, virify it on this version.
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://rhn.redhat.com/errata/RHSA-2015-0430.html