This blogpost will discuss an error me and my colleagues recently encountered when doing a vRealize Automation version 7 (vRA 7) distributed installation at a customer. The error was thrown during one of the last steps in the installation process.
The design of this installation was fairly straightforward. Two load balanced vRA appliances were used. The IaaS part of vRA consisted of two Windows 2012 R2 virtual machines (one for the web and manager part, one for the DEM workers).
Even though all prerequisites were checked and met, the error popped up during one of the last steps of the installation.
During installation, the second vRA appliance needs to be added to the cluster. But during this step the installer throws an error and gives a “Failed” indication. The error messages indicate that the error has something to do with the communication between the virtual appliance and the management agent.
Other messages that may occur in the logs of the first vRA appliance can be the following:
2016-02-17T23:51:30.202922+00:00 vra01 sfcb: — SSL_ERROR_SYSCALL during handshake: EOF occurred: client may have aborted
2016-02-17T23:51:30.203040+00:00 v0000vra001 sfcb:
2016-02-17T23:51:30.203049+00:00 v0000vra001 sfcb: ** /build/mts/release/bora-3190002/studio/src/vami/apps/sfcb/1.4.9/httpAdapter.c:1681 SSL_ERROR_SYSCALL error during SSL handshake — exiting
After a bit of troubleshooting the solution appeared very simple: choose a password with less or better yet no special characters. The password used for the root account for the vRA appliances was generated by the customer and contained special characters. The password consisted of hash tags (#), commas (,), forward slashes (/), exclamation marks (!) and dollar signs ($). At this point it is unclear which specific character or combination of characters caused the problem. However, when we generated a password with only uppercase letters, lowercase letters and numbers everything worked.
When receiving an error during a distributed vRA 7 installation on the cluster join step for the additional vRA appliances, it is advised to verify the complexity of the appliances root passwords and check for special characters when all other troubleshooting steps bring no avail.
I would like to thank my colleagues William De Keyzer (@WilliamDeKeyzer) and Matthieu Pieters for the fun we had debugging the issue.
It appears that the issue described in this post is known to VMware for vRA version 7.0. VMware support indicates that following characters should not be used in vRA 7.0 passwords:
; * < > & ” % ? ^ ‘ $ @ ( ),`
The issue is planned to be fixed in a future release.