After downloading the vSphere 5.5 SDK GA release last week, I started to look into the API reference immediately. Because I am pretty familiar with previous versions of vSphere APIs already, I just jumped directly into the “New and Changed Managed Object Elements in 5.5” page (there is a link on the home page of API Reference) as I had to work on the open source vijava API 5.5 which was released as beta last Friday.
As it’s asked about when the vijava API 5.5 is ready, the answer is NOW. A couple of minutes ago, I uploaded the beta release to the sourceforge.net site. Please feel free to download the beta release and give me your feedbacks and bug reports as soon as possible. I plan to GA the release in about one month.
During the past weekend, I upgraded the vijava API project to the new Allura platform provided by Sourceforge.net. That’s really a button click and then waited for incoming emails for status updates. It went smoothly and didn’t take long before it finished.
Note that the upgrade is limited to the project hosting, not the Web site (http://vijava.sf.net) which remains the same and continues to work as before.
It’s been two months since I announced beta of VI Java API 5.1 supporting vSphere 5.1 on September 23. I got many emails asking for the GA date from ISVs and IHVs as the API is now a corner stone in their products. With the long (could be longer, BTW) Thanksgiving holidays, I got some time to review the fixes and release the GA version. I intended to announce it yesterday but somehow extra spam comments pushed the database behind over 100MB limit thus I could not post any new article.
After VMware released the vSphere 5.1 on the night of September 10, I finally got a chance to look at the new vSphere API, including the API reference and more important to me the WSDL files.
I was relieved to find out that there weren’t many changes. No single managed object is added to the vSphere 5.1 API, meaning a lot less work than I thought for vijava API to support the latest vSphere 5.1.
Recently I got several questions and even a bug on supporting the next release of vSphere in the open source VI Java API. The questions are mostly from VMware partners who have early access of the private beta of next release of vSphere and want to ship their own products at the same time of vSphere GA. I figure more partners may have the same question, therefore decide to answer it all here with a possible work around.
While preparing this annoucement, I realize that on the same day last year we had a very successful community event with several techtalks to celebrate the 3 year of vijava open source project. Today it’s the 4th year of this project!
Since VI Java API 5.0 GAed last October, there have been some changes, one of which is that I left VMware and joined VCE the same month. On the project side, there are several new bugs opened with the forum. These bugs do not affect most developers. But still I fixed them quickly in the code repository so that anyone who was affected could get the fixes from there.
As I tweeted last week, there would be a big announcement when the open source VI Java API gets 20,000 downloads. It hit target yesterday. To celebrate it, I decide to release the code generator for the API, which William (@lamw) rated as “awesome.”
If you’ve had a chance to use vSphere Web Service SDK, you must know the PropertyCollector is very hard to use. It takes a newcomer quite some time to learn how to use it, and even more time to learn to use it effectively. Luckily, you no longer have to if you use the open source vSphere Java API (a.k.a. vijava) because it has encapsulated the PropertyCollector behind these newly added getter methods of the managed object types.
If you have read my previous article on vSphere security model, you know how it works. Still, you may wonder what roles a particular user may have, as asked in a recent email from one of my former VMware colleagues.
In an operating system, a user is assigned to a group or multiple groups therefore granted a certain permissions. In vSphere, a role is simply a set of privileges and that is it. It’s natural to think of a role as a group sometimes, but it’s really not.
Last month a question was raised in our open source vSphere Java API forum regarding an exception during HostSystem.getSummary() method call. As you can see from the stack trace, the actual exception was “org.dom4j.DocumentException.”
Upon hearing about my leaving VMware, quite a few members in the community sent me emails or tweets asking about the future of the API. Most of them have built products or automation scripts using the API, therefore would like to see the continuous success of the open source project. I am sure there will be more inquiries coming without this post.
It’s been one plus month since I pushed out the beta code which has since been downloaded more than 700 times. As promised, I am happy to announce the GA of VI Java API 5.0 today. This is the fourth major release after 1.0, 2.0, and 2.1 which are all shipped on time. Predictability is important for commercial products, even so for open source projects like this. I think we’ve demonstrated it in the past three and half years since the first release in May 2008.
Session management is a very important part of vSphere management, especially when scalability is involved. I’ve blogged about this in my previous posts (1, 2). If you haven’t read them yet, it’s high time to do so.
In this article, I am going to share with you a new finding while helping a development team. By default, an idle session is terminated by vSphere server after 30 minutes. The team found that it’s not totally true. They use several types of sessions for different purposes. Two of the sessions remain live even after the 30 minute default while others are gone.
It’s a known bug in VI Java API that it did not escape strings to be included within a XML tag. The potential risk, although very very rare, is that it can blow the de-serialization of a request on the server side. I did get one or two reports on failing on login, which turned out to be caused by special characters like < or > in passwords. As a quick fix, an escaping logic has been added to escape the special characters in passwords.
After the vSphere Java API 5.0 beta was released, I got a very interesting bug that I think is worthwhile to share with the community. Note that I used the word “interesting.” It turned out to have no solution logically, but quite easy to work around and patch up. The workaround addresses only particular issue but does not prevent similar bugs from happening in the future.
Confused? Let’s take a quick look at the bug report:
Among all the new features vSphere API exposes, I think VIX integration is very important. All of sudden, the vSphere API gets a boost on manageability of guest OS, and you can do many more with single set of APIs.
As reported by the open source VI Java API community, a bug came to my attention. It’s related to the Client REST API which is a powerful hack with vSphere MOB based on a little secret. Started in vSphere 4.1 update 1, things started to break if you want to call a method with the REST API while retrieving properties continues to work.
Now that vSphere 5 just GAed today, I am happy to announce the public beta of VI Java API Crescendo release. Based on the feedbacks I got from the community, especially William Lam, I decided the new version to be 5.0 beta so that we can sync up with the vSphere 5.0.
A community user recently reported an issue in this scenario. His test application was launched via Web Start jnlp. “First, when run a single test thread everything is fine and the VM tasks operate normally. However as soon as we kick off a second test thread while the first test thread