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.

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 😉
Luc.

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.
Steve

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.

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.

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.

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.

NEED HELP?

My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__ doublecloud.org.

Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.