简介：面向VMware ESXi虚拟化管理员与运维工程师，这份网络直通配置指南围绕PCI Passthrough技术，完整说明如何将物理网卡直接映射给虚拟机，从而绕开虚拟化层转发，获得接近物理机的吞吐与延迟表现。文档从硬件兼容性检查入手，讲解如何判断设备是否支持直通，并指导在BIOS中开启PCI设备64位寻址；随后详细演示在虚拟机中添加PCI设备，以及在虚拟机选项中配置hypervisor.cpuid.v0、pciPassthru.use64bitMMIO、pciPassthru.64bitMMIOSizeGB等关键参数，并说明了这些参数的作用与设置时机。针对直通可能引发的虚拟化层保护失效、兼容性风险以及生产环境部署注意事项，文档也给出了提醒和备份策略建议。资源包内为1个docx文档，共343KB，内容以步骤分解和参数说明为主，结构清晰，适合随时查阅。目前已有1945人学习下载，可作为网络直通实施、调优和故障排查时的常备参考。

1. ESXi的网络直通：为什么我们会想把PCIe网卡直接塞给虚拟机

ESXi的虚拟交换机再怎么优化，数据面也要经过vmkernel和vSwitch的处理路径，双向流量拉到万兆以后，CPU开销和延迟曲线会变得很难看。网络直通（PCI Passthrough）把物理网卡直接交给某台虚拟机，让客户机驱动直接操作硬件队列，性能和物理机几乎一致，这是虚拟机跑软路由、DPI、边缘网关时最直接的提速手段。

这篇笔记围绕ESXi网络直通的完整落地过程展开：硬件支持判定、BIOS里64位寻址与VT-d开关、Web Client添加PCI设备、三个关键参数的写法与取舍，最后一章给出一套可复现的验证清单。中间会穿插我在真实服务器上踩到过的状态禁用、虚拟机起不来、客户机网卡消失这三类问题。

适合正在做软路由、边缘网关、DPI分析，或者对网卡多队列和低延迟有明确要求的虚拟化用户。全程不涉及SR-IOV的高级切分，先把手动直通这一条路走通。

2. 直通前的硬件体检：支持性确认与BIOS里的64位寻址开关

2.1 在ESXi里读取设备直通状态

网络直通的第一步不在虚拟机界面，而是在主机侧确认硬件能力。用vSphere Client登录后，选择目标ESXi主机，进入“管理 → 硬件 → PCI设备”。页面会列出该主机全部PCI设备，每行显示地址、厂商、设备名称、直通状态和驱动持有情况。你要找的是Ethernet Controller这一类，比如Intel XL710、E810、Mellanox ConnectX系列，或者Broadcom BCM5719/5720。

状态字段要会读，常见三种。禁用：设备支持直通，但未加入允许列表。活动：已加入允许列表，并且已经从vmkernel解绑，可以被虚拟机添加。需要重启：刚切换直通，设备等待主机重启完成解绑。如果设备型号太老、固件旧，还会出现“不支持”，那说明在当前BIOS和ESXi驱动组合下无法直通，没有参数可以绕开。

命令行确认比界面更准确，SSH到主机执行：

esxcli hardware pci list | grep -B 4 -A 14 "0000:03:00"

输出里的Vendor、Device、SubDevice三行用于核对网卡具体型号，ModuleName字段显示该设备当前被哪个驱动模块持有。继续往下看还有IOMMU Group（平台支持分组时才会出现），以及PassthruCapable、PassthruActive两个布尔字段。前者为true说明硬件支持直通，后者为true表示已经处于直通状态。这两个字段是后面排查问题时最直接的判断依据。

提示：直通状态下设备不再被ESXi的物理网卡驱动接管，主机侧的esxcli network nic list里会少掉这块网卡。看见网卡从列表消失不要慌，这是预期行为。

2.2 BIOS开启64位寻址：Above 4G Decoding不是可选项

直通网卡的MMIO BAR空间比较大，尤其是双口25G、单口100G这类设备，一块卡动辄占用几GB的BAR地址。BIOS默认只把PCIe设备的BAR映射到4GB以下，高地址窗口如果没打开，设备在客户机里会枚举失败，表现为虚拟机开机卡在PCI初始化，或者客户机lspci里根本没有这块卡。

