VCF 4.4+ and vRealize Suite Decoupling

Since the release of VCF 4.4.0.0, there has been a lot of chatter about how we can decouple or disassociate the vRealize suite from VCF and SDDC Manager, or how it is completely externally managed.
This is quite incorrect and stems from a misunderstanding of how the vRealize Suite is linked to VCF.

In this post, I will talk about how the vRealize Suite is linked to VCF and SDDC manager, and what has changed in VCF 4.4 and above.

The vRealize Suite (now known as the VMware Aria Suite) is a cloud management solution, encompassing various vRealize products that provide automation, operations, log-analytics and network insights to your environment.
The vRealize Suite Lifecycle Manager (vRSLCM) manages the deployment and lifecycle of all the vRealize products. A vRSLCM instance can be deployed in a VCF environment through the SDDC manager (screenshot above)

Historically, i.e up until VCF 4.3.x, the Bill of Materials for a given VCF version have included specific versions of the various vRealize products, namely:

• vRealize Suite Lifecycle Manager
• vRealize Operations
• vRealize Log Insight
• vRealize Automation
• Workspace ONE Access

This meant that the versions of the vRealize products were tightly integrated for a specific VCF release, and being on a version outside of that specified in the BoM was technically unsupported.
The updates/upgrades for each of the individual vRealize components was also managed by the SDDC Manager, and were performed in the order that they showed up as available, while performing updates for the management WLD.

Starting with VCF 4.4 and vRSLCM 8.6.2, the lifecycle of the vRealize Suite products are flexible, as mentioned in the VCF 4.4 Release Notes. The upgrade and deployment of the vRealize Suite products is now managed by vRSLCM itself. Additionally, the versions for the products were no longer be listed in the VCF BoM going forward.

This means that after vRSLCM has been upgraded to version 8.6.2, and upgrade for the vRealize Suite components (including vRSLCM itself) will now be updated and upgraded via the vRSLCM UI. Just like with a Non-VCF vRSLCM instance, we will have to login to the vRSLCM UI, download whatever version for whatever component we need to upgrade to, and initiate the upgrade process from vRSLCM.

A very important thing to note here:

In fact, more integration and features are being introduced to be able to better manage a VCF SDDC, for example - Managing VCF with vRealize Operations and the SDDC Health Management Pack.

There are several workflows within the SDDC Manager that have tasks and sub-tasks that leverage this intergration (even in VCF 4.4+). For example, in a VCF environment where vRLI is deployed, when we add a new host to a cluster through the SDDC manager, one of the sub-tasks are configuring the host to forward logs to vRLI. This process involves API calls from the SDDC Manager to vRLI via vRSLCM.

So what about decoupling or disassociating vRealize from SDDC/VCF?

I think a lot of this misinformation stems from this KB:
Disassociate the vRealize Suite 7.x Products from SDDC Manager in VMware Cloud Foundation 3.10.x & 3.11 (81718)

The KB talks about a process to disassociate vRealize Suite 7.x products from the SDDC Manager in VCF 3.10 and 3.11. The process involves running a bash script that is attached to the KB. The script basically contains a bunch of psql commands that delete various entries from the SDDC Manager platform DB.

Important items mentioned in this KB:

• The KB, and therefore the script, are meant to disassociate vRealize Suite 7.x from SDDC Manager 3.10.x and 3.11.x
• This script is not supported on other product versions.
• The script is a part of the upgrade process from vRealize Suite 7.x to vRealize Suite 8.x : "Once the script is successful you can upgrade the vRealize Suite 7.x components to 8.x"

With that information, here are the takeways:

• The disassociate process (and the attached bash script) is ONLY for vRealize Suite 7.x
• The disassociate process (and the attached bash script) is ONLY for VCF/SDDC 3.10.x and 3.11.x
• The KB is not meant for VCF 4.x
• The KB is not meant for vRealize 8.x
• The script in the KB is to be used only before the upgrade from vRealize 7.x to vRealize 8.x, as vRealize Suite 7.x is not supported with SDDC Manager 3.10.x & 3.11x. Please refer to this KB as well: Upgrade vRealize Suite 7.x to vRealize Suite 2019 in VMware Cloud Foundation 3.10 (82216)

So if you are planning to decouple or dissociate your vRealize environment from your VCF environment for whatever reason using the process mentioned above - Please don't. The process is entirely unsupported and will likely result in having to rebuild your SDDC manager (if not your entire VCF environment).

But what if I really want to separate my vRealize environment from VCF, or get rid of it?

Fortunately - there is a supported-ish way to do this, and its likely the only real way to manage this.
We can leverage the Export functionality available for environments and products within the vRSLCM UI.

Disclaimer: There is no officially documented process or KB for this procedure. If you are needing to go through this process, please engage VMware GSS to come up with a plan that works for your environment that is fully supported.

At a very high level, the process will look something like this:

1. Deploy a new vRSLCM instance, external to SDDC Manager.
2. Export vRealize products and environments, if we need to preserve them.
3. Delete vRealize products and environments to vacate VCF-linked vRSLCM instance.
4. Import the vRealize products and environments to the new external vRSLCM instance, using the exported configuration.
5. Power off the VCF-linked vRSLCM instance.
6. (Optional) Decommission and delete the VCF-linked vRSLCM instance using DELETE API for vRSLCM available in SDDC Manager.

At that point, the vRealize deployment will be completely separated from the VCF environment, and we will not have to run any manual DB edits anywhere.

The reason the export and delete commands from vRSLCM work for this scenario is because the VCF-linked vRSLCM instance is, well, linked to the SDDC Manager. When the delete command is run in vRSLCM, SDDC manager is aware of the command being run, and starts a corresponding workflow on its end to clean up (well ... mostly) all references to the product being deleted.

That being said, its not this simple. There are several considerations, depending on the vRealize products deployed, how they are deployed, and the complexity of the environment.

For example:

• Implications of vRA multi-tenancy or content management in play
• Environments are deleted from vRSLCM, but the VMs are still present in the inventory
• Considerations of knowing/preserving/exporting all vRealize passwords from SDDC Manager and/or vRSLCM prior to using the products in the new vRSLCM instance
• Implications of existing NSX load balancers deployed by VCF for vRealize products
• Does not account for a rollback plan
• Order of operations may vary depending on the environment

I'm sure there are other considerations that are not mentioned here - Point being, do not attempt this without first engaging and consulting VMware GSS, and coming up with a documented plan that will be fully supported for your environment. This will likely involve engagement from multiple teams on the GSS team (VCF, vRealize, NSX)

I hope this provides a much better understanding on what has changed and not changed for the vRealize Suite in VCF 4.4 and above, and what the decoupling or disassociating process really looks like.