Unable to delete compute resources

[beefy147]

Hello

I just read this KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=207208...

does this still apply for vRA 6.2.1? Is there a workaround

its pretty horrible for us as we had a number of test ESXi hosts at the time our endpoint was added to vRA. to make matters worse these were added by IP only and are now "stuck"

they are not selected in any fabric group so why are we unable to delete them or at least rescan the entire endpoint?

they are not associated with anything and the only thing it seems I can do is turn off data collection

any ideas?

[zebduin]

One thing you can try - sort of a last resort method is to remove the table entry in the SQL database.  I've done this with mixed results - so make sure to take a backup of the databse before performing the following.

I attempted to replicate your issue.  I added a host 10.119.29.186 to vRA 6.2.1

To ensure I would reduce any potential contention, I removed the compute resource from the fabric group:

In the database, after taking a backup, I look at the dbo.Host table:

I locate the host (compute resource) that I need to remove

If there are any constraints (very likely)  ie Virtual Machines, reservations, templates, etc, you will not be able to remove the host until those records are removed

When opening a query window, ensure the vRA database is selected, default is master:

If you are successful in removing the field, you will see:

a select statement on the dbo.Hosts table will no longer show the host, and the host will no longer show in vRA:

[beefy147]

thats all good but for a product on its 3rd major revision to not have OOB functionality to delete things like this is pretty rubbish isnt it?!

[zebduin]

Rubbish or not, its a reality and I've been doing it since the DynamicOps days (2011+)

As VMware moves away from the IaaS components, I expect the legacy DOPS elements to be revised, replatfomed and some of the data syncronization issues to be mitigated.

[beefy147]

thats the irony. we have DCAC 4.5 here (put in my consultants way before my time) and I am building out a new 6.2.1 environment.

peoples expectations are for things to have moved on a lot which in some cases they havent

thanks for your help

[zebduin]

The changes since DCAC 4.5 to vRA 6.2.1 are noteworthy. And the product is getting better with each release.  IMO the biggest game changer has been with integration with vRealize Orchestrator.  The old vCAC designer days are not missed .

Improvements have been made along the way AzMan to SSO, DEM overhaul, the emergence of the service catalog and entitlements, NSX integration and the Advanced Service Designer.

Some elements that haven't changed where change would be welcome:

- ManagerService cold standby failover requiements

- Property Dictionary limitations - specifically a need to allow drop down lists to dynamically update through Powershell scripting

Being able to update properties via vROrch during the BuildingMachine WFStub has probably been the most helpful for me in my deployments.