BIOS里的开关名词因厂商而异，常见叫法如下：

这个开关必须在安装ESXi之前或直通之前就在BIOS里确认。开启后进入ESXi，用下面的命令核对设备BAR地址是否落在高位：

esxcli hardware pci list | grep -A 14 "0000:03:00" | grep -i -E "BAR|Address"

如果BAR起始地址在0x80000000以下，说明设备仍被压在32位窗口里，Above 4G Decoding没有真正生效。如果BAR地址明显高于0x80000000，说明64位寻址已经工作。这里有个容易误判的点：开启Above 4G之后不需要重启ESXi，但需要重启一次主机让BIOS重新枚举PCI总线。

2.3 “设备支持直通但状态禁用”不是异常，是默认

ESXi默认不会把所有支持直通的设备都加入允许列表，这是出于驱动稳定和安全的考虑。禁用状态在表格里其实是常态。要让设备可以被虚拟机使用，需要显式切换：选中设备，点“切换直通”，此时状态变为“需要重启”，重启主机后变成“活动”。

这一步有个翻车点：如果你直通的网卡正好是管理网络上行链路，重启后管理网络将失去这块网卡，vSphere Client直接断连。所以点“切换直通”之前，先去“网络 → 虚拟交换机”里查看管理网络vmk0的上行链路绑定的是哪个网卡，确认不是目标设备。

如果设备切换后状态一直停留在“需要重启”，说明直通请求没有被正常接收。常见做法是检查BIOS里的VT-d / AMD-Vi是否开启。注意VT-d（Directed I/O）和CPU虚拟化VT-x是两个开关，很多主板默认只开VT-x不开VT-d。VT-d没开，PCI直通所需的IOMMU映射表就不存在，ESXi在设备直通之前会静默失败。

注意：服务器定制BIOS里VT-d选项可能叫Intel Virtualization Technology for Directed I/O，AMD平台叫IOMMU或AMD-Vi。出现“需要重启”长时间无法推进时，优先查这个开关。

VT-d管IOMMU映射，Above 4G Decoding管BAR地址高位窗口，两者是独立项，缺一个直通配置都会卡在半路。

3. 给虚拟机挂载PCI设备：冷添加步骤与设备选择细节

3.1 Web Client冷添加PCI设备的完整路径

直通设备只能冷添加，虚拟机必须处于关机状态，这一点没有例外。路径是：vSphere Client选中虚拟机 → 右键“编辑设置” → “添加其它设备” → “PCI设备”。下拉列表里会出现当前主机所有直通状态为活动的设备，按总线地址过滤，选择目标网卡，例如0000:03:00.0，点击“添加”后保存。

保存后建议打开虚拟机的.vmx文件确认一下写入结果。在ESXi的shell里执行：

grep -i pciPassthru /vmfs/volumes/datastore1/你的虚拟机目录/你的虚拟机.vmx

正常会看到一行类似pciPassthru0.system = "TRUE"和pciPassthru0.id = "03:00.0"的记录。.vmx里没有这两行，说明设备没有被真正挂上，回头检查主机的直通状态。

这里有两个隐蔽问题。第一个是虚拟机硬件版本，过低的老版本虚拟PCIe桥枚举顺序可能不对，冷添加能成功但开机报No function错误，建议硬件版本不低于15。第二个是功能号选择，一块四口网卡会显示为0000:03:00.0到0000:03:00.3四个功能号，每个功能都是独立设备。如果你只需要单口吞吐，只添加一个功能号，不要四个全加进去，否则客户机驱动会尝试做多PF绑定，队列分配会互相干扰。

3.2 开机后怎么确认设备被正确认领

保存配置后启动虚拟机。在客户机Linux里执行：

lspci -nnk | grep -i -A 3 ethernet

正常输出会显示目标网卡型号，Kernel driver in use字段指向原生驱动，比如ixgbe、i40e、mlx5_core。如果字段显示Kernel modules: ixgbe但in use为空，说明设备还没有绑定驱动，继续执行：

