VMware vCenter tasks and events collection
vCenter tasks and events provide valuable information that can be used for historical and audit purposes. They are stored in the vCenter Server’s database and available until the data retention setting is reached. By default tasks and events are cleaned up after 30 days and increasing this limit can result in a significant increase of the vCenter Server’s DB size. In this article, I’m going to share my experience with getting this data programmatically for use in a 3rd party software.
Choosing which API to use
I was involved in a project where vCenter tasks and events had to be collected with a Java client. Additionally, the required backward compatibility and presence of existing integration left no room for anything else but the vSphere Web Services API. In my opinion, it takes an effort to get used to it. It’s quite abstract (probably for a good reason) and you really need to get your hands dirty to start getting familiar with it. But let’s get to the point, using the vSphere Web Services API to get tasks and events.
The Managers
Luckily, there are 2 “Managed Object” (to use VMware’s dictionary) that are perfect for the job:
The documentation is quite good and you can get the expected results pretty fast.
Tip: If you have access to vCenter Server you can navigate to https://vc-address/mob, authenticate and navigate to the desired Managed Object type where you can execute methods and see results directly in the browser. For example https://vc-address/mob/?moid=TaskManager
Limitations
Everything was going just fine until we started testing - data for some objects were missing.
A little back story, in this case, the collection was happening per object, as this was the best way to tie it to the rest of the application flow. Ok, moving on. Of course, there was an error logged:
com.vmware.vim25.InvalidStateFaultMsg: The operation is not allowed in the current state.
When I saw it first I pretty much ignored it, as I knew there were some hosts in Not Connected state and I figured this was the cause. Later, after the missing data was obvious, I started to doubt my initial opinion, because it didn’t make much sense - the tasks and events are provided by the vCenter Server and reside on its database. The object state shouldn’t have any influence on that.
The answer was in another useful documentation vSphere Web Services SDK Programming Guide:
“DestroyCollector – A HistoryCollector exists only for the current session. Invoke the DestroyCollector operation to explicitly destroy the collector before the session ends."
Using the CreateCollectorForTasks method of the TaskManager (or its alternative in the EventManager) creates a TaskHistoryCollector but there is a limited number of those that can exist concurrently. The exact limit is 32 as specified by the maxCollector property of the TaskManager or EventManager. In the scope of the project, there was no need to continuously monitor the tasks of a given object, there for the collector could be safely destroyed once the initial collection is completed.
Implementing the use of destroyCollector method helped to avoid reaching the maxCollectors limit and effectively get all the data that was needed.