I’m still on my VMware Cloud Foundation v3.9 journey. My latest task was to connect my vRealize Components to my Workload Domains (WLDs). In part 2 I deployed vRealize Log Insight (vRLI) and vRealize Operations (vROps), and then in part 3 and part 4, I rolled out vRealize Automation. Now I wanted to connect them to the WLDs that I had rolled out previously. SDDC Manager makes this really easy. In just a couple of clicks I had connected vRLI and vROps to both VI WLDs. However, on trying to connect my vRealize Automation (vRA) 7.6 to my WLDs, I ran into an issue. I followed the same steps as I did for vRLI and vROps:
At this point, the following message was displayed:- vRealize Automation integration with NSX-T domain is currently not supported through VMware Cloud Foundation.
Hmm – OK. I guess if I had read the documentation, I would have come across the following statement:
This version of Cloud Foundation (v3.9) does not support connecting vRealize Automation to NSX-T workload domains through the SDDC Manager Dashboard. Use the vRealize Automation console instead.
Step 1 – Add WLD vCenter Endpoints from vRA Console
No big deal. This should be just a matter adding the Endpoints via the vRA console, as suggested in the docs. I logged onto the vRA console, navigated to Infrastructure, selected Endpoints and then clicked on the + New to add it.
Next, I select Virtual > vSphere (vCenter) and now I can add the details of my vCenter (the vCenter servers in my WLDs). A handy tip is to use TEST CONNECT to ensure I can reach my vCenter (or more precisely, my vSphere agent for that vCenter. Unfortunately, when I did that test, I got a failure stating that “The vSphere agent does not exist or may not be running“.
Ah, so it would appear that the Proxy configuration has not been done, and I assume this part of the automation is typically taken care of by SDDC Manager automatically. As part of the deployment of vRA, we rolled out 2 x Proxy VMs. My next step is to deploy the vSphere proxy agent and do the appropriate proxy configuration in the Proxy VMs.
Step 2 – Deploy Proxy Agents on Proxy VM
I Remote Desktop’ed to my first Proxy VMs, opened a browser and pointed it to my vRA Load Balancer/VIP URL. I knew I could deploy a proxy agent from the IaaS Installer under the vRA component installation page, as shown below:
However, when I clicked on it, it seems the page was not found:
After discussing it with my colleague, Gary Blake, he suggested pointing directly to a vRA appliance rather than the Load Balancer/VIP. That approach worked (cheers Gary). I also spoke to a Jad El-Zein who knows vRA inside-out. The reason for this behaviour is that we do not load balance port 5480. We’re going to discuss some options to address this going forward – watch this space. But for now, the way forward is to point directly to one of the three vRA appliances that were part of the initial deployment.
I proceeded to download the IaaS Installer and start the Proxy deployment on this Proxy VM. This is the welcome page:
Next, accept the EULA:
Provide root credentials for the appliance, and Accept the certificate:
For the Installation Type, select Custom Install, and under Component Selection, click Proxy Agents:
Supply passwords for the vRA Service account that you created for the initial deployment ( see part 4, step 6 ):
Finally, provide an Agent name, vSphere Endpoint name and the FQDN of the hosts that provide the Manager Service and the Model Manager Web Service. When we provided these in the initial deployment, they were provisioned as appliances along with the Load Balancers. It is the Load Balancer FQDNs that are provided here. You can also click on the Test link to verify that the hosts are reachable.
Since I have a second WLD vCenter, I can go ahead and add a proxy agent for that as well. The only thing different is the Agent name and the vSphere Endpoint name. Click Add to add it to the list:
Click Next, and let the agent install process take place. And that completes the Proxy Agent deployment.
Since we actually deployed two Proxy VMs during the initial deployment, you can simply repeat the proxy agent setup with the same names on the other Proxy VM, and vRealize Automation will automatically HA them. The proxies are load balanced via the vRA management plane (vRA routes access to the appropriate proxy). I’m not going to go through those steps here. Instead I am going to return to the vRA Console and see if I can now add the Endpoints.
Step 3 – Add WLD vCenter Endpoints from vRA Console (Revisited)
Going back to where we were before, make sure that name matches that chosen as the Endpoint name when deploying the Proxy Agent on the Proxy VM. In my case, these were vcsa-04 and vcsa-06 respectively.
And now the TEST CONNECTION succeeds and I am able to add both of my WLD vCenter Servers as Endpoints:
That’s the first step completed. Now I can go ahead and do the remaining tasks that will enable me to provision workloads from vRealize Automation v7.6 to my VMware Cloud Foundation v3.9 VI Workload Domains.
- You cannot connect workload domains to vRA via SDDC Manager is NSX-T has been chosen as the network platform. You can only connect them via the vRA console.
- The Proxy Agents will need to be configured on the Proxy VMs.
- When downloading the IaaS installer, don’t use the vRA Load Balancer VIP. Use the URL from one of the vRA appliances.
- Remember that the Endpoint names must match in the Proxy Agent and in the vRA Console.
You can see all parts of my VCF 3.9 deployment journey here.