bios v firmware level difference - x210M7 Blades and Intersight

[Big Vern]

intersight with ucsx-210c-M7 blades
Updated successfully all the firmware on the blades to the latest starred version 5.2(2.240053) via intersight
I assumed this would update the bios the servers as well.?
when I boot the servers via kvm it shows a  lower version 4.3.4a.0 on both the boot screen and when I exit into the bios itself.
I feel as though I'm missing something basic conceptually.
Tried a few reboots, no difference

[Boris Aelen · Accepted solution]

Hi Big Vern,

The 4.3.4a.0 BIOS version is the one that is packaged with the 5.2(2.240053) server firmware bundle.
You can see the content of the server firmware bundle here 

Hope that this confirms that you are not crazy  

[Big Vern]

Thanks so much Boris,
That explains, It , I naively assumed the bios version number would be harmonised with firmware package, thanks for the link!
Overnight we have moved to 5.3(0.240016) firmware as there was an advisory on that fimrware above.

slightly related but can post another question if required.

As I assumed before so I thought i would ask for clarification;
VMware-ESXi-8.0.U3-24022510-Custom-Cisco-4.3.4-a.iso - I need to install ESXi on the blades, this seems to be the latest ciso oem image.
for esxi 8 available for download

4.3.4-a what is that number - is that related to the bios or the firmware, and in high level terms what do I need to get it up to match the firmware installed on the blades 5.3(0.240016) - should that be my aim? - I m guessing once installed I can use VMware life cycle manager (we only have intersigh essentials licence) and look for a cisco package

[Riaan van Niekerk · Accepted solution]

On the Cisco custom image and Cisco Vendor Add-on package (which is distributed by vSphere Lifecycle Manager and contains only the Cisco components that are newer than or in addition to what ships with the non-customised Cisco image), the 4.3.4-a does not denote compatibility with firmware 4.3(4a), but that it is the first of the 4.3(4) compatible ISOs / add-ons. Cisco UCS HCL certification apply to the patch level (e.g. the 3rd number) and do not care about the bugfix release (the letter behind the 3rd number). This release of the custom ISO / vendor add-on may be replaced by 4.3.4-b in the future if Cisco update the certifications and decide to release updated customised ISOs and vendor add-ons. 

Please check the Cisco UCS HCL for actual certified versions of enic & fnic, because the customised ISO or vendor add-on may lag behind the HCL. Practical example: 

We deployed ESXi 7.0 U3 on Cisco X210C M7 blades with firmware 4.3(4e). The latest ESXi 7.0 vendor add-on in vLCM ships with

• enic 2.0.10.0 - this version is still fine on 4.3(4)
• fnic 5.0.0.42 - this version does not match the HCL for 4.3(4). 5.0.0.44 is the recommended latest tested driver on 7.0 & 8.0.

We ended up having to

• download the 5.0.0.44 fnic driver from the Broadcom support website and
• add this fnic driver as a vLCM component (Where you can add individual drivers), which replaces the 5.0.0.42 that is part of the vendor add-on.

Edit: I just checked the contents of vendor add-on 4.3.4-a, and out of the box it ships with the versions that are compatible with firmware 4.3(4) (e.g. no need to "side-load" a newer fnic driver):

• enic 2.0.11.0
• fnic 5.0.0.44

[Big Vern]

Thank you for the comprehensive reply; it has helped me understand . We encountered a similar issue when we noticed on Intersight HCL that the fnic driver was incompatible. To address this, we downloaded the correct version of the driver and installed it on one of the ESXi servers using the following command:

bash
Copy code
esxcli software vib install -d /vmfs/volumes/673f6461-871c32b3-d058-0025b501a000/Cisco-nfnic_5.0.0.45-1OEM.800.1.0.20613240_24275629.zip
However, I was unsure how to efficiently deploy this updated driver across all ESXi servers in the cluster. Your explanation about adding the fnic driver as a vLCM component has provided the key I think I need to read up on

Before reading your detailed instructions, we had resorted to a less streamlined process:

We created a temporary "dummy" cluster in VMware.
We moved the ESXi server with the updated driver into this cluster.
Next, we added the remaining ESXi servers to the cluster and remediated them, ensuring all hosts received the updated driver.
While this method worked, it involved unnecessary complexity and server reboots, which could have been avoided by properly utilizing vSphere Lifecycle Manager (vLCM).

Moving forward, I plan to follow your guidance and add the required fnic driver as a component in vLCM. 

Thank you again for your detailed and clear response.

Im now stuck with a bios query but will post another question for that.

[Boris Aelen]

Hi,

The recommended way for deploy the updated drivers across all ESXi servers in the cluster is by "Setting Up an Image for a Cluster or a Host"

https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-lifecycle-manager/GUID-CBCAC2B6-7C30-4103-89C5-C53FEEA59D0A.html#setting-up-an-image-for-a-cluster-or-a-host-0

If you enable our HSM feature in Intersight you can even select the right FW version from Intersight to match the ESXi version and the Vendor Addons that have the enic and fnic driver. 

Hope that this helps