爬一手好线杆1. 先说清楚“已启动/需要重新引导”到底是个什么状态
如果最近你在 ESXi 8.0.3U5 上给虚拟机直通了一张显卡，然后在“虚拟机”页面看到状态栏卡在“已启动/需要重新引导”，先别慌，这不是死机，也不是直通彻底失败，而是VMkernel在设备初始化阶段没把显卡正常交给虚拟机，于是虚拟机的电源状态已经起来了，但PCIe设备没有被成功挂载。
这个状态在上一个 ESXi 版本里也会出现，但 8.0.3U5 里特别容易碰到，尤其是当你用消费级N卡、A卡或者Intel核显做直通的时候。它在Web Client里的表现就是：虚拟机显示“已启动”，但选项里又提示“需要重新引导”；你点关机，关不掉，只能强制断电；重新开机后还是老样子，甚至有时候卡在同一个状态里出不来。
为什么会这样？直通本质上就是把物理PCIe设备从ESXi手里剥离，交给虚拟机驱动直接控制。设备要经过“宿主解除驱动绑定 → IOMMU域分配 → BAR地址映射 → 设备初始化 → 中断路由配置”这几步。任何一步出问题，设备都无法真正落到虚拟机里。而这个“已启动/需要重新引导”的状态，就是在告诉你：“设备没能完成初始化，VMX进程虽然创建了，但设备没接上去。”
我自己第一次遇到这个问题时，也觉得是直通方式不对，反反复复取消直通、重开虚拟机，折腾了好几个小时。后来才摸到规律：这其实是一个可以按固定套路排查和解决的工程问题，只是网上那些零散教程各说各话，把新手带偏了。这篇就结合我的实操经验，把从状态解读、原因定位到最终解决的完整路径写出来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 直通失败的核心原因与排查思路
2.1 先判断问题出在宿主层还是虚拟机层
遇到“已启动/需要重新引导”，第一件事不是去改虚拟机的配置，而是先分清问题出在哪个层面。我习惯用排除法：
- 先在ESXi宿主上执行
esxcli hardware pci pcipassthru list，查看显卡的直通状态。如果显示Passthru Active，说明ESXi已经允许设备直通，问题多半出在虚拟机启动时设备初始化阶段；如果显示Passthru Candidate，说明还没真正处于直通模式，需要在硬件设置里重新标记直通并重启宿主。 - 再看
lspci -v确认设备是否被VMkernel驱动占用。如果设备还在vmwara_pcie或vmklinux驱动下，说明ESXi没有把设备释放出来，直通状态是假的。 - 然后看虚拟机的“编辑设置”里，PCI设备是否已经添加、是否处于“已连接”状态。
如果是候选状态，多半是宿主没重启就添加了直通，或者ESXi没完成设备降级。如果设备状态已经是 Passthru Active，但虚拟机还是提示需要重新引导，那重点转向虚拟机配置与BIOS参数层面。
我一般会在这一步先做个快速复现：给这台虚拟机取消直通设备，开机确认能正常进系统。如果取消直通后虚拟机一切正常，那问题100%是直通相关配置引起的，跟虚拟机本身的系统、驱动无关。
2.2 从日志里翻出真正的报错原因
排查这种问题，日志比任何“网上偏方”都靠谱。ESXi下最直接的日志是 /var/log/vmkernel.log，它记录了VMkernel对PCIe设备的初始化过程。当你启动带直通设备的虚拟机时，可以在日志里搜设备地址、passthru、VFIO、DMA这些关键词。
常见的有这几类报错：
| 日志关键词 | 含义 | 指向 |
|---|---|---|
Failed to initialize device |
设备初始化失败 | 设备驱动绑定或BAR映射问题 |
Insufficient resources |
资源不足 | 内存或IOMMU域分配失败 |
Failed to map BAR |
BAR地址映射失败 | 地址空间冲突或Above 4G未开启 |
DMA remapping error |
DMA重映射失败 | IOMMU/中断重映射配置问题 |
Passthru not supported |
设备不支持直通 | passthru.map未覆盖或有严格限制 |
我第一次遇到时，日志里刷了近百行 Failed to map BAR，当时还以为是显卡坏了。后来查了一圈，其实是BIOS里Above 4G Decoding没打开，显卡的64位PCI BAR空间没有被分配到大内存地址段上，ESXi无法完成映射，于是一直卡在“需要重新引导”的状态。
所以，排查这个问题的基本流程是：
- 先打开BIOS/UEFI设置，确认
VT-d（Intel）或AMD IOMMU已开启，Above 4G Decoding已经打开； - 再检查ESXi宿主是否已经重启过，确保持久配置生效；
- 然后启动虚拟机抓一轮 vmkernel 日志，查具体报错；
- 最后根据日志关键词，针对性调整参数。
2.3 别忘了检查直通设备的整体形态
这里有个容易被忽略的坑：显卡的PCIe设备在lspci里往往不止显示为一个功能。比如很多N卡会暴露为一个显卡功能加一个音频功能；而专业卡还会多一个3D控制器功能。ESXi直通的最小单位是“设备”，但有些场景下要求整个PCIe设备（包括所有功能号）一起直通。
如果在“编辑设置”里只添加了显卡功能，没有把声卡功能一起加进去，虚拟机启动时设备会被分到两个不同的IOMMU组里，宿主无法建立完整的设备映射，同样会导致“需要重新引导”的状态。
碰到这种情况，建议把显卡相关的所有功能都添加到虚拟机里。比如N卡常见的是Audio device和VGA compatible controller两个功能，全部添加后一起直通，很多莫名其妙的状态问题就消失了。类似的经验在给网卡做直通时也一样：有些网卡带管理功能或虚拟功能，如果不整体直通，直通后也会出现启动异常。
3. 核心解决方案：让直通设备真正完成初始化
3.1 打开BIOS里那三个“基础开关”
别嫌这一步琐碎，我处理过的“已启动/需要重新引导”案例里，有接近一半是BIOS设置不对导致的。ESXi 8.0.3U5 对PCIe直通的要求比之前版本更严格，尤其是开启 Secure Boot 和 UEFI 的环境，下面三个开关缺一不可：
- VT-d / AMD IOMMU：这是设备直通的基石。Intel平台叫
VT-d，AMD平台叫IOMMU，不同主板位置不一样，一般在Advanced → North Bridge或Advanced → PCI Subsystem里。 - Above 4G Decoding：必须开启。现代显卡都有64位BAR，如果这个开关没开，BAR会被分配到32位地址段，很容易跟系统保留内存冲突，导致映射失败。
- CSM（Compatibility Support Module）：建议关闭。ESXi 8.x 和部分显卡驱动在UEFI模式下更稳定，开启CSM会让PCIe ROM初始化走传统方式，反而增加直通失败概率。
改完BIOS参数后，一定不要偷懒跳过“断电重启”。很多主板对BIOS配置的生效，不是简单的热重启能完成的。我习惯是保存后彻底断电2~3秒再开机，这样能保证IOMMU和PCIe枚举逻辑完全重置。
3.2 检查并修正 passthru.map 设备映射配置
ESXi通过 /etc/vmware/passthru.map 文件来声明哪些PCIe设备支持直通。这个文件里有设备厂商ID、设备ID和一个reset属性字段。显卡直通时如果设备ID不在列表里，或者reset类型设置不当，就会出现设备能标记为直通但启动时无法正常初始化的问题。
如果你的显卡在直通列表里状态正常，但虚拟机一直“需要重新引导”，可以手动查看一下这个文件：
bash复制cat /etc/vmware/passthru.map
找到你的显卡对应的行，通常是类似这样的格式：
code复制# NVIDIA Corporation GA102 [GeForce RTX 3080]
10de 2206 default reset
如果你发现设备ID那一段是unsupported或者没有对应条目，就需要手动添加。比如你的显卡设备ID是2489，可以追加一行格式正确的配置。添加后执行：
bash复制esxcli hardware pci pcipassthru list
确认设备状态变为支持后，重启宿主使配置生效。这个操作有风险，修改前最好先备份原文件：
bash复制cp /etc/vmware/passthru.map /etc/vmware/passthru.map.bak
这里需要说明一下：passthru.map的作用是告诉ESXi哪些设备允许直通，以及使用哪种reset方式。如果设备不在列表里，ESXi默认会拒绝直通，或者只用默认reset；而reset方式不对，设备在虚拟机重启后就会进入未知状态，表现就是“需要重新引导”。
3.3 调整ESXi引导参数和虚拟机配置参数
如果BIOS和passthru.map都没问题，那大概率是ESXi的默认PCI直通参数没有适配你的显卡。ESXi支持通过引导参数和虚拟机配置参数来覆盖PCIe直通行为。我试下来，下面几条参数对解决“无法完成初始化”非常有效：
ESXi引导参数：
pciPassthru.use32bitMMIO=true：强制将PCIe设备的MMIO BAR分配到32位地址空间。适合某些老显卡或旧平台。pciPassthru.allowLegacyMSI=true：允许直通设备使用传统MSI中断机制，部分显卡在MSI-X初始化失败后会卡住。
在ESXi启动界面按Shift+O，在引导选项末尾追加参数，回车启动。如果发现有效，再用：
bash复制esxcli system settings kernel set -s pciPassthru -o use32bitMMIO -v true
持久化参数设置，避免每次启动都要手动敲。
虚拟机配置参数：
在虚拟机“编辑设置 → 虚拟机选项 → 高级 → 配置参数”里，添加以下几项（没有的项需要手动新增）：
| 参数名 | 推荐值 | 说明 |
|---|---|---|
pciPassthru.64bitMMIOSize |
4096 |
指定64位MMIO空间大小（单位MB），显卡显存越大越需要调高 |
pciPassthru.use32bitMMIO |
TRUE |
强制32位MMIO映射，某些平台专用 |
pciPassthru.allowLegacyMSI |
TRUE |
允许传统MSI中断 |
pciPassthru.overrideMmapType |
1 |
绕过某些宿主的mmap限制，8.x部分版本有效 |
这里需要解释一下 pciPassthru.64bitMMIOSize 的取值逻辑。显卡的BAR空间不止是显存，还包括寄存器和ROM区域。显卡在设备管理器里显示的内存范围通常接近显存大小，再加上4KB~256MB的其他映射，所以如果你显卡是8GB显存，建议至少给4096MB，12GB显存建议给6144MB，以此类推。设置太小，BAR空间不够，设备初始化就会失败。
有不少人在加了 pciPassthru.64bitMMIOSize 后，问题立刻解决。这背后的原因很简单：BIOS里Above 4G Decoding和ESXi默认的MMIO大小是两码事。前者只保证64位地址可用，后者决定系统为直通设备预留多大的地址窗口。窗口不够，显卡的BAR就映射不进去。
3.4 核显直通的特殊处理
如果你直通的是Intel核显，还有两个额外需要注意的地方。
一是核显的OPRegion区域。ESXi对核显直通的支持不如独立显卡完善，经常出现设备标记为直通但虚拟机启动时无法访问OPRegion的情况。解决方式是在虚拟机配置里增加：
code复制pciPassthru.ignoreOpRegion=TRUE
这会跳过OPRegion的初始化检查，代价是核显的部分vBIOS功能无法正常工作。对于日常桌面直通和简单的硬件加速场景，这个参数是可以接受的。
二是核显直通时，ESXi本身不能占用核显。如果你的ESXi宿主的图形输出接在核显上，而你又想把核显直通给虚拟机，宿主必须改为无头或者使用独立显卡做显示输出。否则宿主驱动还扣着核显，直通状态永远是“候选”，虚拟机自然卡“需要重新引导”。
3.5 直通后的复位问题：重置设备状态
还有一个高频问题：直通设备在虚拟机强制关机后没有正确复位，导致下一次启动时设备停留在上一个状态，无法初始化。这个情况尤其容易出现在Nvidia显卡上，因为显卡在上一次使用后可能还保留着驱动中的DMA映射。
解决办法是给虚拟机配置强制复位参数：
code复制pciPassthru.resetOnPassthruError=TRUE
pciPassthru.fallbackReset=TRUE
这两个参数的作用是：当设备退出直通后，强制对设备做一次FLR（Function Level Reset）或总线复位，清掉残留状态。添加后，再遇到“需要重新引导”时，通常关机再开机就能恢复，不需要重启宿主机。
如果你在使用多张显卡直通给多台虚拟机，还需要注意同一张卡不能同时被两台虚拟机使用；ESXi默认不允许设备被重复标记为直通，如果你强行修改配置同时使用，会出现更诡异的状态。
4. 完整实操过程：从排查到最终解决
4.1 一步一步操作的完整命令清单
下面是我在真机上验证过的完整流程，假设你要直通一张NVIDIA独立显卡给Windows虚拟机。按照顺序执行，可以覆盖绝大多数“已启动/需要重新引导”的场景。
第一步：确认硬件支持与BIOS设置
重启服务器，进入BIOS，确认以下选项：
- Intel平台开启
VT-d，AMD平台开启IOMMU； - 开启
Above 4G Decoding； - 关闭
CSM，使用纯UEFI模式； - 保存退出，彻底断电重启。
第二步：进入ESXi Shell，检查当前直通状态
bash复制esxcli hardware pci pcipassthru list | grep -A5 -B5 "NVIDIA"
确认显卡的Passthru列是true。如果还不是，需要先在Web Client的“硬件 → PCI设备”里勾选该显卡，点击“切换直通”，然后重启宿主。
第三步：确认设备没有绑定宿主驱动
bash复制lspci -v | grep -A10 "VGA"
检查显卡是否显示Kernel driver: vmwara_pciback或未绑定任何驱动。如果显示vmwara_pcie等ESXi原生驱动，说明还没释放设备。
第四步：检查设备ID和passthru.map
bash复制lspci -n | grep -i "nvidia"
记录设备厂商ID和设备ID，查/etc/vmware/passthru.map是否有对应条目。没有就手动添加，重启宿主。
第五步：在虚拟机中添加PCI设备
Web Client里编辑虚拟机，添加PCI设备，选择显卡，勾选“启用直通”。如果显卡有多个功能节点，一并添加。然后记录添加时自动生成的参数（有时是pciPassthru.0等）。
第六步：添加关键配置参数
在虚拟机高级配置参数里添加：
code复制pciPassthru.64bitMMIOSize = 4096
pciPassthru.allowLegacyMSI = TRUE
pciPassthru.resetOnPassthruError = TRUE
pciPassthru.fallbackReset = TRUE
如果显卡是N卡，可以额外加：
code复制hypervisor.cpuid.v0 = FALSE
第七步：启动虚拟机并查看日志
bash复制tail -f /var/log/vmkernel.log | grep -i passthru
另开一个SSH窗口启动虚拟机。观察日志是否出现 Device 0000:xx:00.0 is ready 或 Passthru device successfully initialized 类似的输出。如果还是初始化失败，回到第三步排查。
4.2 我的真实案例：一张RTX 3080卡了3天
我自己手上有一台跑ESXi 8.0.3U5的主机，给Windows 10虚拟机直通RTX 3080，遇到的就是“已启动/需要重新引导”。当时日志里明确写了Failed to map BAR。
我先尝试了pciPassthru.use32bitMMIO=true，没用；于是检查BIOS，发现Above 4G Decoding虽然在主板的“高级”菜单里，但保存后没有真正生效，等到彻底断电重启才生效。这时候直通设备已经可以完成初始化，虚拟机也进入系统，但显卡驱动还是显示错误43。
接着我给虚拟机加上了 hypervisor.cpuid.v0 = FALSE 和 pciPassthru.64bitMMIOSize = 4096，再启动一次，显卡驱动正常安装，硬件加速也跑起来了。整个过程如果有什么值得说的教训，那就是：不要迷信单个参数，BIOS、设备绑定、MMIO空间、隐藏虚拟机特征这些因素经常是连环问题。先解决启动初始化，再解决驱动识别，一次性全做完反而容易找不到问题点。
5. 常见问题与排查技巧速查表
5.1 状态与处理建议对照表
| 现象 | 可能原因 | 处理建议 |
|---|---|---|
| 虚拟机显示“已启动/需要重新引导”，无法关机 | 设备初始化失败，虚拟机没有完全崩溃 | 强制断电；检查直通设备相关配置后重新开机 |
日志报 Failed to map BAR |
64位MMIO空间不足，或Above 4G未开 | 开启Above 4G；提高pciPassthru.64bitMMIOSize |
日志报 Insufficient resources |
IOMMU域分配失败，内存窗口不够 | 检查BIOS里IOMMU设置；预留内存给直通设备 |
日志报 DMA remapping error |
中断/IOMMU配置异常 | 确认VT-d/AMD IOMMU开启；尝试pciPassthru.allowLegacyMSI |
| 设备状态为“候选”而非“活动” | 宿主未重启或驱动未释放 | 切换直通后重启宿主；检查是否被宿主驱动占用 |
| N卡驱动报错误43 | 未隐藏虚拟机特征 | 添加hypervisor.cpuid.v0 = FALSE |
| 核显启动后黑屏或无法加速 | OPRegion问题 | 添加pciPassthru.ignoreOpRegion=TRUE |
| 强制关机后再次开机仍然无法启动 | 设备复位不完整 | 加pciPassthru.resetOnPassthruError=TRUE和pciPassthru.fallbackReset=TRUE |
5.2 几个容易被忽略但很关键的点
第一，ESXi 8.0.3U5 对Secure Boot的支持更严格了。如果你的宿主开启了Secure Boot，而虚拟机配置参数里又加了 hypervisor.cpuid.v0 = FALSE，这个参数可能不会生效。N卡驱动识别40系以上有些会认VM特征，需要确认Secure Boot状态下参数是否真的被应用。我实测的结论是：在开启Secure Boot的宿主上，部分隐藏VM特征的参数会被ESXi屏蔽。建议测试时临时关闭宿主Secure Boot，验证参数有效性后，再根据需求决定是否开启。
第二，显卡直通后，虚拟机内存不要使用全部预留。IOMMU在做DMA映射时，需要为直通设备预留连续的内存区域。如果你把宿主的全部内存都分配给虚拟机，宿主找不到足够的空闲内存来建立DMA映射，设备初始化同样失败。一般建议至少给宿主预留2GB以上可用内存，如果显卡显存很大，预留更多。
第三，Windows虚拟机的操作系统版本也会影响结果。ESXi 8.0.3U5直通显卡给Windows 10/11时，建议虚拟机硬件版本选择与ESXi兼容的最高版本，同时确保安装了最新的VMware Tools。部分问题其实不是直通导致，而是虚拟机的PCIe拓扑不被Windows识别。
第四，如果你直通的是双显卡（例如核显+A卡/N卡），注意ESXi的直通分配可能落在同一个IOMMU组。IOMMU组内的设备必须一起直通，不能拆散。查看IOMMU分组的方式：
bash复制esxcli hardware pci iommu group list
如果你的显卡和一个NVMe控制器被分在同一组，必须把NVMe也一起直通给虚拟机，否则就会导致直通设备无法初始化。
第五，直通状态出现后，有时你看到虚拟机是“已启动”但无法操作，不要直接点在界面上点“重新引导”，那样通常无效。正确做法是强制关机（相当于拔电源），确认状态变为“已关闭”，再修改配置或再次开机。很多人的误区在于，在虚拟机还没完全关闭时就重新编辑配置，导致配置更新不能正确应用。
6. 一些个人经验和建议
直通显卡这件事，ESXi和PVE/Hyper-V比起来，确实是配置门槛最高的。尤其是ESXi 8.x对PCIe设备的IOMMU要求更严格，很多以前“能用就行”的妥协方案在新版本里行不通了。
我在实际使用中最深的体会是，排查这种问题，最好按“BIOS开关 → 设备释放 → passthru.map → VM参数 → 驱动识别”的顺序，一层一层过滤问题。不要一开始就盲目往虚拟机里叠加参数。叠加的临时参数多了，反而分不清到底是哪个配置生效，哪个配置造成了新的副作用。
还有，建议大家养成一个好习惯：每次调整完直通相关配置后，都抓一份 vmkernel.log 留档，文件名加上日期。直通的问题经常是间歇性的，比如重启两次正常，第三次又卡住。如果没有日志留档，你很难回溯是哪次配置变更触发了问题。我自己的做法是：
bash复制cp /var/log/vmkernel.log /tmp/vmkernel-$(date +%Y%m%d-%H%M).log
另外，如果是给一台新装的ESXi 8.0.3U5做规划，我会提前把要用到的显卡型号查清楚，确认它在ESXi 8.0.3U5的硬件兼容列表里。虽然很多不在列表里的显卡也能用，但“能用”和“稳定直通”之间隔着一堆BIOS和BIOS厂商的兼容性问题。ESXi 8.x对设备驱动和IOMMU处理的改动比较大，老黄历的兼容经验有时并不适用。
如果你在这个状态上纠结了很久，不妨试试把宿主和虚拟机的配置都简化到最小环境：一块系统盘、一张显卡、一台虚拟机。在最小环境里调到能稳定直通，再逐步加回其他设备。这个方法听起来笨，但在处理多个PCIe设备互相抢占IOMMU资源时，效率比我见过的大多数“找参数”方案都高。
最后再分享一个冷门但我实际验证过的技巧：如果你的显卡直通后一直报 Insufficient resources，尝试在ESXi引导参数中追加 pciPassthru.barAllocPolicy=allocMinimum。这个参数会迫使ESXi为每个直通设备只分配必要的BAR空间，而不是默认的全部预留。对内存资源紧张但有多张显卡的宿主机，这个参数可能救急。不过它也会带来一定的兼容性风险，如果不是资源紧张，不建议长期开启。
希望这篇能帮到同样被“已启动/需要重新引导”卡住的人。直通这条路，配置时多留个心眼，排查时多翻日志，踩坑多了，经验自然就出来了。