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.
There are new managed object types, new methods to existing managed object types, and new parameters to existing methods of existing managed object types. Among of these three types of additions, the new managed object types are the most important ones as they are most likely associated with new features in the vSphere product (not 1 and 1 mapping though). If you want to take time to read what’s new in vSphere 5.5 product, it definitely worths the time for a bigger context first. Here is the VMware official document What’s New in VMware vSphere® 5.5 Platform.
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.
There are totally 6 new managed object types added to vSphere 5.5. The following is a brief introduction of each of them and my comments on the design.
The DatastoreNamespaceManager is for “manipulating top-level directories of datastores which do not support the traditional top-level directory creation.” It has two methods: createDirectory() and deleteDirectory(). I don’t see anything related to namespace, so I don’t think it’s a good name. Moreover, it does not seem justified to have this new managed object type in my opinion – the two methods should have been easily added to the existing Datastore managed object.
The HostGraphicsManager “manages the graphics state of the host.” It has one property (graphicsInfo) and two methods (isSharedGraphicsActive(), and refreshGraphicsManager()). The methods are indeed very simple in terms of their responsibilities and signatures.
The HostVFlashManager object is used to “configure vFlash resource and vFlash cache on the ESX host.” With the added support of flash, it makes senese to have a managed object to manage this feature. The design is consistent with the other managed objects related to HostSystem.
The HostVsanInternalSystem “exposes low level access to CMMDS, as well as draft versions of VSAN object and disk management APIs that are subject to change in future releases. No compatibility is guaranteed on any of the APIs, including their prototype, behavior or result encoding.” As another important technology in storage, VSAN is getting momentum. The managed object has four methods (QueryCmmds(), QueryObjectsOnPhysicalVsanDisk(), QueryPhysicalVsanDisks(), QueryVsanObjects()). As their names suggest, these methods are for querying information from VSAN, not configuring VSAN. In other words, they are read-only.
The HostVsanSystem “exposes VSAN configuration primitives and serves as a host-level access point for relevant VSAN data objects.” It has one property and 7 methods (
addDisks_Task, initializeDisks_Task, queryDisksForVsan, queryHostStatus, removeDisk_Task, removeDiskMapping_Task, updateVsan_Task). To me, the design of this managed object and the HostVsanInternalSystem is not quite clear and does not really make senese.
The OpaqueNetwork “defines an opaque network, in the sense that the detail and configuration of the network is unknown to vShpere and is managed by a management plane outside of vSphere. However, the identifier and name of these networks is made available to vSphere so that host and virtual machine virtual ethernet device can connect to them.” The very interesting part is that OpaqueNetwork does not define any new property or method beyond what are inherited from its super type Network. It’s still possible that it has something more via VMware’s private APIs. Exposing a new managed object without new responsibility does not make much sense programatically, but does conceptually. It’s like promoting someone to be a manager but continue to do the same things as before, nothing more. This is not the first time though. VmwareDistributedVirtualSwitch managed object type used to be like this, but has a new method as this 5.5 release. That means VMware DVS now has something more than Cisco Nexus 1000V in terms of management APIs from VMware’s view.