WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

ESXi 7.0 Update 2 enhancement for USB NIC only installations

03.16.2021 by William Lam // 16 Comments

The USB Network Native Driver for ESXi Fling has been an extremely popular Fling that has allowed customers to easily add additional networking capabilities by using a supported USB-based network adapter even though ESXi traffic over USB networking is not officially supported.

In most deployments, the USB network adapter is usually a supplement to the existing onboard network adapter of a system. However, there have been scenarios where the onboard network adapter is either not available or functional and customers would still like to be able to install ESXi and have it running over just the USB network adapter.

Although installing ESXi using just a USB network adapter is possible today, one downside is that an additional workflow is needed to fix the network binding after installing ESXi.

During the interactive ESXi installation, you will see the following error at 81% which will cause installer to get stuck

Exception: No vmknic tagged for management was found.

At this point, the installer has completed and you need to switch to the console (Alt+F1) and just perform a reboot to actually complete the installation.


After ESXi boots up for the first time after the install, you will need to go into the DCUI and manually bind the vusb0 interface for ESXi management for connectivity. To persist this USB NIC binding, you will need to add small snippet to /etc/rc.local.d/local.sh

Standard Virtual Switch (VSS):

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')
count=0
while [[ $count -lt 20 && "${vusb0_status}" != "Up" ]]
do
    sleep 10
    count=$(( $count + 1 ))
    vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')
done

esxcfg-vswitch -R

Distributed Virtual Switch (VDS):

VDS_0_NAME=vDS
VDS_0_PORT_ID=10
VDS_1_NAME=vDS-NSX
VDS_1_PORT_ID=2

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print "v0:" $NF}') && vusb1_status=$(esxcli network nic get -n vusb1 | grep 'Link Status' | awk '{print "v1:" $NF}')
count=0
while [[ $count -lt 40 ]] && [[ "${vusb0_status}" != "v0:Up" || "${vusb1_status}" != "v1:Up" ]]
do
    sleep 5
    count=$(( $count + 1 ))
    vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print "v0:" $NF}') && vusb1_status=$(esxcli network nic get -n vusb1 | grep 'Link Status' | awk '{print "v1:" $NF}')
done

if [ "${vusb0_status}" = "v0:Up" ]; then
    esxcfg-vswitch -P vusb0 -V ${VDS_0_PORT_ID} ${VDS_0_NAME}
fi

if [ "${vusb1_status}" = "v1:Up" ]; then
    esxcfg-vswitch -P vusb1 -V ${VDS_1_PORT_ID} ${VDS_1_NAME}
fi

Note: The vusbX vmkernel interface may not show up in either ESXi Embedded Host Client and/or vSphere HTML5 UI, this does not mean there is an issue. ESXi was never designed to support USB-based NICs for Management Network and the UI may not properly detect these devices when using the UI. It is recommended to use the ESXi Shell for any operations requiring configuration of vusbX devices.

Obviously, this was not an ideal user experience and I personally had to use this workaround on several occasions, especially for newer hardware platforms where the onboard network adapter may not be recognized by ESXi and being able to use the USB Network Fling definitely came in handy.

With the release of ESXi 7.0 Update 2, we have improved the user experience for installing ESXi with just a single USB NIC. This enhancement was added by Songtao after mentioning the undesirable behavior. A new driver parameter called usbBusFullScanOnBootEnabled has been introduced and can added after the initial installation which removes the need for the workaround mentioned above by editing the local.sh file. This new parameter instructs ESXi to perform a full bus scan to claim all USB NICs that are attached since USB device claiming is slow compared to PCIe devices.

[Read more...]

Categories // ESXi, Home Lab, vSphere 7.0 Tags // ESXi 7.0 Update 2, vSphere 7.0 Update 2

Aquantia/Marvell AQtion (Atlantic) driver now inbox in ESXi 7.0 Update 2

03.11.2021 by William Lam // 25 Comments

Last spring, VMware and Aquantia (now part of Marvell) collaborated and delivered their first ESXi Native Driver for their AQtion (Atlantic) based 10GbE network adapters. This new driver was primarily focused on enabling network connectivity for ESXi when running on either an Apple 2018 Mac Mini (8,1) and Apple 2019 Mac Pro (7,1) that included the 10GbE networking option. Consequently, this driver also benefited the broader VMware Community as it enabled additional 10GbE networking through a number of Thunderbolt 3 to 10GbE network adapters that customers could now take advantage in their VMware environments.

