Red Hat Bugzilla – Bug 1311218
SSA fails for vsphere55's templates
Last modified: 2016-07-13 16:03:22 EDT
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):
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
Error occurs - see vim.log attached
Template is scanned correctly
jfyi it seems to work fine on vsphere6
Unable to test this until bug 1351716 is fixed.
Why? What does that have to do with being unable to run SSA on a Template on Vcenter 5.5?
I sent an email to you with required credentials.
I am able to reproduce it on Vcenter 5.5 using vddk 5.5.4
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.
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.
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.
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.
This Vcenter server has the following /etc/hosts file:
vcenter55u1:~ # cat /etc/hosts
10.8.58.12 cfme-esx-55-01 cfme-esx-55-01.cfme.lab.eng.rdu2.redhat.com
10.8.58.13 cfme-esx-55-02 cfme-esx-55-02.cfme.lab.eng.rdu2.redhat.com
10.8.58.15 cfme-esx-55-03 cfme-esx-55-03.cfme.lab.eng.rdu2.redhat.com
10.8.58.10 cfme-esx-55-04 cfme-esx-55-04.cfme.lab.eng.rdu2.redhat.com
127.0.0.1 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.