Home

【ESXi】记一次 ESXi 8.0 挂载 USB 3.1 设备导致宿主机卡死、配置丢失的排查全过程

1162字 预计阅读时间：5.8分钟 VMware

最近在 ESXi 8.0.2 环境下折腾一台 Windows 虚拟机（模板机）时，遇到了一个极其诡异且折磨人的大坑。为了挂载一个 USB 3.1 的 U 盘，差点把整个宿主机的管理服务给干崩了。在这里复盘并记录一下排查过程，希望能帮到遇到类似灵异事件的朋友。

🎯 诡异的故障现象

起初只是想给虚拟机直通一个慧荣主控的 U 盘，结果引发了一连串的“灵异”连锁反应：

  1. 面板假死：在编辑虚拟机添加 USB 设备时，ESXi 的 Web 界面极其缓慢。
  2. 全局卡顿：不仅当前虚拟机卡，甚至连去其他数据存储里“注册虚拟机”这种秒级的轻量级操作，都卡死无响应。
  3. 配置“灵异消失”：在 Web 界面里添加“主机 USB 设备”，系统明明弹窗提示“保存成功”，但只要按 F5 刷新页面，刚才加上的 U 盘就不翼而飞了，仿佛无事发生。

🕵️‍♂️ 抽丝剥茧：排查过程

遇到这种配置没保存上的情况，第一反应是 Web UI 出了 Bug 或者文件权限有问题。于是我直接 SSH 进后台开始挖底层逻辑。

第一步：查 .vmx 配置文件（揭穿 UI 的谎言）

我直接去虚拟机的存储目录下查看 windows-模板机.vmx 文件，发现里面赫然写着：

usb_xhci.present = "TRUE"
usb_xhci.autoConnect.device0 = "path:0/1/22/0 autoclean:1 virtPath:usb_xhci.autoConnect.device0 version:4"

结论： UI 并没有骗人，配置指令确确实实下发并写入了。之所以刷新后看不到，是因为底层在尝试物理握手时“翻车”了，为了保护宿主机，ESXi 又在后台悄悄把它给踢掉了。

第二步：查 vmware.log 日志（寻找物理握手翻车的铁证）

既然是底层硬件握手失败，那就得看虚拟机开机/热插拔时的运行日志。使用 grep 过滤出 USB 相关的关键信息，终于在几百行看似正常的废话中，逮到了下面这 4 行致命报错：

2026-03-31T02:04:31.511Z In(05) vmx esxui-cc49-3a87 USB: DevID(10000003090c1000): Connecting device desc:name:Silicon\ Motion\ Flash\ Drive ... ownerdisplay:windows-xxx version:5.
2026-03-31T02:04:31.511Z No(04) vmx - USBGA: DevID(10000003090c1000): Failed to connect device, failedStatus(20).
2026-03-31T02:04:31.511Z In(05) vmx - [msg.usb.connectFailedErr] The connection for the USB device 'Silicon Motion Flash Drive' was unsuccessful. The device is already connected to another virtual machine.
2026-03-31T02:04:31.512Z In(05) vmx - USB: DevID(10000003090c1000): Disconnecting device.

第三步：案情真相大白

看到日志，瞬间破案了：

  1. 被独占锁定：日志清晰写明，这个 U 盘的 ownerdisplay（所有者）是另一台名为 windows-黄中超 的虚拟机。ESXi 的 USB 单设备直通是极其严格的物理独占模式。
  2. 引发中断风暴：当我在这边点保存时，底层的 VMX 进程试图去抢夺设备控制权，遭遇了状态码 20（设备忙/冲突）的错误。这种底层的高速 I/O 争抢和死锁，直接耗尽了 hostd 管理服务的线程，导致了整个 ESXi 宿主机的卡顿和假死。
  3. 秒踢保命：争夺失败后，进程在 1 毫秒内执行了 Disconnecting device（强行断开）。所以 Web 界面一刷新就什么都看不到了。

破局之道：暴力拆锁与终极避坑

既然知道是被别的虚拟机锁死了，解决思路就很清晰了：释放锁。但如果那台占用的虚拟机已经损坏、无法从 Web 界面编辑怎么办？必须进行底层的“暴力拆锁”。

1. 揪出僵尸进程并击杀

不要指望 esxcli vm process kill --type=force 这种文明手段，陷入深度 I/O 等待（D状态）的进程根本不吃这一套。直接从底层系统动手：


ps -c | grep -v grep | grep -i "windows-xxx"

# 找到主 VMX 进程的 PID（通常是第一列数字），直接 -9 赐死
kill -9 <主进程PID>

提示：如果此时提示 No such process，说明系统其实已经通过超时机制把它回收了，这反而是个好消息。

⚠️** 注意：如果连 kill -9 都杀不掉，说明主板 USB 总线彻底 I/O 死锁了。唯二的解法：要么去机房物理拔掉这个 U 盘打破中断，要么找个维护窗口重启整台 ESXi 物理机。**

2. 清理配置文件（扫雷）

锁解开后，千万别急着开机。那台废弃虚拟机的 .vmx 文件里还留着自动挂载这个 U 盘的代码，一通电又会触发死锁。

vi /vmfs/volumes/你的数据存储/windows-黄中超/windows-黄中超.vmx

找到带有 path:0/1/22/0 或 usb_xhci.autoConnect 的行，按 dd 删除，然后 :wq 保存。

VMware 存储