Getting started with VCF Part 14 – Connecting vRA to NSX-T WLD (alternate method)

In my most recent VMware Cloud Foundation post (part 13), I highlighted the fact that if you used NSX-T as the networking platform for your workload domain (WLD), you could not attach vRealize Automation (vRA) to such a WLD via SDDC Manager. In that previous post, I showed how to manually deploy the vRA proxy agents on the Proxy VMs. These Proxy VMs were already deployed via SDDC Manager as part of the overall vRA deployment through SDDC Manager, but the agents were not installed at this point. If NSX-V was used as the networking platform for the WLD, then this would be done automatically when vRA is connected to the WLD. However this is not supported with NSX-T using VCF v3.9.

After posting my procedure, another method was brought to my attention by my colleague Wesley Van Ede. Wesley highlighted the fact that you could scale your vRA environment via the vRealize Suite Lifecycle Manager (vRSLCM). The documentation describing how to use vRSLCM to scale the vRA deployment is here. However, it is not 100% intuitive in some places (especially around certificates), so I thought I’d add some colour to an alternate approach for getting the proxy agents deployed on your vRA Proxy VMs by scaling your vRA deployment via vRSLCM. This means that vRA can in turn connect to your endpoints in your NSX-T based VCF workload domains.

To begin, login to the vRSLCM environment, click on Environments then select the vRA_environment tile and click on View Details, as shown below. Now click on the three vertical dots to the right of the vRA icon.

This will display a drop down menu. Select the first item in the menu which is +Add Components:

This is where we begin to scale out the vRA environment. The very first screen needs to be populated with Infrastructure Details. Many of these will already be auto-populated. However, Folder, Resource Pool, Network and NTP server will need to be added. You can also change the datastore if you wish, but since I have a vSAN datastore, I will leave this as it is. Once done, click the Next button in the top right (which will turn green when the window is fully populated):

Next screen is Networking. This is relatively straight-forward to populate, with the usual DNS, netmask and gateway information required.

Now we get to the Component section. There are two parts; Product Properties and Components. Again, many of the fields will be pre-populated, but this section is a bit more challenging as the Certificate Id requires a certificate file that includes the vRA certificate chain, root CA certificate and private key. All of these files were created individually back in Part 3, Step 7 through the generates_certificates.sh script which is run at the SDDC Manager command line. However, these were all created as separated PEM files. What must be done to satisfy the vRSLCM wizard at this point is a merger of these 3 files together into a single certificate file. The order of the entries in the new merged certificate file is also important. They need to appear in the following order:

  1. Top – Certificate Chain (server.pem)
  2. Middle – Root CA (rootca.pem)
  3. Bottom – Private Key (private_key.pem)

Since the Proxy VM has already been deployed as part of the vRA deployment, we just need to select PROXY-AGENT-VSPHERE as the component that we wish to scale. Finally provide the hostname, IP address and VM name in the Components Section to finish this part of the wizard.

The next check is the precheck. However, there is an expected soft warning about the admin email. This can be ignored, as long as everything else succeeds.

Now, before we submit the scale out request, we need to disable the precheck or it will fail again on the admin email precheck. Disable the precheck from running during the submission as show below:

We can now monitor the request in vRSLCM:

And hopefully it will succeed as shown below:

The final check is to verify that the proxy agent is running on the proxy VM. Logon to the Proxy VM, launch the Windows task manager and select Services to verify:

The name of the proxy agent is “proxy-agent-vsphere“. You can see this in the task manager view above. This is the same name that must be used for the Endpoint when you add the endpoints to the WLD vCenter Server(s) in the vRA Console, as shown below:

OK – so now the next question – which method is better? The one shown here or the one outlined previously in part 13? I’m inclined to think that using vRSLCM to scale vRA here is easier, even though the merging of the certificates is a bit of a PITA. What we’re trying to figure out is if there is any impact on future upgrades or patching of vRA by vRSLCM if the proxy agent is installed manually and not installed via vRSLCM (an interesting point raised by Wesley). We have some engineers evaluating that presently, and I’ll update this post as soon as I get a confirmation.