v-consult.be

This guide brings an Intel Ethernet 700 Series adapter (X710, XL710, XXV710, X722-based LOMs) on an ESXi host to NVM 9.57 with 700Series_NVMUpdatePackage_v9_57_ESX.tar.gz, released by Intel on 26 May 2026. Expect about 15 minutes per host plus one reboot.

Driver or firmware?

The 9.57 package updates the firmware (the NVM image stored on the card), not the driver that ESXi loads. They are separate things with separate version numbers:

Layer	Lives in	ESXi name	Updated with
Firmware (NVM)	Flash on the NIC	Firmware Version, e.g. 9.57 0x8000xxxx 1.3xxx.0	Intel NVM Update Package (this guide)
Driver	ESXi host	i40en	VIB/component from Broadcom, Intel or the server vendor, or vLCM

The two must be a supported pair. Check the Broadcom Compatibility Guide (IO devices) for your ESXi version: it lists which i40en driver goes with which firmware. Update the driver first if the guide asks for a newer one, then the firmware.

Before you start

• Download 700Series_NVMUpdatePackage_v9_57_ESX.tar.gz (links in Where to download below). It already contains the ESXi update tool component (Intel-esx-nvmupdaten64e_*.zip).
• Check the card is a retail Intel adapter. OEM cards (Dell, HPE, Lenovo, Cisco) usually refuse the Intel package. Use the server vendor’s firmware tool (e.g. Dell DUP, HPE SPP) for those.
• Check the Broadcom Compatibility Guide for the matching i40en driver version.
• Enable SSH on the host (vSphere Client → host → Configure → Services → SSH → Start).
• Put the host in maintenance mode and evacuate VMs. The NIC ports reset during the flash and you lose network on that card.
• Have console access (iDRAC, iLO, IPMI) in case the management vmk sits on the NIC you update.
• Free space on a datastore. The unpacked package is about 75 MB; avoid /tmp, which is a small ramdisk.

Update one host at a time and check it before moving to the next.

Where to download

What	File	Where
NVM 9.57 package for ESXi (firmware images + update tool + ESXi component)	700Series_NVMUpdatePackage_v9_57_ESX.tar.gz	Intel download ID 18638 – 700 Series NVM Update Utility, VMware ESX
Same, all operating systems in one bundle	700Series_NVMUpdatePackage_v9_57.zip	Intel download ID 18190 – 700 Series NVM Update Utility
NVM update tool component for ESXi	Intel-esx-nvmupdaten64e_*.zip	Inside the ESX package above, in the ESXi_x64 folder. No separate download needed.
Intel esxcli plug-in (optional, adds esxcli intnet commands)	Intel-esx-intnetcli_<8.0 or 9.0>-*-package.zip	Intel download ID 19380 – Intel esxcli plug-in
i40en driver	Driver component for your ESXi release	Version from the Broadcom Compatibility Guide (Step 2); download from the Broadcom Support Portal or your server vendor
Downgrade, if needed	9.57 → 9.56 … 9.50 packages	Intel download ID 683939 – 700 Series NVM downgrade packages

Compare the SHA256 on the Intel page with sha256sum on your copy before you upload it.

Step 1 – Record the current versions

SSH to the host and list the NICs. The 700 Series ports use the i40en driver:

esxcli network nic list

On my lab host, vmnic1 and vmnic2 are the two X710 SFP+ ports (driver i40en); vmnic0 is the on-board I226-V on cndi_igc and is not touched by this update.

Show driver and firmware for every i40en port in one go:

for n in $(esxcli network nic list | awk '/i40en/{print $1}'); do
  echo "== $n"
  esxcli network nic get -n $n | grep -E 'Driver:|Version:'
done
esxcli software vib list | grep -i i40en

Example output:

In Firmware Version, 9.20 is the NVM version, 0x8000d8c5 the eTrack ID and 1.3602.0 the combo image (boot agent). The driver is i40en 2.6.0.46, the inbox VMware driver (2.6.0.46-1vmw.911.0.25714478). Write these down; you’ll compare them after the reboot.

Step 2 – Check the card in the Broadcom Compatibility Guide

The compatibility guide matches a card on four PCI IDs: Vendor ID (VID), Device ID (DID), Sub-Vendor ID (SVID) and Sub-Device ID (SSID). Read them per vmnic:

