An external USB SSD can sometimes be claimed by ESXi 7 and formatted as VMFS, but it is not a plug-and-play equivalent to a supported shared datastore or backup target. By default, the USB Arbitrator reserves eligible USB devices for passthrough to virtual machines, so a storage rescan may show nothing.
There are three distinct designs:
- stop USB arbitration globally so VMkernel can claim USB storage;
- exclude one USB device from passthrough so VMkernel can claim that device;
- avoid USB and use a supported hot-plug SAS/SATA/NVMe storage path.
The third is the best production design. The first two are useful for labs, emergency transfer, or controlled shuttle workflows when their support and durability limits are accepted.
Why the Drive Does Not Appear After a Rescan
Partitioning is not the first issue. A blank drive, an NTFS-formatted drive, and a previously used disk can all remain absent from Storage Devices if USB Arbitrator owns them.
Check host detection and passthrough state:
lsusb
esxcli hardware usb passthrough device list
Record the device’s bus, device, vendor ID, and product ID. Do not run a format or partition command until the physical device is unambiguously identified; choosing the wrong disk can destroy an ESXi boot device or datastore.
Broadcom explains that a USB device can be used by USB Arbitrator for VM passthrough or by VMkernel locally, but not both. Its generic local-USB procedure stops usbarbitrator, connects the storage device, and rescans.
That global method also removes passthrough access for every VM on the host. It is therefore unsuitable when production VMs depend on USB license dongles or other host USB devices.
Per-Device Exclusion
VMware engineer William Lam documented a narrower method after checking with the USB engineering team. First list devices, then disable passthrough for the selected device:
esxcli hardware usb passthrough device list
esxcli hardware usb passthrough device disable \
-d BUS:DEVICE:VENDOR_ID:PRODUCT_ID
The change requires an ESXi reboot before VMkernel can claim the device. This means the initial conversion is not a zero-reboot operation. The bus and device values can change when the hardware is moved or re-enumerated.
For device-model matching, the documented alternative uses the USB quirks setting:
esxcli system settings advanced set -o /USB/quirks \
-s 0xVID:0xPID:0:0xffff:UQ_MSC_NO_UNCLAIM
Replace VID and PID with the exact hexadecimal identifiers and reboot. The full procedure and its caveat that local USB storage is not officially supported are in William Lam’s engineering note.
This quirk is matched by vendor and product IDs, not a physical port. That can be convenient for a shuttle drive, but it can also match another unit of the same USB bridge model. Document the enclosure as well as the SSD inside it, because ESXi sees the USB-to-SATA/NVMe bridge identifiers.
Do not overwrite an existing /USB/quirks string when other quirks are already configured. Preserve and correctly concatenate the existing entries or use vendor support.
Creating and Using VMFS
After reboot, verify that the intended device appears as local storage and recheck its size and identifier. Create VMFS through the vSphere Client only after confirming no required data remains on the disk.
Use a portable datastore for cold data movement:
- power off the VM;
- ensure no snapshot, backup, replication, or open task is using it;
- copy the complete VM directory and verify completion;
- at the destination, rescan and mount the existing VMFS volume;
- register the
.vmxfrom the datastore browser; - verify networks, disks, firmware, and hardware dependencies before power-on.
Do not run the same VM from both locations. If prompted whether the VM was moved or copied, the answer affects identifiers; choose according to the migration plan, not by habit.
Safe Removal Is Mandatory
Never pull the SSD while VMFS is mounted. Before removal:
- power off or migrate every VM using it;
- unregister temporary VM inventory entries if appropriate;
- stop all copies and confirm no active tasks;
- unmount the datastore from every host that can see it;
- detach the storage device when the client offers that action;
- verify the device is no longer in use;
- only then disconnect power or USB.
An external enclosure, cable, or connector can reset under sustained writes. VMFS journal protection does not turn unreliable consumer USB transport into enterprise storage.
It Is Not a Backup by Itself
A cloned VM directory on one portable SSD is a copy, not a complete backup strategy. It lacks application-consistency guarantees, retention, immutability, automated verification, and independent recovery history. Malware, operator error, enclosure failure, or an interrupted copy can affect the only copy.
Use supported backup software and a tested restore process for protection. A shuttle datastore can carry an additional offline copy, but it should not replace primary backups.
Better Options for a DL380-Class Server
On a server with hot-plug drive bays and a supported Smart Array or HBA, a single-disk logical volume or approved HBA-presented disk provides a more predictable storage path than USB. Confirm controller mode, cache policy, drive roaming, and cross-server compatibility before treating a RAID-controller disk as portable.
Network transfer, NFS, supported direct-attached storage, or backup repositories are usually easier to audit and automate. For large offline transfers between two fixed sites, a dedicated hot-plug disk workflow can be reasonable, but it must include controller compatibility and a formal unmount/export procedure.
The per-device USB exclusion is real and more precise than stopping USB Arbitrator globally. It still requires planned host configuration and reboot, and it does not make USB VMFS a supported production datastore. Use it as a controlled transport mechanism, not as invisible infrastructure.