VMware vSphere SDKs and Tools 8.0

8.0 7.0 6.7 6.5

vSphere Client SDK 8.0 Update 2 Release Notes

This document contains the following sections

Introduction

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
.

Content feedback and comments