vmkchdev -l | grep vmnic

The columns are PCI address, VID:DID, SVID:SSID, owner and vmnic. On my lab host the X710 ports vmnic1 and vmnic2 show VID 8086, DID 1572 (X710 for 10GbE SFP+), SVID 8086, SSID 0000. vmnic0 (8086:125c) is the on-board I226-V.

An SSID of 0000 means no specific Intel board ID is programmed, which is common on generic or white-label X710 cards. Retail Intel boards report e.g. 0001 or 0007. In the compatibility guide, search on VID/DID/SVID and leave SSID empty or as a wildcard; the 8086 SVID still tells you the Intel NVM package applies.

For more detail (card name, NUMA node, all four IDs labelled):

esxcli hardware pci list | grep -B 4 -A 14 'Device Name: Ethernet Controller X710 for 10GbE SFP+'

Bus 0x05, Slot 0x00 and Function 0x0 / 0x1 are PCI address 0000:05:00.0 and 0000:05:00.1, so vmnic1 and vmnic2 in the vmkchdev output above. The four IDs match: 0x8086 / 0x1572 / 0x8086 / 0x0000.

Read the Sub-Vendor ID first – it tells you who built the card and therefore whose firmware to use:

SVID	Card from	Firmware source
8086	Intel (retail)	Intel NVM package – this guide
1028	Dell	Dell Update Package / Lifecycle Controller
1590 or 103c	HPE	HPE SPP / HPE firmware smart component
17aa	Lenovo	Lenovo XClarity / UpdateXpress
1137	Cisco	Cisco UCS HUU / firmware bundle
15d9	Supermicro	Mostly Intel package; check Supermicro first

Common 700 Series Device IDs: 1572 X710 SFP+, 1589 / 15ff X710-T 10GBASE-T, 1583 / 1584 XL710 QSFP+, 158b XXV710 25G, 37d0 / 37d2 X722 (on-board LOM).

Look it up:

1. Open the Broadcom Compatibility Guide and choose IO Devices.
2. Enter VID, DID, SVID and SSID in the ID fields, and select your Product Release Version (e.g. ESXi 8.0 U3 or ESXi 9.0).
3. Open the matching entry and check the driver / firmware table. Each line pairs an i40en driver version with a supported firmware version.
4. Confirm NVM 9.57 is listed with the i40en version you run (Step 1). If 9.57 is not listed yet for your release, the latest listed firmware is the supported one – decide whether to wait.

No entry for your exact SVID/SSID usually means an OEM card: use the vendor’s firmware and driver, not Intel’s.

Step 3 – Copy and extract the 9.57 package

Upload the package with the ESXi Host Client: browse to https://<esx-host>/ui, log in as root, go to Storage → datastore1 → Files and click Upload. Pick 700Series_NVMUpdatePackage_v9_57_ESX.tar.gz; when the upload finishes the file shows in the datastore root (about 75 MB).

Prefer the command line? scp 700Series_NVMUpdatePackage_v9_57_ESX.tar.gz root@<esx-host>:/vmfs/volumes/datastore1/ does the same.

On the host, check the hash against the Intel download page, extract and look inside:

cd /vmfs/volumes/datastore1
sha256sum 700Series_NVMUpdatePackage_v9_57_ESX.tar.gz
tar -xzf 700Series_NVMUpdatePackage_v9_57_ESX.tar.gz
find . -name 'nvmupdate*' -o -name '*.zip'

The prompt shows the datastore UUID instead of datastore1 – that’s normal, /vmfs/volumes/datastore1 is a symlink to it. Compare the sha256sum result with the SHA256 on the Intel download page.

The ESXi_x64 folder holds nvmupdaten64e, nvmupdate.cfg (which card gets which image), the NVM image files and the ESXi component Intel-esx-nvmupdaten64e_<version>.zip. If your file is a plain .tar, use tar -xf.

Step 4 – Install the update tool component

ESXi 8.0 and later only run binaries that are installed as a VIB, so the copy of nvmupdaten64e on the datastore won’t execute. Install the component from the package with the full path:

cd /vmfs/volumes/datastore1/700Series/ESXi_x64
ls Intel-esx-nvmupdaten64e_*.zip
esxcli software vib install -d /vmfs/volumes/datastore1/700Series/ESXi_x64/Intel-esx-nvmupdaten64e_1.43.36.0-800.20613240.zip

The result lists the installed VIB INT_bootbank_nvmupdaten64e_1.43.36.0-1OEM.800.1.0.20613240 and Reboot Required: true. Reboot the host now (it is already in maintenance mode) so /opt/nvmupdaten64e/bin/nvmupdaten64e becomes available, then SSH back in for Step 5.

Gotcha: a relative file name fails with MetadataDownloadErrorV2 ... No such file or directory: '/var/log/vmware/...zip'. esxcli resolves relative paths against its own working directory, /var/log/vmware, not your shell’s. Always pass an absolute path, or use -d $(pwd)/<file>.zip.

If you get an acceptance-level error, check and lower it:

esxcli software acceptance get
esxcli software acceptance set --level=PartnerSupported

Confirm the component and the tool are there:

esxcli software vib list | grep -i nvmupdate
ls -l /opt/nvmupdaten64e

The VIB nvmupdaten64e is listed (vendor INT, acceptance level VMwareAccepted, so no change to the host acceptance level was needed) and the tool lives in /opt/nvmupdaten64e/bin.

After the reboot, both commands should return a result. If /opt/nvmupdaten64e/bin/nvmupdaten64e is still missing, check the VIB list and reinstall the component.

Step 5 – Run the inventory, then the update

Go to the installed tool and point it with -a at the extracted ESXi_x64 folder, where nvmupdate.cfg and the NVM images live:

cd /opt/nvmupdaten64e/bin
./nvmupdaten64e -a /vmfs/volumes/datastore1/700Series/ESXi_x64

The tool runs an inventory, shows an interactive menu, flashes the adapter and then shows the inventory again. The full run on my lab host:

Reading the table:

Column	My lab host	Meaning
Num	01	Adapter index you select in the menu
Description	Intel Ethernet Converged Network Adapter X710	One line per adapter, not per port: both vmnic1 and vmnic2 are updated together
Ver.(hex)	9.32(9.20)	Current NVM; the value in brackets is the 9.20 that esxcli shows
DevId	1572	Same Device ID as in Step 2
S:B	00:005	PCI segment and bus, so bus 05 = 0000:05:00.x
Status	Update available	Other values: Up to date, Not supported (usually an OEM card)

At Enter selection type A (all adapters) or the adapter number (01, or a comma-separated list), then Enter.

When the tool asks whether to back up the current NVM images, answer Y. Keep that backup: it’s your way back to 9.20.

