vRealize Automation 7 – Error – Unable to get metadata

So today my heart sunk when I tried to log into the vRA 7 IaaS portal and was presented with this lovely message:

Now, I had just recently attempted an upgrade of vRA 7.0.1 to 7.1 and failed miserably (more on that in a later post) so I had to roll back all of my changes (reverting snapshots, etc.) and brought all the services back. All seemed fine until I tried to log into the IaaS portal.

One of the first things I checked was the services registration on the vRA VAMI interface (Services tab). I thought perhaps the order of events of the rollback had skewed something. I observed the following:

So clearly something was afoot. I did a little digging and came across the following KB article:

Logging in to tenant fails after adding authenticated proxy config in VAMI in VMware vRealize Automation 7.0.x (2144067)

The interesting thing here, is that just a few hours before, I added a proxy server to the VAMI configuration in order to get the updates I needed from https://vapp-updates.vmware.com. As per the KB article I inspected the following log file:

less /storage/log/vmware/horizon/connector.log

After sifting through the log for about 10 seconds I saw this:

2016-09-02 15:54:17,743 INFO  (SimpleAsyncTaskExecutor-1) [;;] com.vmware.horizon.connector.utils.RestClient - Request failed: HTTPS_PROXY=
java.net.UnknownHostException: HTTPS_PROXY=
        at java.net.InetAddress.getAllByName0(InetAddress.java:1280)
        at java.net.InetAddress.getAllByName(InetAddress.java:1192)
        at java.net.InetAddress.getAllByName(InetAddress.java:1126)
        at org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)
        at org.apache.http.impl.conn.DefaultClientConnectionOperator.resolveHostname(DefaultClientConnectionOperator.java:259)
        at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:159)
        at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
        at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
        at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
....

Then as per the KB article I edited the following config file:

Edit /etc/sysconfig/proxy

vi /etc/sysconfig/proxy

Modify the following line to include the hostname of the VRA appliance (I did the hostname, FQDN and the shared cluster hostname just to be sure). I have modified the actual names for the purpose of this post. “localhost” and “127.0.0.1” were already present.

NO_PROXY="localhost, 127.0.0.1, vra-01, vra-01.domain.local, , vra.domain.local"

I then restarted the vRA services:

service horizon-workspace restart

As per instruction, I waited 5 minutes and sure enough all was working again.

This is one of those really silly problems which really, should not exist. What is more interesting is that the KB article states that this is related to an authenticated proxy for the appliance update downloads. I have not configured authentication for my proxy so it seems it affects regardless of how it is configured.

If someone can shed some light on why this is actually a problem, one that VMware can’t seem to solve then please let me know.