As every year, some of my customers use the weeks after Christmas to update their environments. Nearly all of them run their ESXi hosts with vendor-specific Custom Images that provide additional drivers or agents over the standard VMware image. Unfortunately there are almost always problems with conflicting VIBs when they are updated. Of course it was the same this time. In my case, this time it was about a custom image from Fujitsu.
To perform the update successfully the problematic VIB must be removed. The necessary steps for this I would like to point out below.
But first some Background. During the offline window we replaced an old ESXi Host of the cluster with a new, matching physical Server. This also allowed us to finally upgrade the entire cluster to VMware vSphere/ESXi 6.7. To ensure sufficient resources for the VMs, we first had to install the new server with ESXi 6.5 and add it to the existing cluster. After that we were able to decommission the old host. In the first step of the actual update, we then updated the vCenter Server Appliance (VCSA) from version 6.5 to 6.7. Then it was the time for the ESXi hosts.
I personally like to use the offline bundles for the ESXi update, because I can easily perform the update via SSH using the management IP address of the host. You can find out how to update via CLI here. In this case, I did not use VMware’s online repository but a Custom Offline Bundle previously stored on a shared datastore. Unfortunately the first attempt ran into the error shown above. Therefore I had to delete the corresponding VIB manually first. To do so I had to find out the exact name of the VIB. With the following command you get a list of all installed VIBs including their names.
esxcli software vib listTo make the display a bit clearer I filtered the output directly by a certain keyword (in my case „LSI„).
esxcli software vib list | grep LSIAnd already I had the exact name needed for the next step.
Now it is time to remove the VIB. There is also a suitable esxcli command for this.
esxcli software vib remove -n <name of the VIB>
When the command is completed the VIB is successfully removed. Now the update can be tried a second time. And look: This time it worked (I shortened the output a bit). But I have already made the experience that after the first VIB further VIBs had to be removed before the update could be installed.
After a final reboot the host came up with the new version.
Wrap-Up
Even though the custom images have some advantages in operation, they always make an update more exciting than it should be. In most cases the additional vendor specific VIBs can be removed without problems. If you are not sure, it is still worth checking the VIB affected components before removing them.Usually an updated version of the VIB is reinstalled by the Custom Offline Bundle anyway. Otherwise the next update would be too easy 😉