The backup files are written to the folder you start the tool from. Started from /opt/nvmupdaten64e/bin, they sit in the host’s RAM disk and are lost at the next reboot, so copy them to the datastore first: cp /opt/nvmupdaten64e/bin/*.bin /vmfs/volumes/datastore1/700Series/ESXi_x64/ (check with ls -lt which files are new).

Answer X instead to exit without changing anything – useful for a dry run on other hosts.

Unattended alternative – no prompts; logs, results and backup go to the package folder so they survive the reboot:

cd /vmfs/volumes/datastore1/700Series/ESXi_x64
/opt/nvmupdaten64e/bin/nvmupdaten64e -a /vmfs/volumes/datastore1/700Series/ESXi_x64 -u -b -l update.log -o update.xml

Option	Meaning
-a <folder>	Folder with nvmupdate.cfg and the NVM images
-i	Inventory only, no update
-u	Unattended: no prompts
-b	Back up the current NVM images first
-l <file>	Write a log
-o <file>	Write results as XML

The flash takes a few minutes per adapter. Do not interrupt it and do not power off the host. When it’s done, the second table shows the new version – here 9.87(9.57) with status Update successful – followed by A reboot is required to complete the update process and All operations completed successfully. Press any key to exit, then go to Step 6.

Step 6 – Reboot and verify

The new NVM only loads after a full reboot (some cards need a cold power cycle; if the version hasn’t changed after a warm reboot, power the server off and on via iDRAC/iLO).

reboot

After the host is back, rerun the check from Step 1:

for n in $(esxcli network nic list | awk '/i40en/{print $1}'); do
  echo "$n: $(esxcli network nic get -n $n | grep 'Firmware Version')"
done

Both ports now report 9.57 0x80010371 1.3602.0. Compared with Step 1:

Part	Before	After
NVM version	9.20	9.57
eTrack ID	0x8000d8c5	0x80010371
Combo image (boot agent)	1.3602.0	1.3602.0 – unchanged, this package only updates the NVM

Also confirm the links are up:

esxcli network nic list

vmnic1 and vmnic2 are back with Admin Status Up, Link Status Up at 10000 Mb/s full duplex – same as before the update. Then continue with the cleanup in Step 7.

In the vSphere Client the same information is under host → Configure → Networking → Physical adapters.

Step 7 – Clean up

Do this once the host runs 9.57 and its links are up. It removes everything the update added, so the host is back to a clean, compliant state.

1. Save the NVM backups and logs. They are your way back to the old firmware. From your workstation:

mkdir -p esx01-nvm-backup
scp -r root@esx01:/vmfs/volumes/datastore1/700Series/ESXi_x64/ esx01-nvm-backup/

The copy holds the backup images (created with -b or by answering Y), inventory.log, update.log and update.xml.

2. Remove the update tool component. Find its exact name, then remove it:

esxcli software component list | grep -i nvmupdate
esxcli software component remove -n Intel-esx-nvmupdaten64e

The component is Intel-esx-nvmupdaten64e (Intel NVM Update Tool, 1.43.36.0-800.20613240). The result shows it under Components Removed with Reboot Required: true, so reboot the host once more before the check in step 5.

3. Restore the acceptance level if you lowered it in Step 4:

esxcli software acceptance get
esxcli software acceptance set --level=VMwareAccepted   # or whatever it was before

4. Delete the package files from the datastore:

rm -rf /vmfs/volumes/datastore1/700Series
rm -f  /vmfs/volumes/datastore1/700Series_NVMUpdatePackage_v9_57_ESX.tar.gz

5. Check the host is clean:

esxcli software vib list | grep -i nvmupdate   # no output expected
ls /opt/nvmupdaten64e/bin 2>/dev/null                  # gone or empty

6. Put the host back in service. Exit maintenance mode (esxcli system maintenanceMode set --enable false or in the vSphere Client) and stop SSH if you only enabled it for this.

7. vLCM clusters: run Check compliance on the cluster. The host should be compliant again now that the manual VIB is gone.

Then move to the next host.

Optional – Driver update and vLCM

Update the i40en driver if the compatibility guide pairs NVM 9.57 with a newer driver. Download the driver component for your ESXi version and install it with an absolute path:

esxcli software component apply -d /vmfs/volumes/datastore1/<i40en-component>.zip
reboot

vLCM-managed clusters (vSphere 8, VCF 9): a VIB installed by hand puts the host out of compliance with the cluster image. Remove the helper afterwards, or add the driver component to the cluster image instead of installing it by hand. Firmware itself is not tracked by the image unless you use a vendor Hardware Support Manager, so that part stays manual.

Troubleshooting

Symptom	Cause and fix
MetadataDownloadErrorV2 ... /var/log/vmware/...zip: No such file	Relative path. Use the full /vmfs/volumes/... path with esxcli.
Acceptance level error on VIB install	esxcli software acceptance set --level=PartnerSupported
Adapter shows Not supported or isn’t listed	OEM-branded card or unsupported model. Use the server vendor’s firmware package.
Access error or tool can’t open the device	Helper component missing or not loaded. Check esxcli software vib list | grep nvmupdate; reinstall it.
Permission denied running the tool	Run /opt/nvmupdaten64e/bin/nvmupdaten64e; ESXi 8+ won’t execute the datastore copy
Firmware version unchanged after reboot	Do a cold power cycle (power off, wait 30 s, power on).
Links down after the update	Check the i40en driver against the compatibility guide for NVM 9.57 and update it.
Need to go back	Use Intel’s 700 Series NVM downgrade package (9.57 → 9.56 and earlier).

Sources

• NVM Update Utility for Intel Ethernet Network Adapter 700 Series, v9.57 (all OS)
• NVM Update Utility for Intel Ethernet Adapters 700 Series – VMware ESX
• NVM Downgrade Packages for Intel Ethernet Adapters 700 Series