While working with and maintaining the VM environment, we may need to remove and re-add resources (VMs, Hosts) and keep the same name.
This leaves old objects in the database.
Looking at resource lists in vCops (customUI) you will see several objects of the same name, but different IDs, and different "Identifier 2" values, while the Identifier 1 and Identifier 3 values are the same.
Is there a way to remove the records of old objects?
Yes, this is a known issue. Removing an object from the vCenter inventory (ANY object - folder, VM, host, cluster etc.), results in a new mo-ref id. This is the ID you see in 'Identifier 2'. Identifier 1 is the name of the object and Identifier 3 is the vCenter GUID for that matters. When referencing to a resource, all Identifiers need to be correct, else a new resource is created - and that is exactly what is happening here.
You should note the Health is unknown "?" and the collection state is empty.
You can go to "Environment, Environment overview", sort the Health column (to quickly identify 'old' resources), click (either one, or multiple using shift click) resource, and click the "Delete Resource" icon. This removes the resource, removes data, keeping your database 'clean'.
TBKing, you can set vC Ops to automatically remove these deleted/old objects - see this KB -
VMware KB: Removing non-existent virtual machines from the vCenter Operations Manager vApp
Thanks!
Environment-Environment Overview is where I'm at now.
....?
It appears that SRM creates and removes objects thereby further "polluting" the database with dead objects. Is this correct?
Ack
Thanks for the KB
I'll give it a run.
Is there integration available/planned between SRM and vCops??. If so, when? This would be a very valuable capability, especially for customers who use SRM for large data center migrations. As it stands now, when SRM migrates a workload, especially between vCenters, the old GUID is orphaned, and a new GUID is created, which is not included in the Application/Tier object.
Thanks for this, was just what I was looking for.
Danny