Does vSphere 7.0 SDK Remote plugin sample support Singleton Plug-in pattern?

[shravansofts]

Hi Team,

I'm trying to test Singleton Plug-in topology as mentioned in Remote plugin SDK documentation(vsphere-client-sdk-7.0.0.10100-15863815).

In order to test that, I had registered same instance of plugin with multiple vCenter servers(of 7.0 version in Enhanced Linked Mode) and able to see the plugin by connecting to both vCenters.

But the chassis list actions are always listing VC1 related host list only which is used for manifest server startup command as shown below:

java -jar target/remote-plugin-sample-6.7.0-SNAPSHOT.jar --vcenter.guid=5xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx --vcenter.thumbprint=1xxxxxxxxxxxxxxxxxxxxxxxxxx --vcenter.fqdn=vc1.com --vcenter.port=443

Below are the queries:

1. Is it possible to achieve the singleton plugin instance working using the given sdk sample and tools? If so what is the command options we should use to support multiple vCenters?

2. What are the file/function changes we need to make in service/ui code to support this routing?

Thanks

Shravan

Message was edited by: shravansofts

[amarinov]

Hi Shravan,

1. Is it possible to achieve the singleton plugin instance working using the given sdk sample and tools? If so what is the command options we should use to support multiple vCenters?

The provided sample does not support working with multiple vCenters.

2. What are the file/function changes we need to make in service/ui code to support this routing?

- Your plugin should accept multi-VC configuration at startup. Instead of passing multiple command line parameters in the form: "--vcenter.guid=5xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx --vcenter.thumbprint=1xxxxxxxxxxxxxxxxxxxxxxxxxx --vcenter.fqdn=vc1.com --vcenter.port=443" you should pass a JSON file that contains an array of VC configurations and parse that file to a Java object using Jackson or a similar library.
- When your plugin front-end is making a call for a specific object you should pass the target object ID and target VC GUID as part of the REST call. Then your plugin backend should make an API call to that VC, whose IP it should derive from the target VC GUID and plugin configuration. E.g. a view of your plugin is rendered in Cluster -> Monitor and you want it to show some properties of the cluster, then your REST call should contain the cluster object ID and the VC GUID.
- When your plugin front-end is making a call that queries all VCs with which your plugin is registered, then the respective plugin backend API should query all VCs present in the plugin configuration. E.g. your plugin has a global view that has to display some properties of all VCs with which your plugin is registered.

Thanks,
Aleksandar

[shravansofts]

Thanks for the response.

As vCenter Client SDK 7.0U1 is released recently, I'm going through its SDK documentation. Surprisingly, I could not find the singleton plugin pattern

7.0U1 SDK:(Singleton topology is missing ) Online Documentation - Developing Remote Plug-ins with the vSphere Client SDK (7.0 Update 1) - VMwar...

Singleton plugin topology in 7.0 SDK: Online Documentation - Developing Remote Plug-ins with the vSphere Client SDK - VMware {code}

• Is this intentional or a miss?
• Does VMware support a singleton plugin topology (single plugin instance registering to multiple vCenters in ELM) in future releases?
• Does VMware have any recommendation like each vCenter server should have its own plugin instance (1:1 mapping)?

Our new product design is based on singleton plugin topology this is going to be a big impact on our plans. Please provide the info for the above queries.@

Thanks,

Shravan

[_vladi_]

Hi Shravan,

Thank you for catching this documentation discrepancy.

 - Is this intentional or a miss?

It's a mistake which will be fixed. The Singleton and Custom Plug-in Topologies section is still applicable in 7.0U1.

 - Does VMware support a singleton plugin topology (single plugin instance registering to multiple vCenters in ELM) in future releases?

Yes. It is supported. Please check the doc section mentioned above. 

 - Does VMware have any recommendation like each vCenter server should have its own plugin instance (1:1 mapping)?

Each vCenter Server can have only 1 plugin instance serving the plugin UI but each instance can be registered with multiple vCenters as discussed above.

For other non-UI purposes you can also add auxiliary servers together with the same plugin instance registration with a vCenter.

Cheers,

Vladi

Is this intentional or a miss?

Does VMware support a singleton plugin topology (single plugin instance registering to multiple vCenters in ELM) in future releases?

Does VMware have any recommendation like each vCenter server should have its own plugin instance (1:1 mapping)?