dmesg | grep -i "pci 0000:03:00.0"

日志里出现probe失败信息，多数是因为驱动模块没加载，手动modprobe ixgbe试一次。手动加载成功，问题多半出在initramfs里没把驱动打进去，或者udev规则有冲突。加载不成功，就检查设备是否被其他虚拟机先占用了。

客户机里的队列数也要看一眼：

ethtool -l eth0

直通模式下队列数量应该和物理机一致，比如Intel X710四队列驱动模式下能看到Combined至少4到8。如果队列数只有1，说明驱动没有正确识别设备的多队列能力，通常和驱动版本过旧有关，优先升级客户机内网卡驱动。

3.3 直通与SR-IOV的互斥，以及快照和vMotion的限制

如果你之前在同一块网卡上开过SR-IOV，直通配置会撞车。ESXi同一时间只允许设备处于物理直通或SR-IOV驱动两者之一。直通活动状态下的PF设备无法再创建VF，反过来，已启用SR-IOV的物理网卡在直通列表里往往不出现，或者在切换直通时报错。

要保留SR-IOV又需要直通，只能把两种用途分配到不同物理端口，或者先关掉SR-IOV重启主机，再切换直通。两个动作不能同时存在。

另一个常被忽略的限制是直通设备绑定物理主机。开了直通的虚拟机不能vMotion到另一台宿主机，因为直通设备和物理PCIe槽位强绑定。快照也建议关掉，直通模式下快照恢复时IOMMU映射重建经常失败。这些限制不是配置错误，而是架构本身就有的，提前知道可以省去后面排障的时间。

4. 直通参数配置：hypervisor.cpuid.v0与64位MMIO的取舍

4.1 hypervisor.cpuid.v0="FALSE"：它管的是驱动认不认虚拟化

这个参数在显卡直通场景里很常见，网卡直通里它同样有意义，但作用面不同。参数值是FALSE时，客户机内CPUID指令不再暴露hypervisor位，等于告诉客户机里的驱动：这里不是虚拟机，是物理机。网卡直通场景下，这个参数解决的是驱动对虚拟化环境的检测问题。

哪些场景必须加？第一种，网卡驱动检测到虚拟化环境后主动关闭硬件卸载特性，比如TSO、GRO、多队列。第二种，厂商固件工具在虚拟化环境下拒绝执行配置改写操作。第三种，某些安全类中间层驱动在虚拟机里拦截DMA分配，导致驱动初始化失败。

添加路径是：虚拟机选项 → 高级 → 编辑配置 → 添加参数。键写hypervisor.cpuid.v0，值写FALSE，注意必须大写。

hypervisor.cpuid.v0 = "FALSE"

值一定要加引号，旧版本Web Client里裸写FALSE不一定会被正确识别为字符串。添加后保存并重启虚拟机。

提示：Intel ixgbe（X520/540/550）和i40e（XL710/X722）驱动通常不检查hypervisor位，不加这个参数直通也能正常跑。什么时候需要加，取决于你的网卡驱动源码里有没有虚拟机检测逻辑，这个只能实测。我的一般做法是：先不加参数直通开机，观察吞吐和队列数量，数据不对劲再关掉hypervisor位对比一次。

4.2 64位MMIO参数：BAR空间预留的含义与大小选择

第二个和第三个参数要配套使用：

pciPassthru.use64bitMMIO = "TRUE" pciPassthru.64bitMMIOSizeGB = "64"

use64bitMMIO为TRUE，表示允许直通设备把MMIO BAR预留在4GB以上的地址空间。64bitMMIOSizeGB数值是预留窗口的大小，单位是GB。直通设备的MSI-X table、doorbell register、DMA缓冲区都要占用BAR空间，设备越新、速率越高，BAR空间需求越大。不给足窗口，客户机开机时地址解算就会失败，或者设备枚举后中断无法投递。

那个“64”不是固定答案。它的合适值取决于你直通设备的BAR大小以及同一虚拟机里挂了几块直通卡。经验参考如下：

