Some of the troubles come from the disconnect between conventional programming model and that of vSphere API. In this blog, I summarize the top 5 myths about vSphere API based on my experience and the questions I see in the VMware community forum and vSphere Java API forum:
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.
- Non-existing Managed Objects
- Pervasive PropertyCollector
- Short-Lived Task Object
- “Weak” HostSystem
- “Un-documented” View
Let’s examine each of them one by one.
Non-existing Managed Objects
People talk about managed objects all the time, but you don’t see any of them while coding with Web Service SDK. There is a disconnect between Web Services API and the API Reference. On one hand, the API Reference has nice descriptions of all managed objects; on the other side, you don’t find any of them in any of the sample code.
Well, by nature Web Services is procedural and it does not support OO directly. All the methods of all the managed objects are flattened out into a single jumbo interface. To identify the managed object, a ManagedObjectReference is added as the first parameter. You can find the same idea when you want to emulate OO programming in C.
Open source vSphere Java API re-constructs all the managed objects, therefore you can find them and take advantage of real OOP besides huge performance gain.
If you have ever read or written any code with vSphere Web Services, you must know PropertyCollector to some extent. It’s a powerful managed object that is used to get properties from the server side.
It’s very powerful yet very hard to use. The related code is too long for its purpose. To get a simple property out of the server, you may end up at least 20 lines of code. Although most people don’t like it, but cannot get away from it because it’s the only way to get any properties of any managed objects.
Beyond the basis property retrieval, the property collector supports advance features like object traversal which allows you to define paths to search for objects, and change notification which pushes the changes from the server to the registered clients.
To simplify this, vSphere Java API adds getter methods for every property. So the complexity is removed totally. You can still use the collector for advanced features.
Short-Lived Task Object
Task is returned from a asynchronous call (with a name pattern *_Task), so that the client can still track the progress of a un-finished work. There are many questions related to this, for example, the property cannot be retrieved. 9 out 10 times, it’s related to the fact that it’s retrieved a little while after the task is finished. By default a task only lives for about 10 minutes after which you cannot do anything with it, even though you still have the handle (ManagedObjectReference) to it.
You have to use TaskHistoryCollector to retrieve the finished tasks.
Compared to other managed entities like VirtualMachine, you may find the HostSystem is weak in that you can’t do much with it. But it corresponds to the hypervisor which is the critical part in the virtualization kingdom.
It turns out that there are so much to do with the hypervisor that the functionalities are divided and delegated to other attached managed objects, like HostNetworkSystem. These managed objects has a naming pattern, all starts with Host*. If you have trouble to find a right method in HostSystem, try these Host* types.
The View family of managed objects were originally designed for vSphere Client. It allows the Client to specify what managed objects to watch based on their visibility. You don’t want to get notified about a change of virtual machine that is invisible to the user.
If you look at the official programming guide and samples, there is nothing about this. The API reference has nice descriptions on each of the types. Without a sample showing how they work together, it’s hard to get started. If you are developing a GUI application, you may want to follow the footsteps of VMware.
There may be more myths while you learning the vSphere API. Please feel free to share them here. I can change the title to Top X myths later on.