简介：VMware-Re-Driver 1.101.01 是面向 ESXi 管理员的一款 Realtek 网卡驱动离线组件包，基于 VMware Fling 渠道发布，解决 ESXi 8.0 Update 3 及 9.x 以上版本无法识别 RTL8111、RTL8125、RTL8126、RTL8127 等 PCIe 网卡的问题，覆盖千兆、2.5G、5G 与万兆速率，适合在安装 ESXi 后发现网卡不被支持的场景下快速补齐驱动。该驱动由 VMware 工程师 Wenchao 开发，并非 Realtek 官方出品，面向需要维护 vSphere 宿主机网络、制作离线安装镜像或排查网卡识别异常的运维人员。整个资源包约 205KB、共 4 个文件，以 1 个 VIB 驱动组件为核心，配合 1 个 zip 元数据压缩包和 2 个 xml 索引/校验文件，结构清晰，可直接离线导入 ESXi 8.0U3/9.x 环境，再通过软件组件管理方式部署；元数据压缩包与索引文件可用于校验驱动版本和供应商标识，便于自动化集成。目前已有 442 人学习/下载，对使用 RTL8125 2.5GbE 等 Realtek 网卡的 ESXi 用户有直接参考价值。包内 bootbank VIB 与元数据、索引文件完整记录了驱动的版本号、依赖关系和校验信息，配合 esxcli 组件命令即可完成安装、查询与卸载，省去自行编译驱动和排查兼容性的繁琐工作，可明显提升网卡适配效率、降低排错成本。
1. ESXi 驱动包不是装上就能收工：版本串就是兼容边界
第一次在一台跑着 ESXi 8.0 的存量机器上做驱动替换时，我差点因为一个版本串栽跟头。这个 Re-Driver 离线包的文件名里写着1.101.01-5vmw.800.1.0.20613240。乍一看是“驱动版本号”，但后半截5vmw.800.1.0.20613240其实对应的是 ESXi 8.0 的某个基线补丁版本，而不是驱动自己的版本。ESXi 的驱动包从来不是“解压后点上一步”就能装的东西。它要过签名、过接受级别、过依赖链、过维护模式。哪一步没对齐，esxcli software vib install就会报一个看起来像玄学的错误。这篇文章我把拆包、安装、验证和回退的完整过程拆开讲，同时标出哪些坑是每次都会踩的，适合刚接手存量 ESXi 环境、又必须补某个设备驱动的工程师。
2. 拆包看货：先别装，版本串和依赖会比名字更诚实
2.1 版本号里藏着哪一层兼容边界
文件名里VMware-Re-Driver-1.101.01-5vmw.800.1.0.20613240这段，拆开看是三段信息：
1.101.01：驱动模块自身的厂商版本。你要追踪固件/驱动功能变化时看这个。5vmw：表示这个 VIB 的打包角色是 VMware 侧的 vmkernel 模块版本序列，而不是原厂直接发布的驱动。800.1.0.20613240：800指 ESXi 8.0 分支，1.0是基线构建分支里的子版本，20613240是构建号。
也就是说，这个包做出来的时候，是围绕构建号20613240对应的 ESXi 8.0 基线来验证的。如果你机器上是8.0.0的早期构建（比如20502297之类），驱动大概率能装，但“能装”和“被验证过”是两回事。我在日常操作中默认一条规则：构建号差得越远，装之前越要把第 2.2 节里说的依赖检查走一遍。不要只看驱动版本号大或小，ESXi 对 vmkernel 模块的依赖比对驱动版本更敏感。
2.2 解包后先看三个文件，比信任作者更重要
拿到离线包（实际是个 zip 或 vib 文件）后，我第一件事不是在主机上安装，而是复制到本地临时目录拆开看。
mkdir -p /tmp/re-driver-check && cd /tmp/re-driver-check unzip -l /vmfs/volumes/datastore1/patch/re-driver-1.101.01-5vmw.800.1.0.20613240.zip | head -40这个命令只做列目录，不实际解压，目的是先确认包内是不是标准的offline bundle目录结构：顶层有metadata.zip，里面是VIB明细。你还会看到类似payload的部分，那才是驱动实际文件。
我的习惯是真正解开一次：
unzip -q re-driver-1.101.01-5vmw.800.1.0.20613240.zip -d bundle find bundle -maxdepth 3 -type f | sort | head -80重点看三个文件位置。
metadata.zip里的 VIB 描述文件：写明了驱动名、版本、依赖、厂商。- 解包 VIB 之后的
/etc/vmk*或模块.ko文件：确认是不是你设备对应的那个型号。 - 如果包里有
README或release notes形式的文本：往往写得比命令行输出更诚实。
检查完毕，再用脚本把依赖和接受级别一次抓出来：
import zipfile, re with zipfile.ZipFile("bundle/metadata.zip") as mz: content = mz.read("metadata.xml").decode("utf-8", errors="ignore") for tag in ["name", "vendor", "version", "acceptance-level"]: m = re.search(r"<%s>(.*?)</%s>" % (tag, tag), content) if m: print(f"{tag}: {m.group(1)}")这段脚本的意图是把 VIB 的核心属性先打印出来。name会在后面的 install/remove 命令里反复用到，一旦你复制错名字，esxcli会直接告诉你找不到这个 VIB。acceptance-level则是这样一个东西：它低了不行，高了又装不进去，后面第 5 章会专门讲。
2.3 验证签名、接受级别和依赖链
解包后我不会立刻装。ESXi 主机上原生离线包通常有签名，但如果这个 Re-Driver 是个人或第三方重新打包的，签名状态往往是Signed-Unknown甚至会显示--。没关系，关键是接受级别。
查看主机接受级别：
esxcli software acceptance get常见返回值是PartnerSupported或CommunitySupported。如果你主机当前是PartnerSupported，而新 VIB 的接受级别是CommunitySupported，安装会直接失败。这时要改：
esxcli software acceptance set --level=CommunitySupported这个命令把主机接受级别降级到社区支持级别。注意：这是全局动作，改完后这台主机之后也能接任何社区级别驱动，所以对生产环境要谨慎。改完再跑一次安装的--dry-run：
esxcli software vib install -d /vmfs/volumes/datastore1/patch/re-driver-1.101.01-5vmw.800.1.0.20613240.zip --dry-run--dry-run是所有人都应该先跑的一步。它会告诉你依赖是否满足、是否要动 libs 或现有模块、会不会影响当前运行中的 VM。我看到The following VIBs will be installed这一类输出时，才会决定继续。
3. 三种安装路径：离线包、VIB 直装、镜像集成
3.1 离线包方式：存量主机最稳的选择
对已有生产数据的 ESXi 主机，我优先选离线包方式，前提是包本身是 zip 形态。命令很直接：
esxcli software vib install -d /vmfs/volumes/datastore1/patch/re-driver-1.101.01-5vmw.800.1.0.20613240.zip \ --maintenance-mode --no-sig-check --force说下参数各自的含义。-d表示 d 来自 depot/离线包，specifies 包内可能包含多个 VIB。单独装一个 VIB 时用-v，但这里的 Re-Driver 文件在压缩包里，用-d更合理。--maintenance-mode的含义是我手动确认主机已经进入维护模式并通知了集群，esxcli 不再提醒。--no-sig-check是针对部分第三方重打签名的包；如果包签名完整，建议去掉这个参数。--force这个参数我放置的很保守：只有当你确认包内某模块会和已有模块重名时才加。加了 force 等于告诉 esxcli “出问题我自己负责”，不能不加判断乱用。
跑完后立即检查返回值，返回 0 不代表模块已经生效，只代表 VIB 写进了 bootbank，等维护窗口的 reboot 才会真正加载。
3.2 VIB 直装方式：单包要快就装它
如果你拿到的不是 zip，而是单独的.vib文件，那用-v：
esxcli software vib install -v /tmp/re-driver-1.101.01.vib \ --maintenance-mode --no-sig-check-v的语义是“指定一个具体的 vib”，比-d更精确。好处是安装目标明确，出错信息通常也能直接指到某个 VIB。
但要注意：这个命令一样不会实时加载模块。它把 VIB 持久化到系统盘的 bootbank，然后告诉你 “请重启主机” 或 “需要重新引导”。所以在装完 VIB 到重启之间，主机会处于一个很微妙的中间状态：包已经落盘，但老驱动还在跑。如果这时候主机因为其他原因宕机重启，新驱动会生效，而老驱动的配置状态可能对不上，因此我一般会在装完和重启之间顺手抓一份当前esxcli software vib list和vSphere Web Client里的配置快照。
3.3 镜像集成：换机/新装时省一次折腾
如果你准备换一台机器或重装：那不必先装 ESXi 再装驱动，可以把 Re-Driver 打进安装镜像。常见做法是把离线 zip 解包到镜像配置文件里，再将 profile 导出为可引导镜像。命令行工具链的做法大致是这样：
esxcli software sources vib list --depot=/path/re-driver-1.101.01-5vmw.800.1.0.20613240.zip先确认包里 VIB 的名字。如果能看到re-driver这个名称，把它加到一个新 profile：
esxcli software profile create --help辅助构建镜像时，也可以在 esxcli 之外手动改boot.cfg增加模块，但那个操作对新手风险大。我更推崇 profile 方式。一个 profile 可以看作“安装脚本 + 驱动包集合”，把 Re-Driver 放进去，后续在任何同构建号主机上装机都会自动带上。镜像集成的最大收益不是省那一两个命令，而是避免“装完系统发现网卡不识别、只能又靠本地控制台上传驱动包”的尴尬循环。
4. 装完别信屏幕：验证驱动活没活
4.1 从 VIB 列表确认安装状态
重启之后先做的事不是开 Web 界面，而是登录命令行，确认 VIB 状态。
esxcli software vib list | grep -i re-driver输出里能看到Name,Version,Vendor,Install Date和Status。Status 正常情况下是Installed。如果显示Pending Reboot，说明你重启没彻底，或者 bootbank 写入有问题。如果根本没有这一行，去设备引导日志里找原因，大概率是 VIB 安装时被回滚了。
我还会跑一次：
esxcli software vib get --vibname=re-driver这会给出更细的信息，Version要跟在离线包里看到的一致。如果显示的是你没预期到的旧版本，说明包内有过重复 VIB，或者你之前已经装了一个名字相近但版本不同的东西。
4.2 在 dmesg 和模块列表里找驱动真的跑起来
VIB 列表只能证明“装上了”，不能证明“加载了”。我一般在重启后确认模块状态：
esxcli system module list | grep -i re模块列表里会有一列显示当前是否加载。如果状态是 0，表示模块已加载。某些驱动模块还会在启动阶段注册 PCI 设备时打印一行日志，用 dmesg 过滤更快：
dmesg | grep -i re-driver | tail -20在没有日志输出的云环境里，我会用设备侧的角度验证。如果这是一个网卡或存储类驱动，重点看lspci里对应设备是否带上了驱动信息，以及链路是否亮。如果你是存储控制器驱动，可以对比看esxcli storage core device list。
这一步的价值在于：有些第三方重打包驱动会“伪成功”——模块加载了，却未广播给上层依赖服务。结果就是主机不宕机、群集也标记正常，但对应 PCIe 设备就是没有从lspci的状态里进入可用状态。你说它玄学，其实是验证路径没走完。我的习惯是重启后至少跑一遍第 4.2 节全部三个命令，把输出保存到本地。
4.3 回退的姿势和时机
如果验证失败，马上回退比修复更重要。
esxcli software vib remove -n re-driver --maintenance-mode-n指定 VIB 名，不填版本号，esxcli 会根据当前 bootbank 版本删除。移除命令一旦执行，老驱动也不会自动回来。这里有一个关键点：ESXi 的驱动回退不是“卸了再装旧的”，而是“旧的 VIB 是否还在 bootbank 里可用”。如果你安装新驱动时使用了 force 方式覆盖了旧的同名模块，那么移除新驱动后，旧模块文件可能也被标记为 obsolete，而不是自动恢复。
所以回退的真正后悔药是：装新驱动前先手动备份一下旧 VIB 文件。常见做法是把正在用的包导出为离线 zip：
esxcli software vib get --vibname=re-driver > /tmp/re-driver-old.txt或者直接把/bootbank里对应文件复制到数据存储。这个备份成本很低，却能让你在翻车时可以强制用离线包把旧版本装回来。从那次以后，我每次都会把 “先导出现状，再动手术” 当作默认步骤。
5. 避坑：ESXi 驱动安装的五个真实翻车现场
5.1 报错 “not acceptable”：接受级别没对齐
现象：
Error: The VIB re-driver VIB requires acceptance level CommunitySupported, but the host acceptance level is PartnerSupported原因：主机当前接受级别高于 VIB 的声明级别。很多人会重打包驱动时顺手把 acceptance-level 写成 PartnerSupported，签名又没跟上，结果安装时会报这个错，甚至直接找不到匹配的签名。
解决：确认包可信之后，改主机接受级别，然后重新安装。生产环境要记录变更原因，因为这是全局豁免。改完之后再去esxcli software acceptance get确认一下，免得影响后续其他 VIB。
5.2 挂在维护模式出不来：迁移前的准备没做干净
现象：执行esxcli software vib install -d xxx.zip后，主机长时间停在维护模式，无法正常退出。部分环境还会出现虚拟机的 HA 重新注册反复失败。
原因：安装过程中，esxcli 会把相关 VM 重新迁移或挂起。如果主机上有本地未共享存储的 VM，维护模式无法把这些 VM 迁走，驱动安装流程只能等。少数情况下是 DRS 配置不完整，导致一直有 VM 残留。
解决：进入维护模式前，先确认所有 VM 都有可迁移的共享存储，或在维护窗口直接关机。进入维护模式后跑一下esxcli system maintenanceMode get，看到当前是ENABLED再装驱动。装完确认不会再有影响后esxcli system maintenanceMode set --disable。
5.3 显示已安装但设备不生效：依赖的模块没被加载
现象：VIB 状态正常，模块 list 里能看到 re-driver，但设备还是没有驱动状态，lspci里看不到对应驱动映射。
原因：驱动模块在 vmkernel 层通常依赖另一个模块先加载。如果你的包只更新了主驱动，没更新依赖的 lib 模块或公共模块，加载顺序就会错乱。这一类问题在官方驱动上较少，在重新打包的驱动上很容易出现，因为打包者经常只打一个主干模块，漏掉配套的 lib。
解决：回到第 2.2 节，看 metadata 里的依赖字段，确认包内是否包含所有依赖。如果不包含，先装依赖包再装主包。安装顺序不是万能的，如果两个 VIB 互相依赖，ESXi 会在vib install时就提示冲突，这时不要用 force 硬过，需要先把依赖包拆开解包，看到底哪个版本缺失。
5.4 vib remove 失败：你知道它接下来想删谁吗
现象：
Error: The update cannot be completed since the VIB re-driver depends on VIB xxx原因：你以为自己在卸载 re-driver，但 esxcli 在解析依赖关系时发现还有另一个包正在使用它的模块。这通常发生在存储或网络驱动上，驱动被上层服务直接引用。
解决：先esxcli software vib list | grep -i re看是否有同源的兄弟包。把上层服务对应的包先停掉或移除，再执行 remove。如果依旧失败，用--force强行移除，但必须在生产上确认该设备不会再被使用。移除后及时看 dmesg，避免因为模块悬空带动内核异常。
5.5 重启后回到解放前：bootbank 和模块参数没保存
现象：安装时一切正常，重启后 VIB 状态是Installed，但实际设备又变回未驱动状态，或者模块加载顺序每次都不一样。
原因：常见两个因素。一是安装时用了-v直接装进控制台系统盘，但 U 盘启动环境没写干净，重启后 bootbank 用的是默认镜像。二是驱动带参数，而参数没有写入持久化配置。
解决：先确认系统启动卷是否健康，esxcli software vib list如果能看到 VIB 且状态 OK，那 bootbank 写入成功。如果 VIB 确实在，但模块每次都不加载，检查持久化配置：
esxcli system module parameters list | grep -i re-driver没有输出时，需要把模块参数写进/etc/vmware/esx.conf对应节点。注意这个文件在重启后会被重新生成，最稳妥的做法是重新跑一次esxcli system module parameters set设置参数。从那以后，我只要碰到重启丢配置的主机，都会先看模块参数，实在不行就重启后再补一次参数，再设置一遍，确认 esx.conf 里有残留。
6. 把驱动续到下一次升级：固化检查脚本
6.1 升级前与升级后都要跑的 checklist
升级 ESXi 补丁是最容易丢掉自定义 VIB 的地方。你升级前装好的 re-driver，在基线切换后很可能仍在 rubric 里，但内核模块版本对不上构建号。所以我每次升级前都会备份 VIB 列表：
esxcli software vib list --export > /tmp/vib-export.json esxcli software profile get > /tmp/profile-get.txt升级后第一件事对一下版本，确认 re-driver 是不是真的还匹配当前 profile。如果匹配，什么都不用做；如果不匹配，用旧的离线包重装一次。
6.2 一条命令循环：把补装写成可重复执行的脚本
我常用一个很短的脚本完成“检测缺失 -> 安装 -> 验证”。不是自动化平台，而是把固定动作压缩成一行命令，减少手误。
#!/bin/sh VIB="re-driver" DEPOT="/path/re-driver-1.101.01-5vmw.800.1.0.20613240.zip" esxcli software vib list | grep -q "^$VIB" || \ esxcli software vib install -d "$DEPOT" --maintenance-mode esxcli software vib list | grep "^$VIB"脚本的含义很直白：先检测 VIB 是否已存在，存在则跳过，不存在才安装。因为升级后 VIB 会消失，所以这个脚本天然适合在每次升级后手动执行。我通常把它放在一个数据存储路径下，比如/vmfs/volumes/datastore1/scripts/，避免重装系统时脚本也跟着丢。
脚本里没有加--dry-run，因为这时候你已经知道需要装，刻意模拟没有意义。但它忽略了一个参数：维护模式判断。实际上更严谨的写法是在安装前强制检查维护模式状态。我把这一条留给自己，因为写进脚本后，每次装之前都必须人工盯一眼维护模式，而不是让脚本自动退出，否则会造成 VM 意外迁移。
后来有一次，我就是靠这个脚本快速在集群的另外三台主机上补齐了同版本驱动。从那以后，我每次看到5vmw.800.1.0.20613240这个版本串，都会先问一句：你把这个包做成离线包时，有没有同步保留旧版本文件？再问一句：我这边是不是真的所有主机的构建号都在你说的这个基线上？这两句话能省掉后面一整晚的折腾。希望帮到你。
本文还有配套的精品资源，点击获取
