Home > vSphere API > Why No DatacenterRemovedEvent? A Deep Dive into vSphere Event Model

Why No DatacenterRemovedEvent? A Deep Dive into vSphere Event Model

September 14th, 2010 Leave a comment Go to comments

Last week I discussed how to get event type with vSphere API, followed by a comment asking why there is no DatacenterRemovedEvent? Very good question and almost got me there.

vSphere API has a comprehensive object model for event. In version 4.1, we have 474 different types of events representing different things happened in vSphere. When a managed entity is removed, there are normally events associated, for example, VmDeployedEvent, HostRemovedEvent, ClusterDestroyedEvent, ResourcePoolDestroyedEvent, DatastoreDestroyedEvent, DatastoreRemovedOnHostEvent, etc. It’s natural to expect DatacenterRemovedEvent. But you don’t find one.

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


It’s not only Datacenter which does have DatacenterCreatedEvent and DatacenterRenamedEvent. For Folder type, you find nothing other than VmBeingClonedNoFolderEvent which is not related to lifecycle of Folder at all.

Why are these events missing?

Instead of thinking, let’s try something. So I tried to remove a datacenter from vCenter and got an event there as shown below. A little surprise to me, the event is typed as TaskEvent which is a direct subtype of Event, and has one additional property called info (type TaskInfo).

Although vSphere has a big number of event types, it cannot capture all the things happened in the system. For one thing, vSphere 4.1 has 491 methods. If we create a type for every change as result of a method call, 474 event types are not enough. Of course, for some method calls there could be more than one thing happens; for others nothing. Luckily we have TaskEvent to capture all of them!

The upside of one for all is that you have one type to deal with. The downside is that the type itself doesn’t tell you much. So you want more concrete types representing the nature of the things happened without looking into the details of the object. Therefore vSphere includes many event types.

At the same time, you don’t want to go too far with all the things, important or trivia, represented by distinct types. The trick is really to get a balance point in between. The criteria are of course

1.       Is this what people really care about? The more people care about, the more likely it should have a corresponding event type.

2.       Is this something people use often? The more frequently it happens, the more likely it should have corresponding event type.

With above discussion in mind, you can understand why you cannot find some event types. The importance and frequency are of course subjective. You can always make a case that we should have some event types.

When you can find the concrete types, that is great; if not, look for the TaskEvent type. The is the key take away from this article.

Categories: vSphere API Tags: ,
  1. September 14th, 2010 at 01:34 | #1

    Hi Steve, interesting blog post as usual.
    But I’m not sure I can follow your reasoning.
    Capturing the removal of a datacenter in a Task event looks more like an easy way out to me. I can imagine that a developer needs more resources to introduce a new eventtype for a method than using a catch-all event like the Task event.
    And I definitely can’t see why events should have a popularity vote. If all methods would use events in a similar way it would be a lot easier to code against them.
    Sorry for the rant, but I coded a few scripts against tasks and events and it would have been a nicer experience if there had been some uniformity 😉

  2. September 14th, 2010 at 10:43 | #2

    Hi LucD,
    Great comment!
    I see your points and I agree with you that uniformity is a nicer experience. Like any engineering, it’s always a trade off between technology and cost. In this case, the cost comes in two folds: for the designer, it means more event types to create; for the users, more events to learn and handle.

  3. Vishal
    September 14th, 2010 at 14:38 | #3

    I agree its better to have a uniform solution, since DatacenterDeleted is a pretty common operation from VI Client.

  4. September 14th, 2010 at 19:16 | #4

    Hi Vishal,

    I agree with you and LucD in that uniformity is nicer experience. My article is more on explaining why it’s like this than arguing the current design is the best… :-)


  5. September 18th, 2010 at 15:52 | #5

    In version 4.1, we have 474 different types of events representing different things happened in vSphere.

    vSphere 4.1 has 491 methods.

    If we create a type for every change as result of a method call, 474 event types are not enough.

    Are we just talking about needing another 17 event types? One for each method?

    Is there a URL where these event types and methods are listed?

    It’s be interesting to do a gap assessment for the missing event types and someone might share their code solutions for tracking/reporting on these.

    Any change might need to be associated with an approval in a shop running under ITIL framework with a change management process. With the move away from SNMP and SYSLOG for monitoring and logging using the API is ending up being the best way to keep up with the changes of your vSphere.

    I b e n

  6. September 18th, 2010 at 17:24 | #6

    Thanks for your comment Iben!

    The methods and event types do not have strict one to one mapping. If fact some retrieval methods do not need an event, and some methods may have more than one method associated. I haven’t done a complete analysis there. Even if you don’t have specific event type, you can try TaskEvent.
    You can check out the event types from the API reference. I have listed links to different versions of API reference at http://vijava.sf.net. Please check it out there.
    I heard about ITIL framework but don’t know much on details. We can discuss more on vSphere management under ITIL framework.


  7. Sham
    September 21st, 2010 at 17:14 | #7

    Hi Steve hope your well.

    The other thing about actions not having events associated with them is the ability (or lack of) to alarm off them. For example, I noticed that vSphere 4 would generate a task when a virtual switch was modified on an ESX host, but not an event (this may have changed with 4.1). This meant that I could not generate a “ESX Switch Modified” alarm through the VC alarm mechanism. Instead, I ended up polling VC and interrogated the TASK list to see if any tasks with XXX occured.

    Correct me if im wrong but this is my understanding of the alarm system.

  8. September 21st, 2010 at 21:37 | #8

    Hi Sham,

    Good question. Have you checked if there is an TaskEvent created after the modifying virtual switch task is done?


  9. sham
    September 22nd, 2010 at 06:23 | #9

    I didnt see a specific taskevent for the task from memory and looking through the events list in the api i couldnt find the corresponding event. What would be good following on from your post about custom events is if VMWare allowed you to define an events for existing tasks (and not just extensions). I did some testing on this a while back and found it wasnt possible at present.

  10. September 22nd, 2010 at 11:46 | #10

    I sounds like a good time to file a SR with VMware support team.


  11. Vishal
    October 12th, 2010 at 18:10 | #11

    How do i register for “TaskEvent” events?


    tried the following event Filter, this doesnt work.

    eventFilter.setType(new String[] {
    “DatacenterCreatedEvent”, “DatacenterRenamedEvent”,”TaskEvent”

    _eventHistoryCollector = _eventManager.createCollectorForEvents(eventFilter);

    UpdateSet update = propColl.checkForUpdates(version);
    if (update != null && update.getFilterSet() != null) {
    …// this doesnt get executed.

  12. Vishal
    October 18th, 2010 at 13:14 | #12


    any comment on how do i receive TaskEvents? Any API, like checkforupdates?


  13. October 18th, 2010 at 16:48 | #13

    You can get the EventManager’s latestEvent property, or use EventHistoryCollector for old events.

  1. No trackbacks yet.