Bug 1158859

Summary: virt-who uses wrong server when connecting to satellite
Product: Red Hat Enterprise Linux 7 Reporter: Radek Novacek <rnovacek>
Component: virt-whoAssignee: Radek Novacek <rnovacek>
Status: CLOSED ERRATA QA Contact: Li Bin Liu <liliu>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.1CC: ekin.meroglu, gxing, liliu, matthew.lesieur, mfuruta, ovasik, pwayper, rnovacek, shihliu
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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.
Story Points: ---
Clone Of:
: 1199397 (view as bug list) Environment:
Last Closed: 2015-03-05 10:23:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1199397    
Attachments:
Description Flags
Debug log for 0.11-4.el7
none
Debug log for 0.8-15.el7_0
none
Satellite 5 screenshot with 0.8-15.el7
none
Satellite 5 screenshot with 0.11-4.el7 none

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:
https://git.fedorahosted.org/cgit/virt-who.git/commit/?id=ea34f2538726aa5b622eaab128edabc6c9feb77a

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

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   

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

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,

Paul

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.

https://rhn.redhat.com/errata/RHSA-2015-0430.html