Passing a USB peripheral to a VM is normally straightforward. Passing an entire PCI USB controller is different: the ESXi host gives up control of every port, hub, and device behind that controller. If the ESXi boot device is in that topology, one incorrect passthrough selection can make the host lose access to its boot banks and prevent the setting from being saved or reversed cleanly.
This is a common risk on servers such as the HPE ProLiant DL380 Gen9, where ESXi may boot from an internal USB flash drive while several Intel USB controllers and an iLO USB function appear in PCI inventory. The safe decision cannot be made from lsusb and lspci output order alone.
Device Passthrough and Controller Passthrough Are Not Equivalent
ESXi offers two relevant mechanisms:
- Host USB device passthrough attaches one physical USB device to a VM while ESXi continues to own the USB controller.
- PCI controller passthrough assigns the whole USB controller to a VM through DirectPath I/O, making all devices behind that controller unavailable to the host.
Broadcom’s host USB device procedure supports adding an individual host USB device through the VM’s Add New Device > Host USB Device control. Only one VM can own that physical device at a time. This is the preferred method when the host itself depends on another USB device.
Broadcom explicitly states in KB 341580 that USB-controller passthrough is unsupported when ESXi boots from a USB or SD device connected through that USB channel. Enabling controller passthrough makes all USB devices invisible to the kernel. If the configuration is later deselected, ESXi may be unable to save the reversal back to the now-invisible boot device.
Why a Hub Does Not Protect the Boot Device
Consider this simplified inventory from an ESXi 7 host:
Bus 001 Device 001: VMware Root Hub
Bus 001 Device 002: Microchip USB Hub
Bus 001 Device 003: Kingston 64 GB flash drive
0000:00:14.0 Intel xHCI Host Controller
0000:00:1a.0 Intel EHCI Controller #2
0000:00:1d.0 Intel EHCI Controller #1
0000:01:00.4 HPE iLO4 USB controller
The Kingston device is behind a Microchip hub, but the hub is not an isolation boundary for PCI passthrough. If the upstream controller is assigned to a VM, the host loses the hub and everything below it.
The opposite mistake is also possible: declaring 00:14.0 to be the boot controller merely because the Kingston device appears on Bus 001 and the xHCI controller appears first in lspci. Bus numbering and command-output order do not establish a PCI parent-child relationship. Firmware, driver enumeration, and ESXi’s USB stack can assign numbers in ways that are not apparent from two flat lists.
The evidence proves that a USB boot device exists. It does not, by itself, prove which PCI function owns it or that the other controllers are empty.
Prove the Topology Before Changing Passthrough
Do not mark any controller for passthrough until its complete downstream topology is known. Use several forms of evidence:
- Record the host’s boot device in vSphere under Host > Configure > Storage Devices, including its identifier and partition details.
- Capture the USB device inventory and topology, not only a flat device list. On platforms that provide it, a tree view shows which root hub and downstream hub contain each device.
- Inspect the detailed PCI entries with ESXi hardware commands and record the device, driver, vendor, and passthrough state.
- Insert a noncritical test USB device into one physical port at a time and observe where it appears. Remove it between tests so the mapping is unambiguous.
- Compare the result with the server maintenance guide and system-board diagram for the exact model and riser configuration.
- Treat the iLO USB function as management infrastructure unless HPE documentation for the exact use case says otherwise.
A live insert-and-remove test maps external ports, but it still does not justify touching the controller that contains the boot device. If the topology remains ambiguous, stop and use per-device passthrough.
The Safest Configuration: Pass One USB Device
For a removable disk, UPS interface, license dongle, serial adapter, or other peripheral, attach the specific device instead of the controller:
- Confirm that the device is visible to ESXi and not used by the host.
- Power off the VM if its virtual hardware or guest requirements demand it.
- Open Edit Settings for the VM.
- Select Add New Device > Host USB Device.
- Choose the exact device by identity, not a similarly named entry.
- Leave Support vMotion disabled unless migration with the device is required and the documented conditions are met.
- Start the VM and confirm the guest sees the device.
- Reboot the guest and then test a planned ESXi maintenance reboot only after the host configuration and recovery path are protected.
Per-device passthrough preserves ESXi ownership of the controller and the boot flash drive. It also avoids exposing every external port on that controller to a single VM.
Some applications require direct ownership of an entire controller, particularly for device-reset behavior or unsupported USB classes. That requirement should trigger a boot-architecture change, not a gamble with the existing boot controller.
If a Whole Controller Is Truly Required
Move ESXi away from USB dependency before assigning a controller that might contain the boot device. Broadcom’s current SD card and USB boot guidance continues to support USB and SD boot in specified releases but recommends persistent storage for ESX-OSData and planning a move to higher-endurance media. USB and SD are not the preferred long-term boot choice.
A controlled design is:
- install or migrate ESXi to supported persistent SATA, SAS, NVMe, SATADOM, or other vendor-supported media;
- place ESX-OSData, scratch, and logs on reliable persistent storage according to the ESXi release’s guidance;
- back up the host configuration and document networking, storage, licensing, and passthrough state;
- verify an alternate console through iLO and keep installation media available;
- test that the host boots twice from the new device before enabling any controller for passthrough;
- map the target controller with a disposable peripheral before assigning it to a production VM.
For ESXi 7.0 U3 systems using USB without secondary persistent storage, Broadcom documents warnings that the host can lose data or fail to boot. Its persistent-storage warning article recommends installing on non-USB media or providing persistent storage and a reliable scratch location.
Why “It Still Runs” Is Not a Successful Test
ESXi loads substantial components into memory. A host may continue running after losing access to the USB boot device, which can create false confidence. The failure can appear later when ESXi tries to save configuration, update boot banks, access the locker, or reboot.
Validate more than VM availability:
- both boot banks remain accessible;
- the expected boot device is still visible to the host;
- scratch and ESX-OSData locations are persistent and healthy;
- a configuration change survives a controlled reboot;
- patch staging and remediation complete normally;
- the passed-through peripheral remains assigned after reboot;
- iLO and other out-of-band management functions are unaffected.
Do not use an unplanned production reboot as the first proof. Have a maintenance window, a console session, compatible ESXi installation media, a host-configuration backup, and a documented path to reconnect datastores and networking.
Recovering From an Incorrect Controller Assignment
If controller passthrough has already hidden the USB boot path, avoid repeated uncontrolled reboots. Record the current host configuration while the host is still reachable and evacuate or shut down workloads according to the recovery plan.
Broadcom’s KB explains that the setting may not revert because the modified esx.conf cannot be written back to the invisible USB device. Its documented workaround is to re-image the boot medium, with the warning that host configuration is lost. On hardware with genuinely separate USB controllers, another option is to move the boot device to a port on a different controller and never pass that controller through—but the separation must be proven, not assumed.
Restoring a configuration backup to a compatible ESXi build can reduce reconstruction work, but backup and restore procedures are version-sensitive. Verify the current Broadcom procedure before the incident rather than discovering it during recovery.
The Decision Rule
When ESXi boots from USB, use host USB device passthrough unless there is a documented technical requirement for controller ownership. If a whole controller is required, first migrate the host to reliable persistent boot storage and prove the USB topology.
Flat lsusb and lspci lists are inventory, not topology. The safe controller is the one demonstrated not to contain the boot device or a management function—and uncertainty is a reason to stop, not a reason to test on a production host.
