Has anyone found a way to cleanly unregister machines in VRA 8.x so that they can be onboarded again?
Some other approaches in blogs suggest to delete the corresponding record of the resource in the PSQL database (dep_resource), but this leaves some dependencies and you can't onboard the machine again.
Thanks for reading.
Not even near done rolling over form 7.6 and hit an issue with this. Have an SR in but looks like on the vCenter side there were some host issues and some vms may have been removed and re-registered in vCenter. Same UUID, same name, new moref, different folder, tags gone. Data collection may have swug by in the middle of it and now I have some Missing in deployments with its twin sitting in Discovered.
Don't want to just delete the machine or deployment in vRA and risk kicking off an EBS that would tear down things for the deployment (like DNS) or potentially delete the real VM. In 7.6 this would just be simply unregister. I don't get how we don't have an unregister for deployed items.
I got confirmation that we don't have any option or any kind of workaround to unregister a VM in vRA 8. If you move it to another vCenter for any reason, that's it. You can only delete original deployment - but that usually means for me full decommission process - dns removal, cmdb update, AD removal in case of Windows VMs etc.
Last year we migrated cc 2000 VMs from NSX-V to NSX-T - different vCenters. In vRA 7 we had to update reservations, it was annoying but it worked. Next year we might have to do similar thing and I can only hope that some future vRA 8.13 will have a solution for this.
For some reason product management team doesn't see this "feature" as very important.
Maybe we can pile on that feature request. I never feel like those are taken seriously, but if enough of us ask maybe they'll implement. But I have to guess that they coded themselves into a corner, because unregistering comes with all sorts of required conditions. Almost like they don't know how to unregister a server that was built in vRA (as opposed to onboarded) or one that not longer meets one of those conditions. But I think the entire community would love the ability to simply unregister any server resource at any time. I don't understand how they don't know how to clean those things up on their side.
In the meantime, if deleting the server is viable, we use a custom propery that contains "build" flags. So for example during the build, if we successfully create a dns record, we turn the dns flag on. Then when the "destroy" subs kick in, we check those flags before taking action. So for example, if we never created a dns record and the build failed, we don't try to remove it.
With that in mind, we have a day-2 to allow users to delete a deployment without removing records from DNS, AD, etc. It simply flips all of those flags to false via the api, then issues a delete on the deployment. When it somes to those "destroy" subs, the flag is off and we therefore don't delete from DNS, AD, etc. So the server ends up deleted but all of the other pieces remain. Not sure if that's helpful for anyone, but wanted to mention it.
We shut down the vm, remove from vSphere inventory. Then delete the deployment with missing vm (here you can turn off EBS’s or use some filter not to run them). Then add vm to vSphere inventory and turn on.
I have already asked my TAM and other contacts in VMware to push this as hard as they can. And also got info that people have been waiting for this feature over 2 years now.
Some work is invested into automation: HCX migration to different vCenters should automatically update vRA with new info, cross vCenter migration also and something with SRM - in case of failover to different location/vCenter.
But no details or commitment what exactly and when.
Eventually we will get this feature, just no one knows when...
That only works for on boarded vm's or at least that was always the case before... another complaint of mine a vSphere on boarded vm and a deployed should be treated the same. Not sure why it varies and nobody has ever answered me.
@xian_ this reminds me of what we had to do with vCD back in they day... messy but it seemed to work. The mere fact this does work means that VMware should be able to easily implement this if we can hack at it to get the result we want.
You can move deployments between projects so long as the project has access to the resources the deployment is running on. This feature was added a few point releases ago. What version are you on?
I'm lagging behind a bit in updating our vRA environments but I did notice it was announced that unregistering a vm will be supported soon and might already be in the most current version of vRA. Has anyone had a chance to test this yet? Curious to hear if it works as expected?
Unregister action for “Provisioned” machine resources is what is missing.
Also, if you were to add a disk via Day2 to an onboarded machine, the deployment is no longer considered “onboarded” because there is a “provisioned” disk present.
I have no idea what the details are for the following, but this is scheduled for the saas offering this weekend.
Aria Automation 8.13.0 Features
The feature is enabled but the system needs to be not in a 'cluster' or you will get an error. After a ticket with support, it is stating in your Template should not have 'count' inside the code. Then you can unregister properly. So only single machine deployments will be possible at this time.