This past weekend I finally got a chance to upgrade my personal homelab to vSphere 8, which went super smooth! As shared on Twitter and Mastadon, I started with my VCSA which was running vSphere 7.0 Update 3h and once that had completed and running for a couple of days, I then upgraded my single ESXi host which was running 7.0 Update 3g which runs on Supermicro E200-8D.
just successfully upgraded Supermicro E200-8D from 7.0u3g to ESXi 8.0, though I had to add HW flag as CPU may not be supported in future
ESXI_VERSION=ESXi-8.0.0-20513097-standard
esxcli software profile update -d https://t.co/cs4yUyvnxQ -p ${ESXI_VERSION} --no-hardware-warning pic.twitter.com/hnEspuEDpE— William Lam (@lamw.bsky.social | @*protected email*) (@lamw) November 20, 2022
After was functional after the upgrade, including the VMware Event Broker Appliance (VEBA) UI Plugin 😀
This morning, I happened to navigate over to the vSphere UI Client Plugin screen under Administration->Solutions->Client Plugins and I noticed I had one plugin named "N/A" and was was showing incompatible.
I was not sure what the plugin was and raised this internally with the vSphere UI team on whether this was expected and if there was something I needed to do. It turns out this was the default vCloud Availability plugin for vCloud Director that ships with a vCenter Server deployment and it uses the deprecated local plugin architecture and this particular version of plugin is no longer applicable or compatible with vSphere 8.
With that said, there is a newer version of the plugin that is deployed automatically as part vSphere 8 called VMware Cloud Provider Services Plugin and it also uses the new remote plugins architecture. The question that I had was that since this is a default plugin that is shipped with vCenter Server and a newer version is automatically available, why not clean up or remove the previous plugin? The answer that I had received was that customers could be using this plugin in a Linked Mode configuration and unregistering the plugin would negatively affect those users and hence it was left alone.
If are NOT using this plugin, it is safe to unregister and remove the plugin. Unlike a typical vSphere UI plugin which can be simply be unregistered using the vSphere UI as of vSphere 8, this plugin uses the old vSphere Lookup Service method and require a few additional steps.
Step 1 - SSH to the VCSA as root
Step 2 - Use the Lookup Service utility (lstools.py) to find the service ID for the plugin you which to unregister by running the following command:
/usr/lib/vmware-lookupsvc/tools/lstool.py list --url http://localhost:7090/lookupservice/sdk --product com.vmware.h4
You should get back only single response and make a note of the Service ID which is required in the next step.
Step 3 - We can now unregister the plugin by providing the Service ID along with the administrator credentials by running the following command:
/usr/lib/vmware-lookupsvc/tools/lstool.py unregister --url http://localhost:7090/lookupservice/sdk --id 9372294c-254e-4f87-8346-9ebdb4b44525 --user administrator[at]vsphere[dot]local --password VMware1!
Step 4 - Finally, we need to restart the vSphere UI Client service for the changes to take affect by running the following command:
service-control --restart vsphere-ui
If you now refresh your vSphere UI, you will no longer see the "N/A" plugin.
Upgraded my home lab HPE ML350 Gen 10 to 8.0 with no trouble.
The upgrade on my HPE DL380 Gen 8 to 8.0 warned me that the E5-2600 CPU’s aren’t on the HCL, but they ran fine. The nice thing about 8.0 is it sees the HPE iLO card and related data about the server. The upgrade from VCSA 7 to VCSA 8 went complete flawless.
Thank you, William, great writeup. Helped me to keep my sanity with this annoying incompatible plugin. Kudos!
Hi William,
Sorry,
I tried to use your hint to delete com.vmware.h4.vsphere.client with incompatible status at two vCenter 7.0.3 (21477706).
it fails with the following line at the output:
Caused by: com.vmware.vim.sso.client.exception.AuthenticationFailedException: Provided credentials are not valid.
I am sure that entered credentials were correct.
How can I troubleshoot the issue ?
What credentials did you use, it should be administrator[at]vsphere.local account
I did this and I was using administrator[at]vsphere.local credentials
This is a terrific write-up. Unfortunately I had the same issue with failed creds. I did try one or two others just in case but I also am sure the credentials are correct.
Specifically the error:
2023-11-28T13:55:59.475Z ERROR lookup-client[1:main] [com.vmware.vim.sso.client.impl.SoapBindingImpl] SOAP fault
javax.xml.ws.soap.SOAPFaultException: Invalid credentials
I had the same problem. My solution was to set the password to "". After that everything worked.
We have a password that contains characters "!" and a "."
and this doesn;t work in shell commandline..
Just escape using single-ticks 🙂
to put SSO admin password containing ! and $ into ' ' was the solution for me. You saved my day! Thank you so much, William !
As always, William, your blog posts are indispensable!
Thank you, assisted me in removing the h4va.zip plugin from our environment.
Thanks for the clear, concise and accurate procedure William!
Thank you for sharing this procedure to remove com.vmware.h4 plugin.
Thank you for this!
However, after entering the password in the shell, it is now in history, and potentially in logs. How do we clear this?
I think I found it: rm /root/.bash_history
Is that all we need?