In vRA 7 you could remove a VM from portal management (leaving the VM in vCenter) by using the “Unregister” day 2 action. There is no such action in vRA 8. There is also no way to remove the VM using the API without it being deleted from vCenter.
Fortunately there is a way but it involves directly editing data within the postgres database in the postgres pod.
Accessing the postgres kubernetes pod and directly editing the postgres databases is not supported by VMware.
1) Connect to the vRA 8 VM (console or SSH)
Run the below command to see all pods:kubectl get --all-namespaces pods
You will see a pod named “postgres-0” under namespace “prelude”
Run the below command to get a bash shell on the postgres pod:kubectl exec --namespace prelude -it postgres-0 -- /bin/bash
Run the below command to change to the “postgres” user:su postgres
Run the below command to connect to the “catalog-db” postgres database:psql catalog-db
Run the below postgres query to remove VM from vRA 8 management:delete from dep_resource where name = '{vmName}';
Disconnect from postgres using the \q command and disconnect from the vRA 8 VM.
VM will have disappeared from deployment, leaving an orphaned blueprint which can be deleted
hi Luke
i have a question…would you please help me?
i have 2000 vm onboared on vra 8 and i have a lot of error on my vIDM.
i wanna install vra 8.11 with new vIDM.
what is the best way to migrate to the new environment with new vra and vidm?
should i disconnect all of the vm from old vra and then onboard on the new vra again?
In vRA 8.7 (possibly earlier) you have the option to unregister a VM from the GUI.
Expand the deployment, select the three vertical dots next to the VM, then select Unregister. This will make the deployment blank which you can then delete.
Do us a favor @ VMware and please take down this article.
This is an unsupported method that is generating volume within our support center. VMware has stated this is not supported and the feature to “offboard” a system is not currently available.
vRA 8 is designed with Kubernetes and there are a large number of databases on the system. There is no internally recorded “trick” to get to this state and VMware will not provide one in the form of an escalation to our development team.
Please contact your account managers and Global Support with the ask for this Feature and we will ensure that information is prioritized to our PMs on their feature review cycles.
Compute resource remains managed. Why not add it to the cloud client or API etc as supported feature?
I could see this a huge benefit if you do large onboarding and selected the wrong deployment and want to remap it to the correct locations.
Worked a treat, thank you!
Hi Gary
Thanks for your comment. I am glad it helped you out 🙂
Cheers, Luke
Hi Luke,
I tried using this blog to see if it works for my environment. I see a Machine when looked from Infrastructure – resource – Machines, which doesn’t exist in vCenter, so I tried going to the dep-resource table and did select to see if its exits, I got zero rows for the query, am I missing anything here?
Look foward to hearing from you.
Thanks
Hi Mukesh
Thanks for your comment.
Do you have any VMs in vRA? If so they should be in the “dep-resource” table, what query were you running. If a VM exists in vRA but not vCenter it will be orphaned, does it show this status when looking under Infrastructure?
Cheers, Luke
Luke, doing this will only remove the parent deployment container and not unmanage the machine. The actual compute resource remains managed but with broken dependencies (becoming orphans), you can’t easily repair. There are way more things you need to do to it right in the Cloud Assembly. Please consider revising your approach.
Hi Alexey
Thanks for taking your time to comment.
Hmmm ok interesting as it seemed to do the trick for my needs. I do know that editing the postgres directly has always been unsupported by VMware.
Out of interest is there a correct way to unmanage a VM in vRA 8 without having it deleted from vCenter?
Cheers, Luke
A bit late to respond to your question, Luke. As of today, vRA doesn’t officially support «unmanaging» machines, either provisioned or onboarded. If this is an unavoidable approach, I would recommend reaching out to VMware support for help.
In the screenshot you have “delete from”, in the text “drop from”
Sorry typo, it should be “delete from”. I have edited the post. Thanks for letting me know 🙂
Just be aware that this is not supported by VMware and if you’re looking at adding the VMs back to any projects, they will be unavailable for discovery in the onboarding process.
Hi Michael
Thanks for taking the time to comment.
Yes this method is not supported by VMware but sometimes doing unsupported actions is required 😉
As far as I know unmanaging a provisioned or onboarded VM is still not possible via a VMware supported method. I still need to spend more time with vRA 8.1 and 8.2 to see if the API can be used to unmanage a VM.
Cheers, Luke
Hi,
manipulating the database is, as already stated, not supported, and generally a bad idea, and should be avoided unless guided by the VMware support.
The idea is to delete a vRA deployment without actually deleting the VM?
I guess this should work (and is supported) so I guess it wouldn’t require you to mess with the DB…
When Delete Deployment fails, vRA will, on consecutive retries of the the task, offer an option to delete the deployment despite the possible failures.
Why not try to leverage Extensibility (EBS)? Create a vRO workflow (or an ABX action) that throws an error (just a single line of code in vRO: throw “”;). Then create an event based subscription for “Deployment requested” Event, filter it by eventType (should match “DESTROY_DEPLOYMENT”) and link it to the vRO Workflow or ABX action you just created.
From now on, when you choose to delete some deployment, the workflow will be triggered, and it would fail (purposely). This failure should lead to Delete Deployment failure in Cloud Assembly/Service Broker. Next time you try to delete the same deployment, you can choose to ignore failures; the workflow/action would again be triggered, it will fail, but now vRA deployment will be deleted.
Downside to this is that now all delete deployment tasks will fail. To overcome this, you can either use conditions to filter when the EBS event will be triggered (ex: per deploymentId), or improve the workflow by matching the deployment ID from the vRA payload, so that the workflow fails only if the deployment to be deleted is matched by the ID that’s defined in the workflow.
You can also disable/enable the scheduled event, so it’s enabled only when you have to perform such tasks.
Cheers, Matko!
We now support this for onboarded VMs on prem and vRA Cloud. Not supported for deployed VMs within vRA.
The functionality is available directly in the UI