Bug 1158859 - virt-who uses wrong server when connecting to satellite
Summary: virt-who uses wrong server when connecting to satellite
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-who
Version: 7.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Radek Novacek
QA Contact: Li Bin Liu
Depends On:
Blocks: 1199397
TreeView+ depends on / blocked
Reported: 2014-10-30 11:54 UTC by Radek Novacek
Modified: 2019-09-12 08:03 UTC (History)
9 users (show)

Fixed In Version: virt-who-0.11-3.el7
Doc Type: Bug Fix
Doc Text:
Cause: virt-who uses wrong information for connecting to the satellite 5. Consequence: virt-who is not able to connect to the satellite 5 server. Fix: Use correct parameter when connecting to satellite 5. Result: virt-who can successfully connect to satellite 5.
Clone Of:
: 1199397 (view as bug list)
Last Closed: 2015-03-05 10:23:31 UTC
Target Upstream Version:

Attachments (Terms of Use)
Debug log for 0.11-4.el7 (14.46 KB, text/plain)
2014-11-25 16:53 UTC, Ekin Meroglu
no flags Details
Debug log for 0.8-15.el7_0 (14.39 KB, text/plain)
2014-11-25 16:54 UTC, Ekin Meroglu
no flags Details
Satellite 5 screenshot with 0.8-15.el7 (136.90 KB, image/png)
2014-11-25 16:55 UTC, Ekin Meroglu
no flags Details
Satellite 5 screenshot with 0.11-4.el7 (136.75 KB, image/png)
2014-11-25 16:56 UTC, Ekin Meroglu
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0430 normal SHIPPED_LIVE Moderate: virt-who security, bug fix, and enhancement update 2015-03-05 14:52:46 UTC

Description Radek Novacek 2014-10-30 11:54:03 UTC
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:

Comment 1 Radek Novacek 2014-11-05 11:56:26 UTC
Fixed in virt-who-0.11-3.el7

Comment 3 xingge 2014-11-24 07:21:32 UTC
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?

Comment 4 Ekin Meroglu 2014-11-24 20:20:23 UTC
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.

Comment 5 Radek Novacek 2014-11-25 06:52:47 UTC

thanks for the offer, here is the latest virt-who package:


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.

Comment 6 Ekin Meroglu 2014-11-25 16:52:54 UTC
Hi Radek,

I tried with virt-who-0.11-4.el7.noarch.rpm you've provided, and I can confirm   


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.


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


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


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'


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.

Comment 7 Ekin Meroglu 2014-11-25 16:53:59 UTC
Created attachment 961284 [details]
Debug log for 0.11-4.el7

Comment 8 Ekin Meroglu 2014-11-25 16:54:33 UTC
Created attachment 961285 [details]
Debug log for 0.8-15.el7_0

Comment 9 Ekin Meroglu 2014-11-25 16:55:31 UTC
Created attachment 961286 [details]
Satellite 5 screenshot with 0.8-15.el7

Comment 10 Ekin Meroglu 2014-11-25 16:56:06 UTC
Created attachment 961287 [details]
Satellite 5 screenshot with 0.11-4.el7

Comment 11 Radek Novacek 2014-11-26 08:23:57 UTC
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.

Comment 12 Paul Wayper 2014-12-07 23:55:13 UTC
Can this fix please also be backported to the other versions of RHEL on which virt-who is used?

Thanks in advance,


Comment 13 Liushihui 2014-12-22 08:48:08 UTC
According to comment 6 , it should have been fixed on virt-who-0.11-4.el7.noarch.rpm. Therefore, virify it on this version.

Comment 15 errata-xmlrpc 2015-03-05 10:23:31 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.