Differentiating Plug-in Instances
Last Updated December 16, 2024

When the vSphere Client checks the vCenter Server's Extension Manager for new remote plug-ins it also checks for new instances of a remote plug-in. If the vSphere Client finds two extension registrations in two different vCenter Server instances such that the extension ID and extension version are the same but the plug-in manifest URL (ExtensionClientInfo.url) is different, then these two extensions are considered to be different instances of the same remote plug-in. If the plug-in manifest URL is also the same for both registrations, both vCenter Server instances share the same plug-in instance.
For example, consider an ELM environment with three vCenter Server instances. Suppose that the following extension registration commands are issued:
./extension-registration.sh -action registerPlugin -url https://
vc1
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver1
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin1_server_thumbprint
-remote
./extension-registration.sh -action registerPlugin -url https://
vc2
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver1
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin1_server_thumbprint
-remote
Both VC1 and VC2 have the same plug-in manifest, and thus the same plug-in server. This is considered to be a single plug-in instance, registered with two vCenter Server instances.
Partial Coverage by Singleton Plug-in
This diagram shows a topology where a single plug-in instance registers with some, but not all, vCenter Server instances.
In this topology, browsers connected to VC1 or VC2 will see the same object-specific views. In a global view context, a browser connected to any of the linked vCenter Server instances displays a view selector that enables the user to choose a path to the plug-in server. Both VC1 and VC2 provide a proxy route to the same plug-in instance.
Now suppose that we register the following extension in VC3:
./extension-registration.sh -action registerPlugin -url https://
vc3
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver2
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin2_server_thumbprint
-remote
The extension registered in VC3 has the same ID and version as the one registered in VC1 and VC2 but has a different manifest URL. When the extension is registered, the vSphere Client will detect that this is a different instance of the remote plugin with ID
com.example.remoteplugin.test
, version
1.0.0
. The UI will show the following behavior:
  • Object-specific views declared by plug-in instance 2 (registered in VC3) will be shown for the corresponding objects from VC3. However, the views declared by instance 1 (registered in VC1 and VC2) will be shown for objects from VC1 and VC2.
  • For global views, a single entry point in the object navigator displays a plug-in instance view selector where the user will be able to switch between the global views supplied by either of the two plug-in instances.
Different plug-in instances can also have different plug-in versions. For example, consider an ELM environment with three vCenter Server instances. Suppose that the following extension registration commands are issued:
./extension-registration.sh -action registerPlugin -url https://
vc1
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver1
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin1_server_thumbprint
-remote
./extension-registration.sh -action registerPlugin -url https://
vc2
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver1
.example.com/path/to/plugin.json" -v "
1.0.0
" -st
plugin1_server_thumbprint
-remote
./extension-registration.sh -action registerPlugin -url https://
vc3
.example.com/sdk -u "Administrator@vsphere.local" -p 'Admin!23' -c 'Example, Inc.' -n 'Remote Plugin Test' -s 'A test plugin demonstrating plugin instances' -k com.example.remoteplugin.test -pu "https://
pluginserver2
.example.com/path/to/plugin.json" -v "
2.0.0
" -st
plugin2_server_thumbprint
-remote
In this topology, VC1 and VC2 are running with a single instance of the plug-in, at version
1.0.0
, while VC3 is running with a second instance of the plug-in, at version
2.0.0
.
Remote Plug-in Version Differentiation
This diagram shows a topology where two different versions of a plug-in
					register with different vCenter Server instances.
The newer version might have support for new features, such as changes in the API. This capability allows a plug-in to support custom features for some managed objects. It also can help to facilitate testing and rolling upgrades.