The vSphere 6.7 Update 2 release brings a number of enhancements to the vSphere Client. One important update is a new way to monitor vSphere Client plug-ins lifecycle with the Plugin Management UI.
Up to vSphere 6.7 Update 1 the plug-in deployment process has been taking place behind the scenes. Any errors caused by a wrong configuration, plug-in faults or product incompatibility have only been available in the logs making troubleshooting by admins or support engineers very difficult. This has been particularly challenging during upgrades of vSphere or partner solutions.
The Plugin Management UI significantly improves the visibility and transparency of the plug-in installation workflow by reporting plug-in error and incompatibility information together with possible remediation steps. This enables plug-in lifecycle monitoring and error root cause analysis directly through the UI without having to locate and dig through verbose log files.
Monitoring via Client Plug-ins view
The Client Plug-ins view under Administration now displays all registered plug-ins with any vCenter Server in the environment. Each plug-in is listed with its current deployment state: In Progress, Deployed, Failed or Incompatible.
Failed and Incompatible plug-in deployment states contain a signpost link that includes more details about the reason of the issue (or type of incompatibility) and optionally any available error stack traces.
Tracking Plug-in Lifecycle via vCenter Server Tasks
A plug-in goes through various installation phases which are now exposed by dedicated vCenter Server tasks for plug-in download and deployment. All plug-in tasks are created through the public vCenter Server TaskManager API available to use by partner solutions as well. The vSphere Client supports live refresh of vCenter Server tasks which enables the customer to observe the installation process of all plug-ins without manual UI interaction.
Tasks are available on 3 user interface locations:
Recent Tasks panel
Task Console
Monitor Tasks view of the current vCenter Server inventory object
Plug-in tasks are created on the vCenter Server instance the vSphere Client is currently running on. Each task represents a deployment operation of a specific plug-in on a particular vCenter Server instance which is considered as task’s target object. In Enhanced Linked Mode the plug-in tasks created on all vCenter Servers are displayed in the Task Console of any instance of the vSphere Client. Admins can recognize the tasks associated with plug-in deployments on a particular vCenter Server by filtering on the Target grid column.
Plug-in Deployment Workflow
When a user logs in to the vSphere Client all plug-ins registered with any vCenter Server in the environment are downloaded from the vendor appliance to the vSphere Client’s cache folder on the vCenter Server. To track this operation a “Download plug-in” vCenter Server task is spawned for each plug-in. Its successful completion indicates the plug-in files are now present in the vSphere Client cache folder and are ready for deployment.
As a next step a new “Deploy plug-in” task related to the same plug-in is started. Completed “Deploy plug-in” task indicates that a plug-in is successfully deployed and usable within the vSphere Client. In the event of a download failure the “Deploy plug-in” task is skipped.
Errors at any stage of the process are displayed in the plug-in task’s details view:
The task details is populated with the error stack trace if one exists. This serves as a more descriptive input for problem analysis which cannot be fully categorized by the vSphere Client. For example, external server exceptions, codes and messages are often vendor-specific and are displayed as-is.
Plug-in Upgrade
Plug-ins are upgraded by registering a newer version with the vCenter Server. On the next user login the vSphere Client downloads the new plug-in version, uninstalls the old version and installs the new one. This process is manifested on the UI by “Download plug-in”, “Undeploy plug-in” and “Deploy plug-in” tasks in the Task Console.
A global notification informs all administrators working with the vSphere Client that a new plug-in version has been deployed and they should refresh the browser for the changes to take effect on the UI.
Multi-Version Handling
A single vCenter Server can contains only one registration of a given plug-in. On the other hand, Enhanced Linked Mode and Hybrid Linked Mode environments may contain multiple vCenter Servers with different versions of the same plug-in registered. In this case the vSphere Client handles the known plug-in types differently:
Local plug-in architecture supports a single deployed version which is always the newest version detected from all registrations of the plug-in with the vCenter Servers. It is responsible to communicate with all vCenter Servers and the respective vendor backend appliances connected to them. The newest plug-in version is operational and all other versions are ignored on all vCenter Server instances.
When a newer plug-in version is detected it is installed and the old one is uninstalled. This is represented on the Plugin Management UI as an “Undeploy plug-in” task for the old version and a “Deploy plug-in” task for the new version.
Remote plug-in architecture, introduced in 6.7 Update 1, delivers full support of multiple simultaneously operational plug-in versions. Each version of the plug-in is deployed separately and is dedicated to operating with the exact vCenter Servers it is registered with. This behavior works transparently to the user and is especially important for solution vendors: in Hybrid Linked Mode, where significant deviations between vCenter Server versions can be expected, the latest vendor plug-in version would only have to support the latest vCenter Server version.
Each unique plug-in version is downloaded, deployed and displayed in the Client Plug-ins view and the Task Console as independent plug-in instance.
Common Plug-in Deployment States
As of vSphere 6.7 Update 2 the Plugin Management UI recognizes the following deployment state scenarios that are common in the plug-in ecosystem.
In progress
Shown when the plug-in is still in process of deployment.
Deployed
Shown when the plug-in is deployed and available on the UI.
Failed
Shown when a plug-in installation error occurred. Possible reasons are:
Download error
Download is unsecure – plug-in URL is based on http instead of https.
Plug-in URL is unreachable.
Plug-in registration thumbprint is wrong and the vSphere Client is not authorized to download the plug-in.
Packaging error
Plug-in zip file is corrupt and cannot be expanded.
Plug-in manifest is missing.
Plug-in plugins folder is missing.
Plug-in bundles are missing.
Deployment error
Dependency error occurred during deployment to the vSphere Client application server.
Runtime plug-in error occurred within the plug-in itself.
Incompatible
Shown when the plug-in is not supported on this instance of the vSphere Client. Possible reasons are:
The plug-in is blacklisted by an administrator with sufficient privileges.
The plug-in claims no support for the particular vSphere Client version.
This is a Flash-based plug-in for the vSphere Web Client.
Whenever a corner error case is not handled the UI reports a general download or deployment error. Such errors can be further analyzed using the error stack traces in the Task Console or the Client plug-ins view.
Conclusion
To wrap-up, Plugin Management UI is a great improvement for tracking integration with external solutions. It is based on classic vSphere UI patterns and delivers integrated experience of monitoring and troubleshooting vSphere Client plug-ins through visual workflows.
