Differentiating Plug-in Instances
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
"[email protected]" -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
"[email protected]" -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.
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
"[email protected]" -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
"[email protected]" -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
"[email protected]" -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
"[email protected]" -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.
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.