vSphere Client SDK 8.0 Update 2 Release Notes

vSphere Client SDK 8.0.2 | 21 September 2023 | Find build on developer.vmware.com For vSphere 8.0 Update 2 | Last document update 10 June 2024 Check back for additions and updates to these release notes, marked New.

About the vSphere Client SDK

The vSphere Client SDK provides sample plug-ins, tools, libraries, and documentation to help developers build user interfaces with vSphere Client extensions for vSphere and VMware Cloud.

Changes and New Features

The vSphere Client SDK 8.0 U2 offers the following New features:

• Support for security certificates.

  Plug-in servers can be registered with a security certificate in addition to, or instead of, a thumbprint (fingerprint). Using a certificate is recommended for greater security. The security certificate of a plug-in server is obtained with a web browser, saved as PEM in a certificate file, and specified by the -serverCertificateFile option of the registration script. You can find registration instructions in the 8.0 U2 developer guide.

• Properties for vCenter Server injected into OVF.

  Additional vCenter Server properties are injected into OVF. In previous releases, properties token, endpoint, and endpoint thumbprint were injected. As of 8.0 U2, properties for count of associated vCenter Servers, vCenter hostname, vCenter guid, and vCenter thumbprint are also injected.

• Tasks console shows installation progress.

  Users can monitor progress of solution installation in the Tasks console, and cancel the solution install task if desired. Previously the Tasks console showed solution was installing but not installation progress.

• Number of defined cards increased from 3 to 5.

  In vSphere 8.0 U1, it became possible for a remote plug-in to create multiple cards. In this release, the limit was raised from three to five.

• File vim25.jar no longer included in SDK.

  Programmers without vim25.jar in their development environment must obtain this JAR file from vSphere Management SDK (under Web Services).

For new features in the previous versions, see the vSphere Client SDK 8.0.1 Release Notes and before.

Compatibility Notices

Local plug-ins for vSphere Client remain functional in the vSphere 8.0 release, but they must be upgraded for compatibility with a number of security-related changes. Local plug-ins must become FIPS-compliant and must isolate their 3rd-party libraries. Partners should migrate all local plug-ins to remote plug-ins as soon as possible.

Recently Resolved Issues

• Multi-manifest no longer requires plugin.json.

  It's no longer necessary to create a file specifically named plugin.json for multi-manifest support.

Known Issues and Workarounds

There are no unresolved issues known at this time.

Avoid Use of /sdkTunnel Endpoint

When vCenter extensions or vSphere clients make connections to the /sdk endpoint, it is on port 443 over HTTPS using TLS to the Envoy proxy, which quickly passes HTTP1 or HTTP2 connections to vpxd for servicing. The current limit is 2K simultaneous connections. Another endpoint /sdkTunnel is largely undocumented. Limited to 1K connections, it is on open port 80 also over HTTPS but the client must first connect with plain HTTP, whereas for /sdk the client initiates TLS directly. Rather than being mediated by the proxy, packets go directly to vpxd, authenticated with mutual TLS (mTLS) so the server can ensure that the client owns the respective private key, on top of TLS where the client validates the server. By design, there is no /sdkTunnel for port 443.

Before deprecation of LoginExtensionByCertificate in vSphere 6.0, direct connection was useful for exchanging security credentials, but because the Envoy proxy cannot see inside TCP packets on /sdkTunnel, it was unable to detect and close zombie connections. So when there were more than 1K simultaneous connections, and the client neglected to close any of them, the Envoy proxy queued requests, the /sdkTunnel endpoint clogged, and long service delays resulted.

Use of /sdkTunnel to authenticate by calling LoginExtensionByCertificate should be discontinued, and replaced with LoginByToken. Going forwared vSphere clients should instead use the /sdk endpoint, which is far less prone to congestion and service delays. You can find sample code that calls LoginByToken in topic “Using LoginByToken in Java” of the vSphere Web Services SDK Programming Guide.