Seems like Dell fixed their repository and vLCM can now download the VIBs again as it should when adding a VIB to an image.
Here is the original article I wrote
We have been using the Dell depot in vLCM for a while but since a couple of days we see issues when we try to include some VIBs in an image. Including in the image works, but as soon as we try to remediate a host, vCenter try to download the VIB but that fails and thus remediating the host fails.
We added the Dell repository to our vCLM config:
Next thing we do is add a VIB from this repository to the image we will apply to our cluster:
But when we try to remediate the cluster, it tries to fetch the VIB from the Dell repo but fails …
It seems like the VIB that needs to be downloaded is not available at the URL vCLM gets from the Dell repository ….
I am able to access https://vmwaredepot.dell.com from my vCenter Appliance but trying to fetch the VIB gives me a 404 error: (In this screenshot a proxy is used, but even with a direct connection it fails)
Seems to me like Dell changed the directory structure on https://vmwaredepot.dell.com but forgot to update the xml index file ….. Getting in touch with Dell to get this fixed, will update this article when I get more info.
When vSphere 6 was released, I decided to delete my RTM version of my external Platform service Controller and vCenter Server appliances, to replace them by the GA versions.
Installing the PSC went fine, but when installing the vCenter appliance, I was not able to register it to the PSC. I kept getting the message “Invalid credentials” every time I entered the SSO administrator password. Redeployed the PSC several time, using different passwords, but no luck registering the VCSA.
While upgrading vCenter to 5.1 in an environment where we used local authentication on the vCenter server, we were in for a little surprise.
The original vCenter server had a lot of custom roles and user permissions defind, on all kinds of objects in vCenter.
When we did the upgrade, we decided to install the SSO server on a separate server, and when we did the vCenter upgrade and it was registered with the SSO server, we suddenly received a message that users and groups where not found on the SSO server, which kind of made sense, since even though we recreated the users and groups on the SSO server, they had different security IDs. But what we did not expect, is the upgrade process decided to remove all non existing users and groups from the vCenter database, effectively removing all permissions from vCenter … Continue reading →