When I was doing a demo today, I got an error saying “An internal error has occurred – Error #1099. Reloading the client is recommended, so as to clear any problems left by this error. Click Yes to reload the vSphere Web Client?” After reloading the Web Client, I got the same error. So something has to be fixed on the server side.
A quick search got me this KB article (2032356). I quickly applied the solution, which is to insert one line as the following at line 79 of /usr/lib/vmware-vpx/inventoryservice/lib/server/config/security-config.xml:
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
<property name="maxUsagePerPrincipal" value="200" />
Nothing had happen, of course – otherwise, I won’t write about it here.
To apply the change, I stop and start the inventory services.
# service vmware-inventoryservice stop # service vmware-inventoryservice start
The problem persisted. Then I had to read carefully the log file: /var/log/vmware/vpx/inventoryservice/ds.log, which includes the following lines:
ERROR com.vmware.vim.vcauthorization.impl.provider.InMemoryAuthCache] Caught unexpected exception: org.springframework.beans.factory.BeanCreationException: Error... Error creating bean with name 'httpsPort' defined in class path resource [server/config/server-config.xml]: Unsatified dependency expressed through constructore argument with index 1 of type [int]: Ambiguous constructor argument types - did you specify the correct bean references as constructor arguments? ...
It basically failed the restarting of the service, which is a bigger problem. At least it could start earlier. So it’s clear the previous change caused the problem. Removing the change and restarting the service seems working fine. The vSphere Web Client came back normal.
To my curiosity, I looked back the original error message in the ds.log file, which had been gzipped up as *.log.*.gz file. To view the content, I had to unzip it first:
vCSA://var/log/vmware/vpx/inventoryservice # gzip -d ds.log.2.gz
It’s then clear that it was originally a DB problem. The XHive database may have a bug as following – it could also be related how vCenter uses the database. Anyway, given this error, all needed was to restart the service. It’s not necessary to restart the vCenter service. My guess is that it doesn’t hurt and may be quite helpful for worse problems.
Caused by: com.xhive.error.XhiveException: FEDERATION_ALREADY_OPEN: Federation /storage/db/inventoryservice/data/xdb.bootstrap is already opened ...