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:// -remote
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
./extension-registration.sh -action
registerPlugin -url https:// -remote
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
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
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:// -remote
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
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:// -remote
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
./extension-registration.sh -action
registerPlugin -url https:// -remote
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
./extension-registration.sh -action
registerPlugin -url https:// -remote
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
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
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.