设置步骤同样在“虚拟机选项 → 高级 → 编辑配置”里，两个参数都按字符串类型加入，保存后重启生效。64bitMMIOSizeGB不要写成小于设备BAR实际需求的数值，否则ESXi开机加载虚拟机时会警告PCI资源不足。

这里顺便解决一个玄学问题：为什么我按文档设置了64GB，但客户机里看到的网卡BAR还是不高？因为BAR的实际映射地址由vmkernel在启动虚拟机时分配，客户机里用lspci -v看到的BAR地址不一定正好落在64GB窗口，它落在哪取决于已经启动的其他虚拟机占用了多少高位空间。只要use64bitMMIO为TRUE且64bitMMIOSizeGB足够大，映射就会落在4GB以上，不需要纠结具体数值。

4.3 参数写入的格式细节：引号、大小写与顺序

编辑配置对话框里参数是按字母顺序展示还是按添加顺序展示，不同版本的vSphere Client表现不一样，这个不用纠结。真正影响生效的是值格式。三个参数统一用字符串格式：

hypervisor.cpuid.v0 = "FALSE" pciPassthru.use64bitMMIO = "TRUE" pciPassthru.64bitMMIOSizeGB = "64"

TRUE和FALSE必须大写，小写true在部分版本里会被解析成无效值。64同样要加引号，裸写数字在个别版本里会被当成布尔量处理，结果是MMIO窗口创建失败，虚拟机直接无法开机。

还有一个容易漏掉的点：修改这几个参数前先检查.vmx里有没有残留的旧值。虚拟机之前如果做过直通后又移除，.vmx里可能还会存有pciPassthru0相关的旧配置。新旧参数叠加后会被虚拟机开机时一起解析，出现参数“覆盖失效”的怪问题。稳妥做法是先移除旧PCI设备，保存一次，再重新添加并写入参数。

5. 直通常见问题排查：禁用状态、开不了机和网卡消失

这一章把我在实机环境里踩过、以及帮别人排过的坑按“现象 → 原因 → 解决”三要素列出来，每一条都值得在动手前对照。

5.1 设备状态一直“禁用”，切换直通按钮点了没反应

现象：主机管理 → 硬件 → PCI设备里，网卡直通状态持续显示“禁用”，点击“切换直通”后没有任何变化，也不报错。

原因：ESXi检查到该设备当前被vmkernel驱动持有，而且这块网卡正被管理网络或某个虚拟交换机使用。切换直通请求会被静默拒绝。另一种原因是vCenter版本偏老，对较新设备ID的处理逻辑不完整。

解决：先确认目标网卡没有正被管理网络占用。SSH执行：

esxcli network nic list

看Driver和Link Status列。如果网卡处于活动状态，把管理网络迁移到其他上行链路后执行：

esxcli network nic unload -n vmnic2

卸载驱动后再回到Web Client点“切换直通”。如果仍然是禁用，检查设备ID是否在vCenter兼容列表内。不在的话只能升级vCenter，或者直接改ESXi的passthru.map，后者属于深度操作，不建议在生产环境尝试。

5.2 直通后虚拟机无法开机，报断言失败

现象：虚拟机电源操作报Failed to power on: Assertion failed，事件详情里提示某个PCI设备地址没被识别。

原因：多数情况下是.vmx里残留的直通配置和当前物理设备总线地址对不上。比如物理网卡从0000:03:00.0换到0000:05:00.0，但虚拟机的旧配置还指向03:00.0，vmkernel开机时找不到对应设备。

解决：确认物理设备当前地址：

esxcli hardware pci list | grep -i "Intel.*Ethernet" | grep "0000:"

然后在虚拟机“编辑设置 → PCI设备”里移除旧设备，重新从列表选择当前地址对应的设备，保存再开机。如果移除后.vmx里仍有pciPassthru0相关行，需要直接编辑VMX文件删除残留配置。

5.3 直通网卡的虚拟机开机后客户机里看不到设备

现象：虚拟机电源正常，客户机系统能起来，但lspci输出里找不到直通网卡。

原因：设备被添加到了虚拟机的PCIe总线高位域，客户机OS没有正确枚举到对应PCIe桥。常见于虚拟机硬件版本过旧，或者.vmx里的内存预留策略挤占了MMIO窗口。