With all these benefits, VMware has decided to inbox the Aquantia/Marvell driver with the latest ESXi 7.0 Update 2 release, so that customers no longer had to create a custom ESXi Image Profile that included the driver, which was always required when installing ESXi on either the Apple Mac Mini or Mac Pro that were configured with the 10GbE networking option. For a complete list of supported Aquantia/Marvell AQtion based network adapters, please see the VMware HCL.

Here is a screenshot of an earlier release of ESXi 7.0 Update 2 running on the 2018 Mac Mini which now automatically recognizes the 10GbE network adapter out of the box.

Categories // Apple, ESXi, vSphere 7.0 Tags // apple, Aquantia, ESXi, ESXi 7.0 Update 2, mac mini, mac pro, Marvell, vSphere 7.0 Update 2

ESXi 7.0 Update 2 Upgrade Issue – Failed to load crypto64.efi

03.10.2021 by William Lam // 34 Comments

I started to notice yesterday that a few folks in the community were running into the following error after upgrading their ESXi hosts to latest 7.0 Update 2 release:

Failed to load crypto64.efi

Fatal error: 15 (Not Found)

Upgrading my #VMware #homelab to #vSphere7Update2 is not going so well. 🙁 #vExpert pic.twitter.com/pGOlCGJIOF

— Tim Carman (@tpcarman) March 10, 2021

UPDATE (04/29/2021) - VMware has just released ESXi 7.0 Update 2a which resolves this issue and includes other fixes. Please make sure to read over the release notes and do not forget to first upgrade your vCenter Server to the latest 7.0 Update 2a release which came out earlier this week.

UPDATE (03/13/2021) - It looks like VMware has just pulled the ESXi online/offline depot and has updated KB 83063  to NOT recommend customers upgrade to ESXi 7.0 Update 2. A new patch is actively being developed and customers should hold off upgrading until that is made available.

UPDATE (03/10/2021) - VMware has just published KB 83063 which includes official guidance relating to the issue mentioned in this blog post.

Issue

It was not immediately clear to me on how folks were reaching this state and I had reached out to a few folks in the community to better understand their workflow. It turns out that the upgrade was being initiated from vCenter Server using vSphere Update Manager (VUM) and applying a custom ESXi 7.x Patch baseline to remediate. Upon reboot, the ESXi host would then hit the error as shown above.


Interestingly, I personally have only used Patch baselines for creating ESXi patches (e.g. 6.7p03, 7.0p01) and never for major ESXi upgrades. I normally would import the ESXi ISO and create an Upgrade baseline. At least from the couple of folks I spoke with, it seems like the use of Patch baseline is something they have done for some time and has never given them issues whether it was for a patch or major upgrade release.

Workaround

I also had some folks internally reach out to me regarding this issue and provided a workaround. At the time, I did not have a good grasp of what was going on. It turns out the community also figured out the same workaround, including how to recover an ESXi host which hits this error as you can not just go through recover workflow.

For those hitting the error above, you just need to create a bootable USB key with ESXi 7.0 Update 2 ISO using Rufus or Unetbootin. Boot the ESXi 7.0 Update 2 Installer and select the upgrade option which will fix the host.

To prevent this from happening, instead of creating or using a Patch baseline, create an Upgrade baseline using ESXi 7.0 Update 2 ISO. You will first need to go to Lifecycle Manager Management Interface in vCenter Server and under "Imported ISOs", import your iage.


Then create ESXi Upgrade baseline and select the desired ESXi ISO image and use this baseline for your upgrade.


I am not 100% sure, but I believe the reason for this change in behavior is mentioned in the ESXi 7.0 Update 2 release notes under "Patches contained in this Release" section which someone pointed me to. In any case, for major upgrades, I would certainly recommend using Upgrade baseline as that is something I have always used even when I was a customer back in the day.

Categories // ESXi, vSphere 7.0 Tags // vSphere 7.0 Update 2

  • « Previous Page
  • 1
  • …
  • 55
  • 56
  • 57
  • 58
  • 59
  • …
  • 153
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VCF 9.1 - Enabling High Availability for a Small VCF Management Services (VCFMS) Deployment 06/22/2026
  • Clarifying Minimum Required ESX Hosts for VCF Deployments 06/18/2026
  • VCF 9.1 - Auditing VCF Management Services (VCFMS) IP Pool Usage  06/17/2026
  • VCF 9.1 - Auditing vCenter Server Connections using the Connection Utilization API 06/15/2026
  • Quick Tip: Resolving OVFTool "Failed to Send File" Errors on macOS 06/13/2026
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.

To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2026

Loading Comments...