Object Model of VMware vSphere API: A Big Picture in 2 Minutes

When I start to use a new API/SDK, I always look for the object model diagram before digging into the API Reference. With that, I can have a good overview of the API, from the concepts to the structure. This can save a lot of time.

Unfortunately, we don’t find such a object model diagram in any official document. The following is the UML diagram from my book VMware VI and vSphere SDK.

Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.

The UML diagram can be inferred from VI SDK API Reference. Please note that there is NOT a managed object type called ManagedObject in the API Reference. This is a type I add to make the object model complete. Given the limited size, I only show the names of the types, not properties and methods.

To better group these managed object types, I use different colors. On the right most side of the diagram are the ServiceInstance class and various “manager” classes like AuthorizationManager. From the ServiceInstance, you can get any object of these types with single call in VI Java API, for example getAuthorizationManager().

In the middle of left side, you can find ManagedEntity class and its sub-classes like HostSystem, VirtualMachine. These types represent all the items you could find in the inventory tree from VI Clients. They are the most important managed objects in the whole model, and all tagged with orange color except the HostSystem.

The HostSystem is very much like ServiceInstance in that it has many “System” or “Manager” types closely attached to it, for example, HostDatastoreSystem. You can get hold of these objects with a single method call from a HostSystem object in vSphere(VI) Java API. For this reason, both HostSystem and all the attached classes are tagged the same color.

The diagram shows the object model of VI SDK 2.5. vSphere 4 adds 20+ managed object types. It also changes a few inheritance relationships. Network, for example, becomes a subtype of ManagedEntity in vSphere. Other than these changes, the overall structure and the way how it works are the same.

This entry was posted in vSphere API and tagged , , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

22 Comments

  1. Posted March 3, 2010 at 9:48 am | Permalink

    Good diagram, Steve!

  2. Posted March 3, 2010 at 10:25 am | Permalink

    Thanks Dmitri!
    More diagrams to come. Please stay tuned.
    -Steve

  3. Jayadeep Purushothaman
    Posted March 22, 2010 at 12:52 am | Permalink

    Isn’t this way too complicated for a simple model of Datacenter-Host-VM model ? I found it difficult to understand. IMO It overlays important things with not-so-important ones that makes things difficult.

  4. Posted March 22, 2010 at 2:35 am | Permalink

    The vSphere API is indeed complicated, and that is why vCloud API was designed. The vSphere API is like “under the hook” API and the vCloud API is like “driver seat” API. Both are needed depending on what you want to achieve. I think you vCloud API is what you like. I will blog about it later. Please stay tuned.

  5. Damien
    Posted November 17, 2010 at 11:15 am | Permalink

    Hi Steve,
    First, thanks for the API !
    I don’t really understand how counter works (i already have a look at http://vijava.sf.net/…/samples/perf), do you think you can have a try to make a object model for counter ?

    Kind regards,

    Damien

  6. Posted November 17, 2010 at 12:30 pm | Permalink

    Hi Damien,

    I am glad you like the API. Have you read the post on performance management in vSphere? http://www.doublecloud.org/2010/03/fundamentals-of-vsphere-performance-management/. Thanks!

    -Steve

  7. Damien
    Posted November 18, 2010 at 9:32 am | Permalink

    Hi Steve,

    Thanks, i haven’t read this part before (i’m new using the SDK), it’s very intersting.
    I think i’ll have to come back to you some times.

    Regards,

    Damien

  8. Damien
    Posted January 24, 2011 at 9:38 am | Permalink

    Hey Steve,
    What is the difference between vim and vim25 ? There some common classes, but not the same behavior.

    regards,

  9. Posted January 24, 2011 at 11:22 am | Permalink

    Hi Damien,

    vim and vim25 are the namespace used to version the VI/vSphere SDK. Before VI SDK 2.5, it was vim; every version after, 2.5. With VI Java API, you only need vim25 package which can handle vim namespace as well.

    Steve

  10. Damien
    Posted January 25, 2011 at 4:44 am | Permalink

    Thanks Steve.

  11. Damien
    Posted January 25, 2011 at 5:23 am | Permalink

    I think i was using the wrong sdk till now.. Where could i download last SDK ?
    cause i was using this one : http://sourceforge.net/projects/vijava/files/vijava/VI%20Java%20API%202.1/

  12. Posted January 25, 2011 at 10:19 am | Permalink

    VI Java API has different versions. The 2.1 you are using is the latest one that support all the VI and vSphere versions. I think you are good.

    Steve

  13. Damien
    Posted January 26, 2011 at 4:35 am | Permalink

    Ok. I’ve downloaded and tried the “vijava experimental” from VMware website. What make it “experimental” ? Is it reliable ?

  14. Posted January 26, 2011 at 10:24 am | Permalink

    Hi Damien,
    As an open source project, VI Java API has never been experimental although we did have one or two experimental features. The one you got from VMware website is totally different thing. For latest vijava API, you can check out http://vijava.sf.net and click the download menu.
    Steve

  15. Damien
    Posted January 26, 2011 at 11:37 am | Permalink

    Thnaks Steve, but what would be the difference so ?

  16. Posted January 26, 2011 at 2:43 pm | Permalink

    Damien, I have not used the other SDK, so I cannot comment on that. However, I know of a research by Andrew Kutz at here: http://vijmark.sourceforge.net/

    Steve

  17. Damien
    Posted January 27, 2011 at 8:37 am | Permalink

    Thanks Steve ! That’s really interesting.

  18. Posted April 12, 2011 at 12:30 am | Permalink

    Hi Steve. diagram is very much detailed and self explanatory.
    Also thanks to Damien and Steve for clearing my vim and vim25 concept.

  19. Posted April 12, 2011 at 12:46 am | Permalink

    You are welcome Pranav! Please feel free to join our first community meetup on May 18th. Registration page will be online soon. Stay tuned.

  20. kim
    Posted January 23, 2013 at 12:07 am | Permalink

    can u plz give me class diagram for vsphere smulator?
    or class diagram for mocking vsphere’s VM

  21. Posted January 23, 2013 at 12:34 am | Permalink

    Hi Kim, I don’t have class diagram for vSphere simulator. However if you want to develop one, the class diagram should help you.

    Steve

  22. kim
    Posted January 23, 2013 at 3:07 am | Permalink

    thnx for quik reply!!

4 Trackbacks

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

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