解决：先把虚拟机硬件升级到v15以上。然后核对第4章里的pciPassthru.use64bitMMIO和pciPassthru.64bitMMIOSizeGB两个参数是否已经写入。如果还在虚拟机配置里见过“内存热添加”，关闭它保存重启一次，再重新开启。内存热添加会改变客户机内PCI枚举顺序，和直通设备经常打架。

5.4 多队列都在但吞吐上不去，重传率高

现象：iperf3测速只有线速三分之一，netstat -s里重传率高得异常，CPU占用看着不高。

原因：直通模式下多队列已经创建，但每个队列的中断全落在一个vCPU上。直通设备的中断一样走虚拟中断控制器，vCPU亲和性不对时，中断热点会集中在某一个逻辑处理器上，吞吐自然上不去。另一个常见原因是直通网卡所在PCIe插槽和虚拟机vCPU不在同一个NUMA节点，跨节点访问内存，万兆场景下性能损失非常大。

解决：先看主机侧网卡所在NUMA节点：

esxcli hardware pci list | grep -A 20 "0000:03:00" | grep -i numa

然后在虚拟机属性里把CPU和内存调度都绑定到该NUMA节点。客户机内部再看中断分布：

cat /proc/interrupts | grep -i ixgbe

如果中断集中在单个CPU，用irqbalance --banirq把对应中断号排除出去，或者写/proc/irq/<中断号>/smp_affinity手工分散。

5.5 主机关机或重启卡在PCI设备初始化

现象：主机重启后黑屏，进度条卡住不动，BIOS菜单都进不去。

原因：上面第2节强调过Above 4G Decoding要开，这里还有一个隐藏点。某些服务器主板在PCIe初始化阶段，如果检测到某设备BAR空间请求过大且高地址窗口未开启，会直接挂起整个PCI枚举流程，导致ESXi永远起不来。

解决：开机进BIOS把Above 4G Decoding打开，然后恢复BIOS默认设置，重启后再重新配置直通。如果连BIOS都进不去，只能清CMOS跳线。清CMOS会丢失BIOS里所有定制项，所以生产机器改直通前，务必先把BIOS配置导出备份。

6. 验证与进阶：从iperf3测速到SR-IOV的升级路线

配置完成后，先做一次基准验证。在直通网卡上配置IP，与另一台物理机互通，然后跑iperf3：

iperf3 -c 192.168.10.2 -t 60 -P 8

观察双向吞吐是否接近线速，同时看客户端CPU占用。再用ethtool -L eth0 combined 8确认队列数量，直通场景下队列数应该和物理机一致。还有一步容易被漏掉：ethtool -k eth0 | grep -E "tx-checksum|tcp-segmentation"，确认TSO和GRO没有被驱动禁用掉。

之后拿同一台虚拟机用VMXNET3虚拟网卡再跑一轮同样的iperf3，两组数据放一起对比，你就能直观看到直通带来的收益。这里给一个可复现的对比方法：固定同一台对端服务器、同一测试时长、同一并行流数，只切换网卡类型，记录吞吐和CPU占用两组数据。

我的一贯做法是，开直通前先在本地笔记里写下物理机上的基线数据，队列数、TSO状态、最大吞吐，直通后逐项核对。数值有出入就回去查，不凭感觉判断。

如果直通的性能已经达标，但你发现多台虚拟机都需要共享同一块万兆网卡，下一步就该看SR-IOV。SR-IOV可以在物理PF下切出多个VF，每个VF单独直通给不同虚拟机，保留硬件级队列隔离，而且宿主机保留PF的管理能力，不会像完整直通那样把整块卡独占。升级路线是这样判断的：单机追求极致低延迟，用完整PCI直通；多虚机隔离需求上来，把PF切VF更合理。

从那以后，我每次在ESXi上给机器配网络直通，都强制把这三条过一遍：BIOS里Above 4G Decoding确认开启、切换直通前确认网卡不持有管理网络和SR-IOV、虚拟机里三个参数以字符串格式写入并核对引号。这套习惯替我挡过至少三次生产环境的返工，希望帮到你。

本文还有配套的精品资源，点击获取