ESXi 8.0 集成 RTL 瑞昱螃蟹网卡驱动后出现断流这个标题下的问题我处理过太多次了。现象往往高度一致驱动装好了、网卡也认出来了ESXi 界面里链路显示 Up结果管理端每隔一阵就失联虚拟机 Ping 网关时通时不通大流量一上来甚至整块网卡直接“假死”重启主机才恢复。更气人的是它不规律发作排查时干干净净一上线就犯病。这篇文章我就把集成驱动、断流根因、排查手段和最后的落地解法一次讲清楚给正在被螃蟹卡折磨的虚拟化玩家一点能直接抄作业的东西。1. 为什么 ESXi 8.0 装个螃蟹卡驱动会给自己挖断流的坑1.1 官方支持列表里根本没有它先捅破一层窗户纸ESXi 8.0 的官方硬件兼容列表里RTL 瑞昱螃蟹网卡基本是“查无此卡”的状态。VMware 官方驱动只面向服务器级网卡比如常见的数据中心网卡和部分中高端板载方案。螃蟹卡虽然在消费级主板里遍地都是但在 ESXi 眼里属于“非标准硬件”官方不会给你提供驱动也不承诺稳定性。所以想在 ESXi 8.0 里用上螃蟹卡只能走社区驱动路线也就是把第三方打包的 VIB 驱动制作进安装镜像里。这个 VIB 本质上是一组由社区开发者移植和维护的驱动模块不是官方内核自带的东西。正因如此“能识别”和“能稳定跑”是两回事。我看到很多安装了螃蟹卡驱动的机器启动时一切正常但跑半天后就开始丢包、断流原因就藏在驱动和 ESXi 内核的配合程度上。ESXi 8.0 相对 6.x、7.x 有内核层面的更新很多在旧版本上很稳的社区驱动拿到 8.0 后并不一定仍有同等兼容性。如果你手里的驱动包是从网上随便搜的、不是针对 8.0 重新编译的版本那断流几乎是必然的。1.2 两种常见集成方式踩坑深度不一样把螃蟹卡驱动集成进 ESXi 安装镜像常见的方式有两种很多人不区分但这会影响后面的稳定。一种是直接用图形化定制工具把 VIB 塞进官方 ISO 里重新打包。这种操作上手最快适合个人玩家单台安装。比较典型的就是把官方 Offline Bundle 或 VIB 文件加载进去生成一个带驱动的新 ISO。优点是快缺点是它不会帮你检查驱动和内核 API 是否匹配塞进去能跑就默认成功。另一种是用 Image Builder PowerCLI 从官方软件包仓库生成新镜像。这种方式更接近正规部署流程能自定义 VIB、剔除不需要的组件也更容易保留多个版本做回退。PowerCLI 的典型操作思路是这样# 加载离线软件包 Add-EsxSoftwareDepot D:\offline_bundle.zip # 基于官方标准配置克隆一个新的 Image Profile New-EsxImageProfile -CloneProfile ESXi-8.0.0-standard -Name ESXi-8.0-RTL -Vendor local # 查找并添加螃蟹卡驱动包 Get-EsxSoftwarePackage | Where-Object {$_.Name -like *r8168*} Add-EsxSoftwarePackage -ImageProfile ESXi-8.0-RTL -SoftwarePackage net-r8168_xxx # 导出成 ISO 或 Offline Bundle Export-EsxImageProfile -ImageProfile ESXi-8.0-RTL -ExportToIso -FilePath D:\ESXi-8.0-RTL.iso我个人的经验是集成方式确实会影响后面的稳定性但更关键的是选对 VIB 版本。别用 6.x 时代的老包也不要迷信“通用的就是最好的”。上机装好后第一件事要确认驱动是否真的被系统加载esxcli software vib list | grep -i net esxcfg-nics -l如果esxcfg-nics -l里能看到 vmnic0 对应的是 RTL 控制器说明驱动层面已经接管了网卡。但接管只是开始断流的排查是从这一刻才正式开始的。2. 断流到底断在哪先分清现象和根因2.1 三个典型断流场景螃蟹卡在 ESXi 8.0 上的断流并不会总是以同一种面目出现。我遇到的基本可以归成三类你也可以对照自己的现象定位方向。场景一管理端偶发掉线。ESXi Web 管理界面或者 SSH 时不时失去响应有时候几十秒自己恢复有时候直接连不上只能去物理机强制重启。这类问题往往被怀疑是 Web 服务的问题但最后几乎都指向网卡驱动不稳定。场景二大流量触发网卡假死。虚拟机做存储迁移、整机克隆或者大文件拷贝时网络在某个吞吐阈值附近突然瘫痪Ping 不通、虚拟交换机上的流量全部卡住重启管理网络没用只能重启物理机。这类断流最像驱动在处理高并发时内部卡死而不是单纯的链路断开。场景三长时间空闲后第一包延迟暴增。网卡链路看起来一直 Up但隔了一段时间没流量后再发起访问就会感到明显的延迟要过几秒才恢复。这个现象在螃蟹卡上特别典型基本可以先怀疑节能模式。2.2 按概率给断流原因排个序做排障最忌讳没有方向就乱试。根据我在多台螃蟹卡 ESXi 主机上的处理经验断流根因的出现频率大概是这样可能原因概率倾向典型表现驱动版本与 8.0 内核不匹配高装好后偶发断流重启后短暂恢复网卡节能/EEE/ASPM 触发中高空闲后第一包卡顿大流量时恢复慢速率协商矛盾中固定双工后出现周期性丢包驱动中断/卸载机制冲突中低高吞吐下假死日志出现超时关键字先说驱动版本。社区驱动不是官方持续维护的产品每个版本针对的 ESXi 内核版本都不一样。如果你的包是给 7.0 或更早版本编译的在 8.0 上可能能加载但内部函数接口已经变了驱动在某个边界条件下会自己挂掉。再说节能。螃蟹卡一直有“绿色以太网”的通病包括 EEE 节能以太网和 PCIe ASPM 链路电源管理。这类机制会故意把链路从正常状态调节到低功耗状态遇到 ESXi 这种对驱动要求极高的环境唤醒不及时就会表现为断流。第三是协商问题。很多排障习惯把“固定全双工”当作万能药但千兆链路本身是依赖自动协商的如果交换机端口和网卡对协商结构理解不一致反而会造成大量底层错误丢包更严重。至于中断和卸载机制主要体现在大流量场景。ESXi 默认驱动行为高度依赖硬件队列和中断分配螃蟹卡的队列能力本就一般加上驱动对 TSO/LRO 等卸载特性的支持参差不齐高并发下很容易出现中断风暴最终一发不可收拾。3. 从硬件到内核日志排查链路完整走一遍3.1 第一反应不是改驱动而是判断“假断”和“真断”很多人在遇到断流时第一件事就是换驱动或者卸驱动重装但我的建议是先搞清楚是“真断”还是“假断”。真断是链路物理 down这时候交换机端口灯灭或者 ESXi 里报告的 Link State 是 Down。假断是链路一直是 Up但丢包、延迟暴增、转发卡死。螃蟹卡断流大部分属于假断因为这颗网卡的物理链路本身极少会主动断开问题往往出在驱动内部、节能机制或者虚拟交换机层面。区分方法很简单。用 IPMI 或者本地显示器进 ESXi 维护界面看网卡状态和虚拟交换机 uplink 状态。如果物理链路显示 Up但宿主机 Ping 不通外部那基本就是假断重点查驱动和系统策略。如果是 Down才需要去查线缆、交换机端口和速率协商。3.2 一组命令看清网卡和驱动登录到 ESXi Shell我一般按这套顺序把状态抓全# 看驱动 VIB 是否正常 esxcli software vib list | grep -iE net-|r8168|r8125 # 看内核加载的驱动模块 vmkload_mod -l 2/dev/null | grep -iE r8168|r8125 # 看网卡链路、速率、双工是否正常 esxcfg-nics -l esxcli network nic list esxcli network nic get -n vmnic0 # 看丢包和错误统计 esxcli network nic stats get -n vmnic0重点看esxcli network nic get -n vmnic0输出里的 Link Status、Speed、Duplex 字段。Speed 如果是0或者Unknown说明协商没成功。再看 stats 里的 Tx Dropped、Rx Errors 这类字段如果数字不断增长说明底层链路有问题而不只是驱动“闹脾气”。3.3 日志里的蛛丝马迹日志是排查断流的重头戏。ESXi 里主要看 vmkernel.log 和 hostd.log过滤关键字就可以定位到螃蟹卡驱动是否有异常行为grep -iE r8168|r8125|vmnic0|link down|link up /var/log/vmkernel.log | tail -300你可以重点关注这几个关键字日志关键字大致含义优先处理方向Link down on vmnic0物理链路层断开查线缆、交换机端口、协商r8168: tx timeout驱动发送超时内部卡死升级/回退 VIB关节能queue full/dropped队列积压丢包明显检查负载模型和驱动队列能力hostd大量超时记录管理服务连不上网卡先转移管理流量再处理驱动经验里最有价值的一条是看到tx timeout时别急着只换驱动。你先想一下自己跑大流量的场景是不是特别吃队列缓冲。螃蟹卡早期驱动的设计理念接近消费级系统对虚拟化平台的批量中断处理并不擅长所以高负载下出现发送超时非常典型。3.4 还原一次断流现场我处理过一台 ESXi 8.0 主机装的就是螃蟹卡。故障很经典白天业务流量小一切正常一到晚上备份任务开始虚拟机跑数据量上来之后管理界面就开始失联。重启后能撑几个小时然后又复发。第一次排查我误判为虚拟交换机配置问题结果重做 vSwitch 后问题依旧。后来看 vmkernel.log发现断流前一段大量出现r8168: tx timeout并且有vmnic0: Link Up和Link Down反复切换的痕迹。这说明网卡驱动内部已经在反复重试物理链路其实没有彻底断开。结合该主板自带螃蟹卡的节能选项我先通过 BIOS 关闭 PCIe ASPM再把驱动换成了适配 8.0 的专用 VIB之后才彻底稳定下来。4. 别急着换卡驱动版本、链路参数和系统策略一起调4.1 把社区驱动换成适配 8.0 的版本对于大多数断流问题第一步永远是排查驱动版本。先记录当前 VIBesxcli software vib list | grep -i net如果要升级或替换先进入维护模式再安装新的 VIB 文件。以下以安装一个本地 VIB 路径为例# 进入维护模式 esxcli system maintenanceMode set --enable true # 安装驱动 VIB不同环境文件路径自行替换 esxcli software vib install -v /vmfs/volumes/datastore1/net-r8168-8.050.vib --no-sig-check --maintenance-mode # 重启 reboot如果不是很确定新旧 VIB 之间的依赖关系我的建议是不要在原系统上反复覆盖。有条件的话直接用 Image Builder 重新生成一个包含正确驱动版本的 ISO一次性重装比在线折腾 VIB 要干净很多。这里有个容易被忽略的细节安装 VIB 之后即使命令提示成功也要确认 vmkload 模块加载的是新版本。可以在重启后用vmkload_mod -l再查一次防止系统从缓存区加载了旧的模块副本。不要问我为什么这么强调在线装驱动翻过车的人都懂。4.2 关掉 EEE / Green Ethernet / ASPM让螃蟹卡别“偷懒”螃蟹卡的节能机制是断流的高发来源。ESXi 环境里没有 Windows 设备管理器那种图形化开关所以你要在更底层的地方处理。第一进主板 BIOS找到PCIe ASPM或Active State Power Management选项设成 Disabled。ASPM 是 PCIe 链路层电源管理螃蟹卡在 ASPM 启用状态下会和 ESXi 对 PCIe 设备状态的管理产生冲突浅睡眠进入快唤醒不够快链路就会出现很像是断流的延迟。第二如果主板 BIOS 里有ErP Ready、Deep Sleep、C-States之类选项建议先关闭或者改成非深度节能模式。ESXi 主机不是桌面电脑该让硬件保持清醒的时候就得保持清醒。第三交换机端口如果有EEE或802.3az节能以太网功能也建议把它关掉。这里要特别提醒交换机的 EEE 是双向协商的你只在网卡侧关不一定有效最好的办法是交换机端口和网卡同时关闭。4.3 固定速率和双工但不能病急乱投医有些资料会让你直接固定速率双工。这个操作在百兆环境里通常有效但在千兆环境里要非常谨慎。千兆以太网标准要求链路必须通过自动协商过程来确定主从时钟和 ping 参数。所以如果你强行把 ESXi 网卡设置成固定千兆全双工而交换机端口还在跑自动协商就会产生底层参数不匹配丢包反而更严重。正确的做法是先在交换机端口上明确指定端口速率和双工再在 ESXi 里对应设置。如果确实要手动指定可以这样# 查看当前协商参数 esxcli network nic get -n vmnic0 # 手动指定速率和双工建议在交换机侧也同步配置 esxcli network nic set -n vmnic0 -s 1000 -d full -a true-a true表示继续使用自动协商但速度倾向 1000Mbps。如果 -a 设成 false一定要确保交换机端口也是强制模式否则断流只会变得更糟。这个问题的本质是链路层参数不一致时物理链路虽然建立但底层编码和时钟对齐一直在纠错表现出来就是高延迟和高丢包和断流体验完全一致。4.4 管理流量不要全压在同一张螃蟹卡上如果你的 ESXi 主机只有一张螃蟹卡那管理流量、虚拟机业务流量、存储流量可能全都在同一张网卡上。这种负载叠加会把螃蟹卡驱动的小问题放大成致命问题。我的建议是尽量分离管理流量哪怕只是给 ESXi 再加一块别的网卡当管理口。假设你有一块额外的 vmnic1可以新建一个虚拟交换机把 vmkernel 管理接口迁过去# 新建标准虚拟交换机并挂上稳定网卡 esxcli network vswitch standard add --vswitch-name vSwitchM esxcli network vswitch standard uplink add --vswitch-name vSwitchM --uplink-name vmnic1 # 添加管理端口组和 vmkernel 接口 esxcli network vswitch standard portgroup add --vswitch-name vSwitchM --portgroup-name Mgmt-R esxcli network ip interface add --interface-name vmk1 --portgroup-name Mgmt-R # 分配管理 IP esxcli network ip interface ipv4 set --interface-name vmk1 --ip-type static --ipv4 192.168.10.10 --netmask 255.255.255.0在这个过程里原有的 vmk0 不要立刻删等新管理接口能通之后再把虚拟机配置里的网络路径切过来。这么做的意义是就算螃蟹卡驱动再不稳定ESXi 控制面也不会跟着一起掉线至少你能在断流发生时保持 SSH 存活方便继续排障。4.5 用网卡 Teaming 给断流系上安全带如果你手上恰好有第二块螃蟹卡可以把两张卡做成一个负载均衡组。虽然这不能根治驱动稳定性问题但能显著降低单卡假死对管理面的影响。在 vSwitch0 上把两个 uplink 都加进来然后调整 failover 策略让流量按照来源端口或 IP 哈希分担到两块物理网卡上。当一块卡内部卡死时另一块卡能继续扛着不至于整个管理面瘫掉。但必须清楚螃蟹卡螃蟹卡的组合本质是两个不稳定硬件互相备份只能缓解不能根治。真要追求长期稳定还是得看第五章的方案。5. 真要彻底告别断流直通、替换的最后选择5.1 把螃蟹卡直通给虚拟机让官方驱动救场如果你已经试过驱动升级、BIOS 关闭节能、速率统一断流依然反复那我建议换个思路不要让 ESXi 来管这块螃蟹卡而是把它直通给一台虚拟机让虚拟机系统自己的官方驱动去接管它。这个方案特别适合拿螃蟹卡跑虚拟软路由的场景。做法是先确认设备是否能直通esxcli hardware pci pcipassthru list | grep -i Realtek找到螃蟹卡的 PCI 地址比如 0000:04:00.0然后启用直通esxcli hardware pci pcipassthru set -a -i 0000:04:00.0 reboot重启后在 Web 管理界面中给虚拟机添加 PCI 设备把这块卡挂给虚拟机。虚拟机里的 Windows 或 Linux 会加载螃蟹卡的官方驱动而不是社区移植 VIB。官方驱动在普通系统上的成熟度远高于 ESXi 里的社区驱动断流概率会大幅下降。这里有个重要提醒直通之后ESXi 主机本身就不能再使用这块网卡了管理面也会因此丧失一个可用 uplink。如果你整台主机只有这一张螃蟹卡直通后宿主机会变成“无网络管理”状态只能靠本机显示器或者 IPMI 控制台操作。所以直通方案只推荐给“主机里还有另一张能正常用于管理的网卡”的机器。5.2 什么时候换卡最划算如果直通不允许或者你的螃蟹卡本身就是板载孤卡那我的最终建议就四个字物理换卡。这不是认输而是算账。社区驱动的问题本质是因为厂商不给虚拟化平台做官方支持你再怎么调参数都是在给一个缺乏原生设计的产品打补丁。替换时优先选择 ESXi HCL 里明确的服务器网卡比如常见的 Intel 82574L、I210 系列这类被大量虚拟化环境验证过的卡。这类卡的驱动在 ESXi 中是健全的固件对中断、队列、卸载特性的支持也更完整不会再出现那种“看运气不卡”的状态。投入一块卡的成本能省下反复排障的几十个小时这笔账怎么算都值。如果暂时不想花钱至少在做最终决定前要把“驱动升级 关闭 EEE/ASPM 管理面分离 适当降低负载”这套组合拳打完。我自己处理过的螃蟹卡断流案例里有三分之一靠升级 8.0 对应驱动就解决了三分之一靠关节能和管理面分离解决了剩下三分之一才走到直通和换卡这条路。最后再说一个容易被忽略的小技巧断流发生、SSH 又连不上的时候不要急着拔电重启先用 IPMI 或本地控制台看一眼 vmkernel.log 的尾部日志。很多时候那几十行日志就是判断“网卡驱动问题”还是“物理链路问题”的唯一证据。等日志抓完再决定是重启管理网络还是整机重启排障效率会高很多。