Note: If you face this problem in a production environment you should reach out to VMware Global Support at this point. This is not an official guide. And even if you use it in non-prod, please make a backup before any changes.
These steps are a mix and match from slack threads, engineering PRs etc that I compiled. So, the main work has been done by others and I want to thank you all who contributed and helped out!
I worked with a customer who faced a situation where they needed to decommission their old vCenter at short notice and moved all the vRealize virtual machines (VMs) into another vCenter. The impact to vRealize Lifecycle Manager (vRSLCM) came as an afterthought and for sure, it fell down when it could not find the VMs.
Here is a quick overview about the old and working setup:
From a vRSLCM perspective, all the environments (globalenvironment as well as custom environments) are in a single datacenter that contains a single vCenter with all the VMs.
Here is what happened when the VMs were moved
All the VMs reside now in a new vCenter which is unknown to the lifecycle manager and it has no reference to it. Inventory syncs are failing and your cannot do any requests like upgrades.
On a high-level, you need to make vRSLCM aware of the new vCenter and adjust the environment configuration to reflect the changed vCenter location.
For this you need to have access to vRSLCM with administrative rights, provide vRSLCM access to the new vCenter with a service user and have something like VS Code to edit the JSON payloads.
Add the new vCenter to the existing datacenter
Head to the datacenter configuration in vRSLCM and add the new vCenter to the existing datacenter in vRSLCM.
After you completed the task, you should have two vCenter server in the list, the old one and the new one. You cannot remove the old vCenter yet as all references are tied to this entry.
At this point, please note down the values for the new vCenter:
- vCenter name (e.g. new-vCenter)
- vCenter FQDN (e.g. newvcenter.lab.why-did-it.fail)
It becomes A LOT easier if you have the same credentials for the old and new vCenter. In fact, I will just cover this case here to limit the scope of this blog.
Prepare for private API access
I suggest using a second browser tab as you might switch between the UI and API for verification. While you can do this with Postman or curl, it’s just a few operations and will show the steps using the built-in swagger UI:
Once swagger is open switch to the private API. Then authorize with your password to make any operations.
Extract the current environment details
In the private API section, scroll down or search for the Environment Controller and open/unfold it.
The next step is to execute a GET operation in order to extract the current definition of all your environments affected.
Personally, I prefer to use “getEnvironmentByName” but you can also use “getEnvironmentDataFromId”.
Start with the “globalenvironment” (in this case, it is the same name for “getEnvironmentByName” or “getEnvironmentDataFromId”) and execute the GET command.
You should receive a response of 200, which means success and a JSON body output which you need to download.
Adjust the environment details
At this point we need the values from the new vCenter (you noted them, right?). If you don’t have them at hand, open the UI and head down to datacenters to review the values.
Open the JSON file in your favorite editor and replace the values for:
vCenterName - here goes in the label of the new vCenter
vCenterHost - here goes in the FQDN for the new vCenter
I guess it goes without saying, but: Make sure to change just the values and not any command characters to avoid any JSON syntax errors.
Copy the changed content (that is the whole JSON file) to your clipboard and head back to the browser tab where you have the vRSLCM API open.
Submit the changes
In the Environment Controller section, go to “updateEnvironment”.
Paste your modified JSON content in the body of the request and execute.
On success the return code is 200.
Go to the vRSLCM UI and check the details (e.g. vIDM nodes) in the global environment to reflect the changes for the vCenter. Don’t worry if the rest of the values (host, datastore) are not yet accurate. Trigger an “inventory sync” to update these.
Repeat the steps
For all other environments affected you need to repeat the steps.
Once you have done that, you can remove the old vCenter