VMware {code} Community
atoka
Contributor
Contributor

Supporting third party web client plugin in Enhanced Linked Mode vCenter Server setup

As per VMware document we are supposed to install the same plugin(our custom plugin) instance to all vCenter Servers in Enhanced Linked Mode vCenter Server setup, but we have a situation where our external plugin web server can handle only one vCenter Server at a time and so we want to install same plugin exposed by different external plugin web server to different vCenter Servers in linked mode. This is not going to work as the plugin id is the same and vSphere Web Client service will only load the one which was registered first.

How can we work-around in this situation?

Is changing the plugin id for each instance of external plugin web server a good solution?

Thank you!

Reply
0 Kudos
1 Reply
_vladi_
VMware Employee
VMware Employee

Hi,

This is a great topology question - we will be having more and more of these going forward!

Having a separate ID is not going to scale well because it means the customer would have a separate plugin downloaded into the Client for each instance of your plugin server and vCenter.

I think you definitely want to check the new Remote plugin architecture part of the vSphere Client SDK 6.7U1 which is GA since yesterday. Your case is one of the prominent reasons remote plugins came to be.

In essence, it allows delivering a piece of UI from the plugin server that is connected to the relevant vCenter of the selected inventory object. If a global view is selected the vSphere Client would automatically show an instance selector to the user to choose which UI they want served. This allows widely varying versions to coexist robustly even if they are using different APIs.

To summarize, Remote plugins differentiate between plugin "instances" even if they are the same plugin with the same version. As such this is multi-version multi-instance support for plugins.

Practically, if you already developed some UI the old way it can be reused. What changes is that it will need to be served from the plugin server, not deployed in the vSphere Client application server.

Please check the Remote plugins developers guide and let us know if that helps you.

 

As far as the existing local plugin architecture is concerned you can make a single local plugin (regardless of where it is downloaded from) talk to each of the plugin servers OR have a master plugin server that talks to the other plugin servers and vCenters. In those cases you have to take care of versioning yourself and the plugin (or the master plugin server) needs to have a bit more advanced Java backend logic to route requests properly.

 

Cheers,

Vladi

Reply
0 Kudos