vRO plugin for vcenter stuck downloading after update to 6.7 U2a

[darrenoid]

After updating vcenter from 6.7 to 6.7 U2a, we have noticed a task stuck in progress for the last 12+ hours downloading the vco/vro plugin for vcenter. If I go to the vcenter plugins page I can see it stuck in progress:

Has anyone else experienced this? I was going to try a vcenter appliance reboot over the weekend to see if it helps, but was wondering if there is anything else I can try to re-initiate this plugin deployment. It was kicked off automatically after the appliance update.

Thanks,

~Darren

[daphnissov]

Since that's vRO 7.3.1, have you tried updating the plug-in for the web client inside vRO?

https://communities.vmware.com/docs/DOC-35002

[darrenoid]

I haven't tried this. Is there something wrong with 7.3.1? We recently updated vRA with embedded vRO to version 7.6 before the vcenter update. I would like to use whatever comes stock with the embedded vRO after the upgrade, which looks like version 7.3.1?

The vcenter flash client shows the plugin status a little bit differently:

[daphnissov]

It may be that you need to unregister the extension and re-register if the HTML5 client is reporting the old version. 7.3.1 was a hot mess so no telling if something got lodged in vCenter or not.

[darrenoid]

I found a log on vcenter /var/log/vmware/vsphere-client/logs/vsphere_client_virgo.log that has some info:

[2019-05-23T04:11:11.214Z] [ERROR] vc-extensionmanager-pool-104 70000028 100004 200002 com.vmware.vise.vim.extension.VcExtensionManager                  Package com.vmware.vco was not installed. Error expanding zip file found at https://<IP-redacted>:8281/vco/vsphere-web-client/vco-plugin.zip. Make sure it is a valid zip file then logout/login to force another download. java.util.zip.ZipException: zip file is empty

From the vro server I can see the zip file there and it is 6.7M. What seems strange is the vro server is not listening on port 8281 at all according to netstat, not sure if that is expected behavior.

[daphnissov]

If it's an embedded vRO/vRA server that's normal because everything is run through the vRA appliance's rHTTP proxy. If it's external vRO then there's a problem somewhere, maybe with firewalls, routes, or something else in the network.

[darrenoid]

We are using the embedded vRO on the vRA appliance. I think what happened was at some point someone tried to register the embedded vRO with vcenter, but from what I have been seeing online, this is not recommended and may not even be possible. That is to run the embedded vRO workflows from the vcenter web client, which is what I believe this com.vmware.vco plugin is for.

Using the managed object browser for vcenter, https://vcenter-server-host/mob/?moid=ExtensionManager I can see the plugin listed, and in the server property multiple vRO instances are listed including the embedded vRO. In the past we have used external vRO instances for testing, but no longer use them. On the vcenter server itself, I cannot see the plugin in the /etc/vmware/vsphere-client/vc-packages/vsphere-client-serenity/ directory.

vRA seems to be working fine without the plugin and we do not need this functionality in vCenter at the moment. What is the best way to unregister this plugin from vcenter?

[daphnissov · Accepted solution]

The embedded vRO shouldn't be used to register against vCenter for the Web Client plug-in. To fully remove it (if you can't run the unregister vRO workflow), use the vCenter MOB to unregister all instances of that extension. You may need to cycle at least the vsphere-client service after that.