You know how you buy a new product, and so many times you have to work to make it act the way it should out of the box? A perfect example is any iOS device from Apple. There is simply no reason an Apple device wouldn’t automatically download podcasts for you in the background so you’re always up to date with the latest episodes. But it doesn’t. You have to buy Downcast for $2 to make the device work as it should from the beginning.
What’s that got to do with vCenter Operations? If you’ve used vCOps (pronounced vee-cee-aaahhhhps, according to the Twitter cognoscenti) extensively, you will no doubt have run into a problem where a VM, datastore, or any other object gets deleted out of vCenter, but will not go away from vCenter Operations’ database.
This can be quite frustrating. It will let you go into the custom UI and delete it as many times as you want. But it truly is an exercise in futility. It will never actually delete until you go in and make some changes to some config files.
Let’s get started.
First, you’ll want to SSH into the Analytics VM. Login with “root” and your password.
Next, type the command in blue below. The prompt shows “secondvm-external“, which indicates you’re on the Analytics VM.
secondvm-external:/ # vi /usr/lib/vmware-vcops/user/conf/controller/controller.properties
Take a look at this file, and find the following line:
deleteNotExisting = false
Change false to true
If you’re in a hurry, you can play with the deletionSchedulePeriod setting, or you can just wait 24 hours, and the objects you wanted deleted will be deleted.
When you’ve made the change, type the following:
One last step for good measure.
Back at the secondvm-external:/ # prompt, type the following:
Note the prompt now changes to firstvm-external:/ #
Type in: su – admin
Now you’re at the admin@firstvm-external:~> prompt.
And you’re all done.
24 hours from now, objects that no longer exist in vCenter won’t exist in vCenter Operations. Why this is not default is not entirely obvious to me, but there you go.