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.
If you are using, or intend to use, the open source vijava API with Java Web start, you want to read this article carefully.
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
Today I got an email from Louis Jia who is a Sr. Development manager at Cisco. He told me that the product his team has been working on had been rebranded as Cisco Data Center Network Manager (DCNM) and is formally released. Congratulations to Louis and team!
I don’t normally cover products from vendors, be it an established company or a startup. But this one is different
I saw a new bug (Intermittent ManagedObjectNotFound on VirtualMachine.getConf) filed in the open source VI Java API project today:
It looks like sometimes VirtualMachine.getConfig() returns null, but other times it throws:
Caused by: java.lang.RuntimeException: com.vmware.vim25.ManagedObjectNotFound
at com.vmware.vim25.mo.ManagedObject.retrieveObjectProperties(ManagedObject.java:158)
at com.vmware.vim25.mo.ManagedObject.getCurrentProperty(ManagedObject.java:179)
at com.vmware.vim25.mo.VirtualMachine.getConfig(VirtualMachine.java:55)
As the vSphere API reference points out,
After blogging about moving virtual machines from a standard virtual switch to a distributed virtual switch, I saw a new question in VI Java API forum on how to roll it back. Technically, I don’t see any reason why one should switch back because using distributed virtual switch gives you a lot of benefits. But the decision is not mine but yours. Whatever you want to do, we help do it easily.
The method involved is
If you have paid close attention to the SOAP messages recorded by Oynx, you may have noticed that there is an extra attribute called “serverGuid” in a ManagedObjectReference. The following is copied from my previous posting “Moving Virtual Machine to Distributed Virtual Switch”.
<_this xsi:type=”ManagedObjectReference” type=”VirtualMachine” serverGuid=”BA9CE658-75F7-4A99-ACE6-99EB1376B94A”>vm-134</_this>
Note that this SOAP request message is from a vSphere Client. In VIJava API or other language binding, there is no such an attribute. You may wonder,
One of the most common confusions that a newcomer has while learning vSphere API is the ManagedObjectReference, a.k.a MOR. If you read the API Reference, you will find a lot of them. Recently there was a question poping in the open source VIJava API forum. So I think it is worth explaining it here.
There are two major types in the vSphere API: managed object types are for these objects on the server side only; and data object types for properties, parameters, and results, which can be send back and forth between client and server. The MOR is a data object type, but used to represent managed objects living on server side. If you are familiar with C/C++ programming, you can think of it as pointer in some sense. Even better,
Yesterday I blogged about the least used API in VMware vSphere. This naturally leads to another question, “what is the most used API in vSphere?” It’s a harder question than the “least” one, because for the latter I can be very sure that zero is the lowest possible usage. If that API is not the least, it must be one of the least.
Before we try to figure out the answer, let’s clarify a bit the “most used.” Does it mean the one that is called the most times? Does it mean the one that is touched and used by most developers?
Last week I was extremely busy working on the VI(vSphere) Java API 3.0 (codename: Crescendo) whose main theme to support the next release of vSphere. To my surprise, I caught on an API that should have been included in vSphere Java API 2.1 but somehow omitted. Even surprised to me is that no one has reported to me via our sourceforge.net tracker.
I think the conclusion can only be one –
English
Recent Comments