vSphere Java API 3.0 Kicks off, code name “Crescendo”

WIth 2.1 GAed yesterday, I am happy to announce the 3.0 project kicks off officially. For more fun, I picked up a code name for 3.0 release: Crescendo. For folks know music, crescendo means music gets louder and louder. That is where I want to bring the project to. It’s been a huge success for this VMware sponsored open source project. We’ve had 9,000+ downloads, plus 1000+ SVN code sync, after its first debut in 2008.

So where are we going next?

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.

Before answering the question, let’s take a look at the themes of previous releases. The theme of 1.0 was ease of use with full object model and getter methods hiding property collector. The theme of 2.0 was Just Enough High Performance Web Service Engine resulted in not only performance boost, but also clean license with pure BSD, and much smaller footprint and zero memory leak.

Now it’s time to re-visit ease of use again, but from a different perspective. As I discussed early, the learning curve of vSphere API comes from two folds: lack of object model, and complexity of data objects. The 1.0 release solved the problem nicely. Now it’s time to tackle the second one.

There are two possible ways to take care of this. First, provide more samples with better documentation as starting point. Secondly, come up with a higher level of APIs that capture the most common use cases so that you have a giant shoulder to stand on. Crescendo will take the second approach.

Let me give a quick example here. As today if you want to add a hard disk to a virtual machine, you have to use the reconfigVM_Task() method with tons of possible parameters while you actually need just a few. What is the point to read deeply into the parameter data objects? These parameters can easily get wrong. You can, for instance, mistakingly assign a unit number that has been taken by other devices under the same controller. Many more details exposed than needed. Therefore I see a need for a higher level APIs that address this use case with far simpler method.

This is just one sample of many common use cases you may find in real projects. To make sure it’s something you find useful, I would love to hear from you on how you use vijava today and what you wish to have in the future. If you have some code to contribute, that would be even better. I can use them as the base to abstract high level of APIs. I will give you credits whenever it’s due.

Architecture wise, the new layer won’t be mixed up with existing layer, meaning you have choice to skip this layer. But if not, you will enjoy a much higher productivity than using the current abstraction.

Another important thing is that crescendo will empower system administrators on writing automation scripts. The current vijava API is mainly targeted toward software developer even though we have nice jython, Groovy tutorials. With Crescendo, the scripts will be easier and shorter.

BTW, I will be at VMworld next week presenting vSphere API best practices, helping at VMware booth in exhibition hall, and book signing at bookstore (Tuesday 12:30~1PM). If you happen to be there, please feel free to stop by.

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


  1. Mikhail
    Posted September 22, 2010 at 12:49 am | Permalink

    Hi Steve,
    Didn’t you think about switching from DOM4J to StAX to parse XML?

  2. Posted September 22, 2010 at 1:08 am | Permalink

    I haven’t thought about that. What problem do you see using DOM4J?


  3. Mikhail
    Posted September 22, 2010 at 5:28 am | Permalink

    Well, StAX is the part of JDK since 1.6, so Vi Java will not depend on 3rd party lib.

    Also it’s reported that StAX is faster than DOM4J.

  4. Posted September 22, 2010 at 11:55 am | Permalink

    Given how StAX is implemented, it should be faster than DOM4J. However, I don’t expect noticeable difference in performance with StAX. Currently DOM4J parses the response while it waits more from the server. Faster parsing doesn’t help much on the overall completion time.
    For the dependency you have a good point there. Because DOM4J is BSD, I am OK with having this additional jar there.


  5. Posted September 30, 2010 at 8:35 pm | Permalink

    Just wanted to say, I love your work. I am just starting to code some utilities and hope to harness the multitude of images on and off…servers in windows in linux etc etc..

    Thank you! Big ups to the 5 minute starter

  6. Tulsi
    Posted October 14, 2010 at 1:35 am | Permalink


    You rock. All the best for Crecendo.

    Are you planning to add some Meta Data API to expose the types, attributes and relations?

    Adding more examples will help too.

  7. Posted October 14, 2010 at 11:26 am | Permalink

    Hi Tulsi,

    Currently there is no plan on meta data api in Crescendo release. But we can consider it in the future releases. Do you wan to to file a feature request with more details at http://vijava.sf.net (from Bug link)? Thanks!


  8. Bhushan
    Posted October 27, 2010 at 1:05 am | Permalink

    Hi Steve,
    I had a query regarding how often is the vijava project updated
    corresponding to the updates in the VMware SDK? Do updates in VMware SDK get incorporated in vijava instantaneously or what is the usual time time lag?

    Please let me know


  9. Posted October 27, 2010 at 1:23 am | Permalink

    Good question. vijava has been released consistently within one week of VMware SDK GA release. If you are existing VMware beta customer, you can have early access. In between, we have one or two update releases. Critical bugs have been fixed in 24 hours, and made immediately into subversion. Hope it helps.


  10. Tos2k
    Posted February 22, 2011 at 12:39 pm | Permalink

    Hi Steve!

    Thanks for the impressive job you have done with vijava.

    Where is the main forum to post questions you will answer?
    I read that the current release does not support vApps, is that true?
    If I would implement that feature, what do you think about having the community participating in vijava (main public branch)?
    Why do not all entities like datacenter, folder, datastore provide a getVMs() method?
    Can you explain the main concept of vijava concerning that?

    Do you think that VMware one day will only publish your Java API? It has soooo many advantages, or is VMware adopting some of your development experiences/result?

    Dont know where the best place is to post that…


  11. Posted February 22, 2011 at 1:34 pm | Permalink

    Hi Tos2k,

    I am glad you like the vijava API.

    1. The main forum for questions is here: https://sourceforge.net/projects/vijava/forums/forum/826592
    2. The vApps feature is supported in latest VI Java API 2.1. You can check out the VirtualApp managed object.
    3. getVMs() method is a getter method for the property vm defined in a managed object. If there is such a property defined, there will be a corresponding method; otherwise no. I try my best to make the API as close to the vSphere API spec. After all, VI Java is NOT another API, but an implementation of vSphere API.
    4. This open source API *IS* sponsored by VMware although it’s not an official product therefore no support. The VI Java community has done a good job to help each other and I believe we ran a great community forum.


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>


    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.