Issue registering an extension using the MOB on vSphere 6.7

[jvitorino]

We recently noticed that we can no longer use the MOB to manually register our extension.  The registration seems to work, however when I attempt to log into vCenter I see an error in the virgo log indicating that the ZIP file can't be downloaded:

[2019-04-24T15:01:40.317-04:00] [WARN ] vc-extensionmanager-pool-125 70000139 100018 200002 com.vmware.vise.vim.extension.VcExtensionManager                  Package com.simplivity.web-client was not installed. Error downloading https://10.147.50.130/simplivity/simplivity-web-client-16.46.1022.zip. Make sure that the URL is reachable then logout/login to force another download.

I'm able to use the URL that's displayed in the warning message within a browser and the ZIP file downloads fine.  Prior to 6.7, we regularly unregistered and registered using the same procedure and things always worked however now it seems like something must have changed. 

Is anybody else running into this?  Has anybody else been successful at registering an extension using the MOB?

[jvitorino]

After posting this, I was able to work around the issue by using HTTP instead of HTTPS for the URL to the plug-in package ZIP file.  I double-checked the SHA1 thumbprint in the XML that I am using and that seems correct so I'm not sure why HTTPS isn't working for me.

[jvitorino]

Should I be posting this question under a different forum?  If so, could you please recommend which one?

Thank you,

Jesse

[Denis_Chorbadzh]

Hi Jesse,

May I ask you to try and use the extension registration tool available from the vSphere Client SDK deliverable and see if the issue exists there.

You can find the tool in "<your_sdk_folder>/tools/vCenter plugin registration/prebuilt".

Here is the link to the vSphere Client SDK Documentation (see page 36 of "Developing Local Plug-ins with the vSphere Client SDK (6.7 U2)"): https://code.vmware.com/web/sdk/6.7/client

Have in mind that the thumbprint should be specified in the following format: 99:FD:2B:0D:12:85:37:AA:DA:A0:08:E1:F4:3B:4A:E6:08:AC:49:CD

99:FD:2B:0D:12:85:37:AA:DA:A0:08:E1:F4:3B:

4A:E6:08:AC:49:CD

In addition, I think that using the tool is way easier than using the MOB.

Thank you for the feedback,

Denis

[jvitorino]

Using the tool to register was successful.  Does this help identify why using the MOB doesn't work?  There are instances where we need to manually unregister and register our extension in a customer's environment and being able to use the MOB is less intrusive than asking the customer to download and execute a tool on their system.

[Denis_Chorbadzh]

Hi Jesse,

Thank you for the response.

I wanted to make sure that the tool available in the SDK works as expected in your case.

Now we can investigate what is different in the two methods and root cause the issue.

Best Regards,

Denis

[tganchev]

Jesse,

Unfortunately the root cause is not immediately visible in the log. We're working on addressing this in subsequent vSphere releases.

In the mean time to figure out what's wrong you need to enable the DEBUG-level logging for the plugin deployer. To do that add the following to the logging configuration (/usr/lib/vmware-vsphere-ui/server/conf/serviceability.xml for the HTML client or /usr/lib/vmware-vsphere-client/server/conf/serviceability.xml for the Flash client)

   <logger level="DEBUG" additivity="false" name="com.vmware.vise.vim.extension">

      <appender-ref ref="LOG_FILE" />

   </logger>

- just before the trailing closing </configuration> tag.

Then, clean the plugin cache folder and restart the UI service.

You should see information about the correct root-cause of the exception coming from the com.vmware.vise.vim.extension.VcExtensionManager appender.

Let me know what happens when you try that.

Tony

[_vladi_]

Hi Jesse,

Next to what Tony requested please provide the xml you are using to manually register your plugin so that we can try to reproduce the issue.

Cheers,

Vladi

[jvitorino]

Here is the snippet of the log file with adding logging enabled as well as the XML that we are using for the manual registration.  I've also include a screenshot showing how I've gotten the thumbprint which I've using the XML file.  This procedure has worked and is working in other version of vSphere.  Thank you for your help.

[_vladi_]

Hi Jesse,

Looking at your screenshot I see that the IP of your Client and the IP where the .zip is hosted are the same. Could you please elaborate on how you are hosting the zip?

Generally, the plugin zip should be served by your backend appliance. Also the thumbprint should be the one you see in the shown box in the browser but when you navigate to your zip, not to the vSphere Client like it is visible in the screenshot.

Cheers,

Vladi

[jvitorino]

We copy our ZIP file into a subdirectory of vmware-vpx/docRoot (C:\ProgramData\VMware\vCenterServer\cfg\vmware-vpx\docRoot\simplivity) and serve it from there.  This is the reason that the IP ad the thumbprint match.  We haven't hit a problem with this deployment scheme until recently (6.7) and we have only noticed this issue on a vCenter.  VCSA seems to be working as it has in the past.

Thank you,

Jesse

[_vladi_]

Hi Jesse,

This is not a supported scenario in Production and is also related only to the deprecated vCenter for Windows so a variety of things might break when using such an approach for serving the plugin. It is recommended to serve the plugin from your appliance.

Looking at the logs the thumbprint verification failed. Have you changed certificates on this vCenter environment? Do you reproduce it on a fresh environment?

Cheers,

Vladi