Bug 1311218 - SSA fails for vsphere55's templates
SSA fails for vsphere55's templates
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: SmartState Analysis (Show other bugs)
Unspecified Unspecified
high Severity high
: GA
: 5.7.0
Assigned To: Jerry Keselman
Satyajit Bulage
: ZStream
Depends On:
Blocks: 1351331 1351334
  Show dependency treegraph
Reported: 2016-02-23 10:40 EST by Vadim Rutkovsky
Modified: 2016-07-13 16:03 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1351331 1351334 (view as bug list)
Last Closed: 2016-07-13 16:01:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
vim.log (7.29 KB, text/plain)
2016-02-23 10:40 EST, Vadim Rutkovsky
no flags Details

  None (edit)
Description Vadim Rutkovsky 2016-02-23 10:40:11 EST
Created attachment 1129823 [details]

Description of problem:
VIX_E_HOST_NETWORK_CONN_REFUSED error appears when template is scanned

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Add SmartProxy role to the server
2. Add vsphere55 provider and install vddk
3. Set credentials for hosts
4. Run SSA on template

Actual results:
Error occurs - see vim.log attached

Expected results:
Template is scanned correctly

Additional info:
Comment 1 Vadim Rutkovsky 2016-02-23 12:08:06 EST
jfyi it seems to work fine on vsphere6
Comment 8 Satyajit Bulage 2016-07-01 03:49:08 EDT
Unable to test this until bug 1351716 is fixed.
Comment 9 Jerry Keselman 2016-07-01 09:23:55 EDT
Why?  What does that have to do with being unable to run SSA on a Template on Vcenter 5.5?
Comment 10 Jerry Keselman 2016-07-01 09:24:07 EDT
Why?  What does that have to do with being unable to run SSA on a Template on Vcenter 5.5?
Comment 12 Satyajit Bulage 2016-07-05 03:00:12 EDT
Hello Jerry,

I sent an email to you with required credentials.
I am able to reproduce it on Vcenter 5.5 using vddk 5.5.4

Satyajit Bulage
Comment 13 Jerry Keselman 2016-07-05 07:43:50 EDT
Thank you Satyajit.  I received the email.  Can you also send me the credentials for the appliance on which you are reproducing the issue?  Thank you.
Comment 14 Jerry Keselman 2016-07-05 07:44:00 EDT
Thank you Satyajit.  I received the email.  Can you also send me the credentials for the appliance on which you are reproducing the issue?  Thank you.
Comment 15 Jerry Keselman 2016-07-05 07:51:57 EDT
Satyajit never mind about the appliance.  I just reproduced against the given template using an upstream appliance.  I have run this successfully on a different Vcenter 5.5 provider and template so I wonder if this is an environmental issue.  I will continue to investigate.
Comment 17 Jerry Keselman 2016-07-06 15:17:12 EDT
I received the credentials from Jeff Teehan.

This is an environmental issue.  During refresh the VCenter provider is returning a fully qualified hostname for the ESX hosts used to scan the templates.  However when running SSA on templates, this particular VCenter provider is returning a short hostname to reference the template on the datastore.  This short name is known to the Vcenter server (its pingable from the server) but not from the appliance.  Hence when the appliance attempts to access the template it receives the error in the description above.  When we run VM SSA it does not go through Vcenter by default with scan_via_host set to true so we would not run into this issue.

When we run SSA on templates on a different Vcenter 5.5 provider set up by development we do not run into this issue - the Vcenter server is returning the fully qualified ESX hostname in this case.
Comment 18 Jerry Keselman 2016-07-06 15:18:15 EDT
We do need to determine how the Vcenter server is configured to cause this issue so I will leave this ticket open for now.  Once we get more info about the configuration this BZ will be closed.
Comment 19 Jerry Keselman 2016-07-13 16:01:49 EDT
This Vcenter server has the following /etc/hosts file:
vcenter55u1:~ # cat /etc/hosts	cfme-esx-55-01 cfme-esx-55-01.cfme.lab.eng.rdu2.redhat.com      cfme-esx-55-02 cfme-esx-55-02.cfme.lab.eng.rdu2.redhat.com      cfme-esx-55-03 cfme-esx-55-03.cfme.lab.eng.rdu2.redhat.com	cfme-esx-55-04 cfme-esx-55-04.cfme.lab.eng.rdu2.redhat.com  vcenter55u1.cfme.lab.eng.rdu2.redhat.com vcenter55u1 localhost
::1     vcenter55u1.cfme.lab.eng.rdu2.redhat.com vcenter55u1 localhost ip6-localhost ip6-loopback

At issue is this - the VCenter server looks up a hostname for the IP address of one of the ESX servers in question, and passes back the first name it finds in the VDDK protocol.  The first names in the file are aliases that are not known by the appliance.  The appliance does not know how to talk to "cfme-esx-55-01 ... 04".  So we get the VIX_E_HOST_NETWORK_CONN_REFUSED error.  If, for instance, I put those aliases in a host file on the appliance, everything works.

On another Vcenter 5.5 server that does NOT put the ESX host entries in the /etc/hosts file, everything works fine also.

First, I would not bother with /etc/hosts - I would let DNS do its job.  Second, if you really want to put the alias in there - then put it *AFTER* the fully qualified name.

I am closing this BZ as an environmental issue.

Note You need to log in before you can comment on or make changes to this bug.