Stale inventory data?

I am noticing that old datastore inventory are still showing up in the overall datastore inventory list, even though the datastores were removed from our VMware vcenter and no longer show up in the providers view.

I know I can manually delete inventory, but is there a regular scheduled routine, job or policy to help clean up stale inventory?

Thanks in advance.

Do you mean from Compute -> Infrastructure -> Datastores they are listed, but from Compute -> Infrastructures -> Providers -> <your provider> -> <dashboard view> they are not?

Objects removed from the provider are generally removed from the inventory, unless they are marked as archived or orphaned. It’s possible to create a schedule in Configuration -> Settings -> Schedules that runs an automate task (say daily), that cleans these up, but there’s nothing like this out of the box as some people genuinely like to retain object records of archived “things”.

I don’t see an ‘archived’ attribute on a storage object though, someone with more developer skills here might be able to comment.

It would be worth comparing the attributes of one of your valid Datastores, with one of the “old” Datastores. Have you ever used object_walker? It might be worth installing this and the object_walker_reader rpm , and then run it twice from Automate -> Simulation, specifying one of each type of datastore (i.e. good and bad) each time, i.e.

You can then run object_walker_reader in list mode to get the timestamps of the two runs:

./object_walker_reader.rb -l
Found object_walker dump at 2020-08-21T08:24:58.862595
Found object_walker dump at 2020-08-21T08:26:30.145389

and then run it again in diff mode to compare the outputs:

./object_walker_reader.rb -d 2020-08-21T08:24:58.862595,2020-08-21T08:26:30.145389

...
209,212c209,212
<      |    |    $evm.root['storage'].ems_ref = datastore-35   (type: String)
<      |    |    $evm.root['storage'].ems_ref_obj = #<DRb::DRbUnknown:0x0000558a77201f78>   (type: DRb::DRbUnknown)
<      |    |    $evm.root['storage'].free_space = 130500554752   (type: Integer)
<      |    |    $evm.root['storage'].id = 4   (type: Integer)
---
>      |    |    $evm.root['storage'].ems_ref = datastore-63   (type: String)
>      |    |    $evm.root['storage'].ems_ref_obj = #<DRb::DRbUnknown:0x000055aaaa7f1f48>   (type: DRb::DRbUnknown)
>      |    |    $evm.root['storage'].free_space = 125024862208   (type: Integer)
>      |    |    $evm.root['storage'].id = 3   (type: Integer)
214,215c214,215
...

See if both Datastores have a valid ems_ref and ems_ref_obj. If you can find an attribute that’s reliably absent or null on the “bad” Datastores, you might be able to create a small automate task to search for Datastores with this attribute value and remove them from the VMDB on the schedule.

Sounds a bit hacky (and it is), but you need to find out what’s stopping the Datastores from being removed as part of the natural purging of out-of-date inventory. It may be a bug.

hope this helps
pemcg