Lifecycle Manager: Downgrades of host VIBs in the image are not supported

[BHagenSPI]

VCSA 7.0.2.00200
Cluster of 6 hosts: ESXi 7.0.1, 17551050

I'm changing from "baseline" to "image" upgrades within Lifecycle manager, and planning to upgrade the hosts to 7.0U2a.

After creating an image, I see the following on all 6 hosts:

 

Is this saying that I have to manually upgrade the ixgben VIB before upgrading? Or that I have to delete that VIB before upgrading? Or that my hosts are simply not able to be upgraded at all?

I don't have a "hardware manager" since these are "generic" Supermicro boxes, so the lifecycle manager doesn't seem to be able to see much info on the hosts.

Thoughts? Thanks!

[BHagenSPI]

For anybody experiencing the same thing, I opened a ticket with vmware about this. The conclusion was:

1. That specific VIB is a non-vmware driver for my NIC, so it isn't included in the standard esxi v7 iso
   
   1. Because it's a "red bang" error, I can't upgrade my host via Lifecycle manager
   2. If I remove the vib from the host, I'll be able to upgrade via lifecycle manager. But...if I remove the vib, there's no guarantee my host will communicate any more, since that vib is for the nic!
2. So, I have to manually upgrade (cli) my esxi hosts. All of them. And apparently I always will, unless at some point vmware decides to package a working driver for an "Intel Ethernet Controller 10 Gigabit X540-AT2" in their iso. 
3. I moved from "baseline" to "image" updates before I knew any of this. Since I can't go back to baseline updates now, and vmware doesn't have a working driver for my nics, lifecycle manager is now useless to me, I guess. *All* updates will need to be done thru the CLI. Wonderful.

BTW, to manually update via CLI, I have to grab the v7 zip file (not iso) from vmware, winscp it to my ISO folder on my vsan, put my host in maintenance mode, log into it via ssh, then run the command:

esxcli software profile update -d /vmfs/volumes/vsan:UUID/ISO/VMware-ESXi-7.0U2a-17867351-depot.zip -p ESXi-7.0U2a-17867351-standard

Then reboot -f

Times 16 hosts.

Gonna be a long couple weeks...

[a_p_]

I didn't "play" with vLCM much yet, but from what I read so far about how it's supposed to work, you may try to see whether it works to download the latest driver from https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=20396 , upload it to the Image Depot, and use it as an additional Component in your baseline.

André

[BHagenSPI]

Wow...thanks! That did the trick, and I'm marking that as the correct answer!

I hope vmware will send this solution to their level 1 support techs; it's too bad I spent all that time on the phone with somebody who didn't know this fix.

[anders_o]

Thanks, that helped me as well, but with a slightly different problem: vLCM was complaining about some components/drivers being newer on the hosts compared to the vLCM image. On the first couple of hosts we "solved" it by going in and downgrading the affected components, but your proposed solution was obviously better.

Our error message was:

"Downgrades of manually added Components
Broadcom Emulex Connectivity Division lpfc driver for FC adapters(14.0.326.12-1),
Broadcom Native 12Gbps SAS/PCIe MPT Driver(19.00.03.00),
Broadcom Native MegaRAID SAS(7.719.02.00),
Broadcom NetXtreme-E VMKAPI network and RoCE driver for VMWare ESXi(220.0.165.0-1OEM),
VMware Tools Async Release(12.0.0)
in the desired ESXi version are not supported."

Since these had already been uploaded to the VUM database (manually, I think), I could fairly easily find them when editing my image under 'Add Components' and change the version to match the existing ones in the error message.