SeigRoboticsESXi 8.0.3U5 上配置显卡直通，本来想的是插上卡、勾上直通、开机装驱动，结果 VM 列表里虚拟机显示“已启动”，下面却挂着一行“需要重新引导”，点进控制台也看不到系统正常起来。这个状态我遇过不少次，网上问的人也多，但大部分回答要么让你反复重启虚拟机，要么直接让你重装系统，完全没讲到点子上。这篇文章就围绕这个状态，把显卡直通后出现“已启动/需要重新引导”的成因、排查顺序和处理方法完整拆一遍。刚接触 ESXi 直通的朋友可以按顺序看，已经被卡住的朋友可以直接跳到第 3 节和第 4 节先解决问题。
1. 先搞懂“已启动/需要重新引导”这行状态到底在说什么
1.1 电源状态和配置状态是两套信息，别混在一起看
ESXi 的 Web Client 里，虚拟机列表展示的“已启动”是电源状态（Power State），而旁边那个“需要重新引导”是配置状态（Configuration State）。这两个字段代表的信息完全不同：电源状态说明 VMX 进程已经被拉起，虚拟机“在运行”；配置状态说明 VMX 在启动过程中发现某个硬件配置没有生效，必须在一次新的引导流程里重新尝试初始化。
具体到显卡直通场景，这个“没有生效”的配置就是 PCIe 直通设备本身。直通设备要被虚拟机使用，中间要完成好几步：设备重置、BAR 空间映射、IOMMU DMA 重映射、中断分配。只要其中任何一步失败，VMX 不会让虚拟机直接挂掉，而是把设备状态标记成“等待重新初始化”，然后抛出一个“需要重新引导”的信号。所以你在界面上看到的就是：VM 开着，但里面根本没有正常亮屏，显卡设备实际上没有接管成功。
很多朋友遇到这个状态第一反应是“强制重启虚拟机”，结果发现重启完了还是老样子，原因就在这里——重启只是重新触发了一次初始化，如果最根本的条件不满足，重启多少次结果都一样。
1.2 最容易踩出这个状态的三种操作
第一种：在虚拟机开机状态下给 VM 添加 PCIe 直通设备。这个基本属于必踩雷。VMX 设计上就不支持热插拔一个完整的多功能显卡，添加设备后系统会提示“需要重新引导”，如果你这时候点了重启，设备往往会残留在一个半初始化状态，下次启动时还是起不来。
第二种：主机冷启动之后直接开机。ESXi 主机断电重启后，某些直通设备（尤其是独显）在硬件层面还没有被完全重置，上一轮的 DMA 映射状态还残留在设备里。VM 启动时 VMX 尝试接管设备却发现设备状态不干净，于是初始化失败，进入了“需要重新引导”的状态。
第三种：显卡 Option ROM 加载失败。这个多见于虚拟机固件还是传统 BIOS 的情况。现代显卡基本上只有 UEFI GOP 驱动，传统模式下找不到合法的 Option ROM，VMX 在准备阶段就读不到显卡的固件信息，自然没办法继续初始化设备。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手之前先过一遍：硬件与BIOS前置检查清单
2.1 VT-d、Above 4G Decoding 这些开关缺一不可
排查这类问题，我习惯先从硬件层开始，而不是一头扎进虚拟机配置里。因为显卡直通依赖的底层能力都在主板 BIOS 里，任何一个关键开关没开，后面所有操作都白费。
最重要的两个开关：一个是 CPU 的虚拟化重映射技术，Intel 叫 VT-d，AMD 叫 IOMMU。这个不开，直通设备根本无法进行 DMA 重映射，ESXi 直接不会让你启用直通。另一个是 PCIe 设备的大地址空间支持，BIOS 里通常叫 Above 4G Decoding，有些主板叫“PCIe 64-bit BAR Support”或者“Memory Hole for PCI MMIO”。这个名字里的“4G”指的是 32 位地址空间上限。现代显卡显存动不动就 8GB、16GB，显卡 BAR 动辄需要几个 GB 的地址空间，不开 Above 4G Decoding，BIOS 就没办法把显卡的 BAR 映射到 64 位地址区域，ESXi 拿到的设备地址空间会非常局促。
还有几个建议顺手处理：SR-IOV 如果没用到就关掉，它能减少 BIOS 对 PCIe 资源重排的干扰；ACS（Access Control Services）在部分主板的 PCIe 插槽分组里有独立设置项，如果显卡插在由 PCIe Switch 扩展出来的插槽上，ACS 相关选项的状态会直接影响直通能否成功。至于具体是开还是关，取决于主板实现，可以先按默认，遇到问题再去 BIOS 里切换测试。
2.2 显卡型号与ESXi 8.0.3U5的直通兼容性
ESXi 8.0 Update 5 官方兼容性清单（HCL）对显卡直通是有明确要求的，但个人玩家手里很多硬件根本不在 HCL 列表里。不在列表不意味着不能直通，只是意味着你要有心理准备，排查成本会高一些。
我自己在 8.0.3U5 上测过几类卡：NVIDIA 的 GTX 10 系、RTX 20/30 系，直通逻辑都还算正常，装完驱动后跑得也挺稳；AMD 的 RX 5000/6000 系开始也能通，但有个别型号需要额外加大 MMIO 预留，不然就会出现本文说的这个状态。Intel 核显的情况比较特殊，直通给 Windows 后驱动兼容性比较看运气，我自己不太推荐用核显做直通。
另外有一点要注意：直通给虚拟机的显卡，输出画面主要靠远程桌面、串流这类软件，显卡本身不需要接显示器。如果这块显卡是插在主板上用来输出 ESXi 主机画面的，那直通后主机端显示就会丢，可能还会导致设备初始化时序错乱。所以正确做法是让 ESXi 主机用板载显卡输出，独立显卡纯粹作为直通设备使用。
3. 虚拟机侧三板斧：UEFI引导、内存预留与MMIO参数
3.1 固件：为什么直通显卡一定要用UEFI
如果你去翻 VMware 社区里关于“需要重新引导”的老帖子，会发现大量案例最后都指向同一个问题：虚拟机固件用的是 BIOS。我一开始也觉得奇怪，BIOS 和 UEFI 不都是引导方式吗，怎么到了显卡直通这里就成了决定性因素？
原因在于设备固件的加载方式。传统 BIOS 启动的虚拟机，在引导阶段会尝试执行 PCIe 设备的 Option ROM。老显卡在 Option ROM 里同时提供了传统模式和 UEFI 模式的固件，所以 BIOS 模式也能点亮。但近几年的新显卡，很多厂商已经不再往 Option ROM 里塞传统模式代码，只保留 UEFI GOP 驱动。BIOS 固件的虚拟机在启动时找不到可用的 Option ROM，VMX 对显卡初始化就会失败，表现出来就是这个“已启动/需要重新引导”。
解决办法是在虚拟机设置里把固件切成 UEFI。但这里有个坑：如果 Windows 已经以 BIOS 模式安装在虚拟磁盘上，直接切换固件会导致系统无法引导，因为磁盘分区表还是 MBR，没有 EFI 系统分区。正确的做法是在安装操作系统之前就把虚拟机的引导固件设为 UEFI，然后再装系统。如果你已经用 BIOS 装好系统了，可以先用 Windows 的 MBR2GPT 工具转换磁盘格式，再切换固件，但操作复杂度和风险都不低，建议数据备份齐全后再做。
3.2 内存预留：直通设备要锁页
虚拟机配置里有一个非常容易被忽略的选项：内存预留。在“编辑设置 -> 虚拟机选项 -> 高级 -> 内存/CPU 热插拔”附近，有一个“预留所有客户机内存”的开关，显卡直通场景下必须打开。
直通设备的 DMA 操作直接读写物理内存页，而 ESXi 的虚拟内存机制允许客户机内存页被换出或者被 balloon 驱动回收。如果物理页被换走了，设备 DMA 写过来就会出现数据一致性问题。ESXi 的安全机制遇到这种情况会拒绝初始化直通设备，或者初始化到一半就放弃。打开“预留所有客户机内存”就是告诉 ESXi：这个虚拟机的内存页必须全部锁定在物理内存里，不允许换出。
需要提醒的是，勾了这个选项后，虚拟机的内存容量会直接占用主机物理内存。比如虚拟机配了 16GB 内存，主机就必须有 16GB 物理内存持续给这台机器占用。如果主机内存不够，虚拟机根本开不起来。所以做直通之前，要先确认主机物理内存是否充足。
3.3 大显存显卡的MMIO参数配置
显卡初始化失败最常见的一个日志信息是“MMIO space not available”，对应的原因就是虚拟机没有为直通设备预留足够的 MMIO 地址空间。默认情况下，VMX 给 PCIe 设备预留的 32 位 MMIO 窗口非常有限，根本放不下一张现代显卡几个 GB 的 BAR。
解决办法是在虚拟机高级配置参数里手动添加两项：
code复制pciPassthru.use64bitMMIO = "TRUE"
pciPassthru.64bitMMIOSize = "4096"
第一个参数让 VMX 允许使用 64 位 MMIO 空间，第二个参数指定预留多少 MB 的 64 位地址空间。值的大小建议根据显卡显存决定：显存 8GB 的显卡，4096 起步比较稳；显存 16GB 的显卡，建议直接设 8192；32GB 显存的卡，设 16384。这个值并不是越大越好，主机地址空间会被吃满，所以按需设置即可，不要盲目调到 65536。
也有少量老显卡需要配合 pciPassthru.use32bitMMIO = "TRUE" 使用，这个看具体卡，新卡一般用不到。
4. 命令行手工重置直通设备：比反复开关虚拟机更省事
4.1 用SSH进入ESXi并查看直通设备状态
Web Client 上反复关机开机解决不了问题时，我建议直接 SSH 到 ESXi 主机操作。首先在主机“操作”菜单里启用 SSH 服务，然后用终端登录。查看 PCIe 直通设备状态的命令是这样：
code复制esxcli hardware pci pcipassthru list
输出内容会列出所有支持直通的 PCIe 设备，找到你那张显卡对应的条目，重点看两行状态：
Passthru Enabled：设备是否已经启用了直通模式。Passthru Active：设备当前是否处于“活动占用”状态。
如果你的虚拟机已经关机，但 Passthru Active 仍然显示 true，说明设备没有被正常释放。这种情况正是“需要重新引导”的典型根源——VMX 认为设备还被占用着，实际已经没有虚拟机在用了，设备卡在一个半释放状态。
4.2 彻底终止残留VM进程并释放设备
如果虚拟机处于“已启动/需要重新引导”状态，先不要急着直接点开机。我先列出当前主机的虚拟机进程：
code复制esxcli vm process list
这个命令会显示所有正在运行的虚拟机进程及其 World ID。找到目标虚拟机对应的 World ID，如果 Web Client 里已经无法正常关机，可以用下面的命令强制终止：
code复制esxcli vm process kill --type=force --world-id=<World_ID>
强制终止之后，直通设备理论上会从占用状态释放。再执行一次 esxcli hardware pci pcipassthru list，确认 Passthru Active 变成了 false。如果还是 true，说明设备在底层没有被释放干净，可以用一组更彻底的“复位”操作把设备从直通模式退出再重新启用：
code复制esxcli hardware pci pcipassthru clear -d 0000:03:00.0
esxcli hardware pci pcipassthru set -d 0000:03:00.0
注意把 0000:03:00.0 替换成你自己显卡的 BDF（Bus:Device.Function）地址。这组命令会让设备重新走一遍驱动绑定和解绑流程，很多“假占用”状态都能清理掉。
4.3 重置直通设备后重新开机
设备状态确认干净之后，用命令行启动虚拟机会比 Web Client 更可靠：
code复制vim-cmd vmsvc/getallvms
vim-cmd vmsvc/power.on <VMID>
getallvms 会列出虚拟机的名称和 ID，power.on 后面的参数填虚拟机的 ID。启动之后等大约 20 秒，再执行：
code复制vim-cmd vmsvc/get.summary <VMID>
看输出里的 runtime.powerState 是否已经是 poweredOn，同时去 Web Client 确认“需要重新引导”的提示是否消失。如果消失了，说明问题出在设备残留占用，现在已经被清理掉了。
如果提示还在，那就进入下一步，去日志里找根因。
4.4 主机冷重启是最后的撒手锏
命令行重置解决不了时，不要太抗拒重启 ESXi 主机。直通设备在硬件层面卡死后，软件再怎么重置都没用，必须让主机重新上电，设备才会恢复到一个干净的出厂状态。有些时候，主机重启后直通设备状态会显示“D3”，即设备处于深度休眠，这种情况下需要把设备从直通中移除，再重新启用一次，才能让设备真正激活。
冷重启成本虽然高，但在直通故障排查里是一个非常有效的办法，尤其是设备固件状态异常的情况。不要把它当成首选，但也不要排除它。
5. 日志不会骗人：从vmkernel日志里定位真正原因
5.1 查看日志的命令和阅读方法
如果重置设备之后问题依然复现，说明不是设备残留占用的问题，而是某个条件根本不满足。这时候必须看日志。
ESXi 的关键日志在 /var/log/vmkernel.log，直通相关的错误基本都会记录在这里。SSH 登录后执行：
code复制grep -i "PT\|passthru\|BAR\|IOMMU" /var/log/vmkernel.log | tail -100
建议先看最后 100 行，因为虚拟机启动过程的报错都集中在最近的时间范围内。如果觉得日志刷得快，可以让虚拟机重新开机一次，同时用下面的命令实时跟踪：
code复制tail -f /var/log/vmkernel.log
然后在另一个终端启动虚拟机，观察日志输出。这样能直接定位到设备初始化失败的瞬间报了什么错。
5.2 两个真实案例：MMIO空间不足与Option ROM失败
先说我遇到的最常见的一种情况。某台机器直通一块 8GB 显存的 NVIDIA 显卡，虚拟机开机后状态就是“已启动/需要重新引导”。查看 vmkernel.log 发现一行关键错误：
code复制vmx: PT: Map BAR1 failed: MMIO space not available
这行日志直接说明了问题：虚拟机没有给显卡 BAR1 预留足够的 MMIO 空间。我在虚拟机的高级配置参数里加上 pciPassthru.64bitMMIOSize = "4096"，重启虚拟机，问题就解掉了。
另一种情况是 AMD 显卡，现象一模一样，但日志里报的是：
code复制vmx: PCI option ROM read failed, image not found
看到“option ROM”这个词，基本可以断定是虚拟机固件的问题。检查虚拟机配置确认固件确实是 BIOS，把固件改成 UEFI 之后重新引导，设备初始化就正常了。所以日志不是给你看的，是帮你缩小排查范围的——看到 MMIO 就去配参数，看到 Option ROM 就去查固件，方向对了，问题很快就能定位。
5.3 日志关键词对照表
我把直通排查过程中比较常见的日志关键词整理成了表格，方便你遇到问题时快速对照。
| 日志中的关键词 | 代表的含义 | 处理方向 |
|---|---|---|
MMIO space not available |
直通设备 BAR 空间不足 | 添加并调大 pciPassthru.64bitMMIOSize |
option ROM read failed |
显卡固件加载失败 | 虚拟机固件从 BIOS 切换为 UEFI |
IOMMU fault |
DMA 重映射异常 | 检查 VT-d/IOMMU 开关，检查内存预留 |
Device not reset |
设备没有完成硬件重置 | 重启 ESXi 主机，或执行直通设备重置 |
Device already in use |
设备被其他虚拟机占用 | 确认其他 VM 已关机，释放设备 |
Map DMA region failed |
DMA 区域映射失败 | 确认内存预留已勾选，主机内存充足 |
这份表格只能帮你确定排查方向，不能替代日志。遇到问题先把日志里最后一段与直通设备相关的信息完整截图，再对照这张表处理，效率会高很多。
6. 问题解决后的稳定运行习惯
6.1 改配置前先关机，等设备真正释放
显卡直通稳定运行的关键，在很多时候不是配置多花哨，而是操作习惯。我见过的绝大多数“需要重新引导”故障，都跟“在虚拟机开机状态下改动直通配置”有关。现在的 Web Client 虽然允许你在 VM 运行时添加 PCIe 设备，但这不代表 VMware 推荐这么做。正确顺序是：关机 -> 修改直通配置 -> 确认设备状态 -> 开机。
另外，虚拟机正常关机之后，如果直通设备还显示“活动”，不要立刻开机。等 20 到 30 秒，让 VMX 完成设备释放，再启动虚拟机。这个等待时间很短，但能省掉不少人祸。
6.2 直通虚拟机建议绑定NUMA节点
如果 ESXi 主机是双路 CPU 或者 CPU 的 PCIe 通道分布比较复杂，直通显卡所在的 NUMA 节点和虚拟机的内存节点如果不在同一个域，DMA 跨节点访问不仅性能会打折扣，偶尔也会触发初始化时序问题。
可以通过虚拟机的高级配置参数，把虚拟机绑定到显卡所在的 NUMA 节点上：
code复制numa.nodeAffinity = "0"
这里的节点编号需要根据显卡的具体位置调整，不确定的话先用 esxcli hardware pci pcipassthru list 查看设备信息，再用 lspci 辅助确认设备属于哪个 NUMA 节点。这个参数不是必须的，但主机硬件规模越大，越值得加。
6.3 一份可以直接套用的VM配置参数清单
最后我总结一份个人实践中比较稳定的直通虚拟机配置，供你新装系统时直接套用：
- 虚拟机硬件版本：与 ESXi 8.0.3U5 支持的最高版本一致，新版本对 PCIe 资源的管理更成熟。
- 引导固件：UEFI。
- 内存：预留所有客户机内存，大小按实际需要配。
- 高级参数：
pciPassthru.use64bitMMIO = "TRUE"。 - 高级参数：
pciPassthru.64bitMMIOSize = "4096"，显存 16GB 以上改 8192。 - 高级参数：
pciPassthru.allowUnlistedDevice = "TRUE"，仅当设备不在 HCL 且直通被拒绝时添加，不建议一开始就加。
这套配置在 8.0.3U5 上对 NVIDIA 和 AMD 的主流显卡都适用。只要硬件层 VT-d、Above 4G Decoding 正常，BIOS 设置没有明显问题，按照这套配置新装的虚拟机基本不会碰到“已启动/需要重新引导”。
最后再分享一个实际操作里的小技巧：如果你已经折腾了很久，每改一次参数就开机验证一次效率太低，可以先把虚拟机配置好一遍，不点开机，直接查看 vmx 文件确认参数都已经写入：
code复制find /vmfs/volumes -name "*.vmx" | xargs grep -n "pciPassthru"
确认参数写进去了，再开机。这样能省掉很多“改完配置发现没保存成功”的无效等待。ESXi 直通这东西，说难不算难，但每个环节都有讲究，希望这篇文章能帮你把这个状态一次性处理干净。