ESXi 6.7 还能用吗？停止支持的风险、升级路径与老主机问题

ESXi 6.7 还能用，但已经没有任何支持：它的通用支持（General Support）在 2022 年 10 月 15 日结束，技术指导期（Technical Guidance）在 2023 年 11 月 15 日结束。主机和虚拟机照常运行，授权也不会失效，失去的是补丁、驱动和厂商支持：此后公开的 ESXi 漏洞，常规渠道不再为 6.7 发布修复，新出的网卡、阵列卡也不会再有 6.7 的驱动。结论很直接：还在跑 ESXi 6.7 的主机，按 8.0 规划升级；7.0 不适合作为终点，它的通用支持也已在 2025 年 10 月 2 日结束；硬件过不了 8.0 门槛的，换硬件或者迁到其他虚拟化平台。文末另外解答老主机上两个常见问题：启动停在 ssh，以及混用不同代 CPU 时 EVC 怎么设。

ESXi 6.7 的支持时间线

时间	事件	对运维的影响
2018 年 4 月	ESXi 6.7 发布	—
2019 年 8 月	6.7 Update 3 发布，是 6.7 的最后一个 Update	之后只有补丁版本，不再增加新功能和新硬件支持
2021 年 11 月 15 日	原定的通用支持结束日，后来与 6.5 一起延期	—
2022 年 10 月 15 日	通用支持结束	不再发布补丁和安全修复
2023 年 11 月 15 日	技术指导期结束	官方不再提供任何形式的支持
2025 年 10 月 2 日	ESXi 7.0 通用支持结束	从 6.7 升到 7.0，同样拿不到新补丁
2027 年 10 月 11 日	ESXi 8.0 计划结束通用支持	现阶段升级的合理目标

以上日期按 Broadcom（原 VMware）公布的产品生命周期整理，以官方生命周期页面为准。主机多的环境，先用 PowerCLI 把版本拉一遍，弄清还有多少台 6.7：

Connect-VIServer vcenter.example.internal
Get-VMHost | Sort-Object Version | Select-Object Name, Version, Build, Model, ProcessorType

单台主机在 ESXi Shell 里执行 esxcli system version get，看 Version、Update 和 Build 三行。

继续运行 6.7 有哪些风险，怎么临时加固

风险	具体表现	能否缓解
新漏洞没有补丁	2022 年 10 月以后公开的 ESXi 漏洞，安全公告一般不再给出 6.7 的修复版本，漏洞扫描报告里的高危项会一直留着	只能靠网络隔离减少暴露面，无法消除
已有的补丁没打	2023 年 2 月的 ESXiArgs 勒索事件，利用的是 OpenSLP 漏洞 CVE-2021-21974，补丁 2021 年就已发布，中招的多是管理口暴露在公网、长期没打补丁的主机	升到 6.7 的最后一个补丁版本，关闭 SLP
硬件与备件	新型号的网卡、阵列卡、NVMe 盘不会再有 6.7 的驱动；老配件停产后买到的替换件可能是新型号，装上识别不了	囤同型号备件只能拖延
客户机系统	6.7 之后发布的操作系统不会进入它的客户机支持列表；虚拟机硬件版本最高到 15	新系统可能装得上，但出了问题没有依据可查
周边软件	备份、监控、存储插件的新版本陆续不再支持 6.x，只能停在旧版本，而旧版本自己也不再更新	无
故障无处求助	不能再向厂商提交支持请求	无

对 IDC 来说还多一层风险：一台 ESXi 上跑着多个客户的虚拟机，宿主机被攻破，影响的是这台机器上所有客户的数据。

暂时不能升级：先做这五项加固

采购、授权或业务窗口的原因暂时升不了，至少把暴露面压到最小：

1. 升到 6.7 的最后一个补丁版本。 停止支持前发布的补丁仍然有效，核对当前构建号和 6.7 最后发布的补丁，差几个就补几个。离线包能否下载，取决于你的 Broadcom 账号是否有对应的授权。
2. 管理口只放在管理网，并在 ESXi 防火墙上限定来源。 443、902、22、427 都不应对公网开放。ESXi 自带的防火墙可以按规则集限制来源，以 SSH 为例：

esxcli network firewall ruleset list                      # 所有规则集及是否启用
esxcli network firewall ruleset allowedip list            # 每个规则集允许的来源
esxcli network firewall ruleset set --ruleset-id=sshServer --allowed-all=false
esxcli network firewall ruleset allowedip add --ruleset-id=sshServer --ip-address=10.10.0.0/24

--allowed-all=false 执行后，允许列表之外的地址就无法再建立 SSH 连接，最好在服务器控制台的 ESXi Shell 里操作，或者先确认自己的来源地址在 allowedip add 填的网段里。其他规则集照此处理，个别规则集不允许修改。限制 Web 管理和 vCenter 相关的规则集之前，先把 vCenter 的地址加进允许列表，否则主机会和 vCenter 失联。

3. 关闭 SLP 服务。 不用 CIM 的 SLP 服务发现，就把它停掉，这是 ESXiArgs 事件后 VMware 给出的临时措施：

/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd off
chkconfig --list | grep slpd        # 显示 slpd off 表示开机不再启动

4. SSH 和 ESXi Shell 用完就关。 排查结束后执行 vim-cmd hostsvc/stop_ssh、vim-cmd hostsvc/disable_ssh，ESXi Shell 对应 stop_esx_shell、disable_esx_shell。由 vCenter 管理的主机可以开启锁定模式（Lockdown Mode），正常锁定模式下只能经 vCenter 或 DCUI 管理。
5. 备份放到宿主机之外。 勒索软件加密的是数据存储里的虚拟机文件，备份如果也在同一套存储上、或者备份服务器和 ESXi 共用一套管理员密码，会被一起加密。至少保留一份离线或不可改写的副本。

这些措施只能降低风险，不能替代升级。

6.7 升级路径：能直接升到哪个版本

目标	能否从 6.7 直接升级	前提	适用情况
7.0	可以	vCenter 先升到 7.0 或更新；网卡、存储控制器都有原生驱动	不建议作为终点：7.0 已结束通用支持，升上去只换来更新的驱动和客户机支持
8.0	以 Broadcom 的 ESXi 8.0 升级文档和互操作性矩阵为准，核对你的 6.7 构建号是否在支持的升级来源里；不能直接升的，先升 7.0 再升 8.0	vCenter 先升到 8.0；CPU、驱动过 8.0 的门槛；准备 8.x 授权	硬件达标的主机首选
9.x	不能直接升级，要先到 8.0	新硬件、新订阅	新采购的服务器另建集群
新硬件装 8.0，迁移虚拟机	不升级旧主机	新旧主机能由同一个 vCenter 管理时可以在线迁移，CPU 代际不同要用 EVC，见最后一节；不能时关机后复制虚拟机文件到新主机重新注册	旧硬件过不了门槛
迁到其他平台	—	例如 Proxmox VE 8.2 起自带 ESXi 虚拟机导入向导；也可以用 qemu-img convert -f vmdk -O qcow2 转换磁盘；Windows 虚拟机先装好 virtio 驱动再改磁盘总线，否则会蓝屏无法启动	不再续订 VMware

按 8.0 升级时的顺序：

1. 清点每台主机的版本、CPU 和驱动。 命令见下一节，结果填进一张表，逐台标出能升、要换卡、要换机。
2. 查兼容性指南。 在 Broadcom Compatibility Guide 里分别查整机型号、CPU 系列、网卡和阵列卡在 8.0 下是否列出，任何一项不在都不要硬升。
3. 先升 vCenter。 vCenter 的版本不能低于它管理的主机。Windows 版 vCenter 6.7 不能原地升级：7.0 起只有设备版（vCSA），要用安装程序的迁移（Migrate）功能转换过去，能一步迁到哪个版本以升级文档为准。vCenter 8.0 能否管理尚未升级的 6.7 主机，同样以互操作性矩阵为准；不能的话，按“vCenter 升 7.0、主机升 7.0、vCenter 升 8.0、主机升 8.0”分步走，每一步都在 7.0 和 8.0 各自的支持范围内。
4. 每台主机先演练。 用离线包执行 esxcli software profile update ... --dry-run，重点看输出里的 VIBs Removed：被移除的如果是网卡或阵列卡驱动，正式升级后这张卡就会消失。
5. 逐台升级。 进入维护模式、迁走虚拟机、升级、重启、检查网卡和数据存储，确认无误再做下一台；升级后分配 8.x 授权。
6. 收尾。 升级 VMware Tools；虚拟机硬件版本按需升级，不是必须。6.7 时期建的 VMFS5 数据存储在 8.0 上仍能挂载使用，但不能原地升级成 VMFS6，要新建 VMFS6 数据存储，再用存储迁移把虚拟机搬过去。

硬件门槛：6.7、7.0、8.0 对照

项目	6.7	7.0	8.0
最低内存	4 GB	4 GB，建议 8 GB 以上	8 GB，运行虚拟机建议 12 GB 以上
启动设备	U 盘、SD 卡都可以，容量要求很低	新的分区布局，建议 32 GB 以上的本地持久存储；7.0 U3 起不再推荐只用 U 盘或 SD 卡启动	至少 32 GB；U 盘、SD 卡作为唯一启动设备已被弃用
设备驱动	原生驱动和旧式 vmklinux 驱动都能用	只支持原生驱动	只支持原生驱动
TPM	支持 1.2 和 2.0	支持 1.2 和 2.0	不再支持 1.2
引导方式	传统 BIOS、UEFI	传统 BIOS、UEFI	传统 BIOS 已被列为弃用，新装用 UEFI
虚拟机硬件版本上限	15（6.7 U2 起）	19（7.0 U2 起）	21（8.0 U2 起）

6.7 主机最常卡在两处：CPU 代际和 vmklinux 驱动。

CPU。 下表是常见至强代际的大致情况，具体型号以 Broadcom 知识库 CPU Support Deprecation and Discontinuation In vSphere Releases 的最新表格为准：

处理器	常见机型	7.0	8.0
至强 5600 系列（Westmere）及更早	Dell R610、R710，HPE G7	不支持	不支持
至强 E5 v1（Sandy Bridge-EP）	Dell R620、R720，HPE Gen8	能装，提示将来可能不支持	不支持
至强 E5 v2（Ivy Bridge-EP）	Dell R620、R720，HPE Gen8	支持	能装，提示将来可能不支持
至强 E5 v3、v4（Haswell、Broadwell）	Dell R630、R730，HPE Gen9	支持	能装，较老的代际可能出现同样的提示
至强可扩展处理器、AMD EPYC	Dell R640、R740，HPE Gen10 及更新	支持	支持

驱动。 7.0 起删除了 vmklinux 兼容层，6.7 上靠旧式驱动工作的网卡和阵列卡，升级后会直接消失。先看每张卡用的是什么驱动：

esxcli hardware cpu list | grep Brand | head -n 1   # CPU 型号
esxcli network nic list                       # 看 Driver 一列
esxcli storage core adapter list              # 看 Driver 一列

旧式驱动名	对应的原生驱动	常见设备类型
igb	igbn	Intel 千兆网卡，如 I350
ixgbe	ixgben	Intel 万兆网卡，如 82599、X540
tg3	ntg3	Broadcom BCM57xx 千兆网卡，服务器板载常见
bnx2x	qfle3	QLogic、Broadcom 万兆网卡，如 57810
megaraid_sas	lsi_mr3	LSI、Broadcom MegaRAID 阵列卡
mpt2sas、mpt3sas	lsi_msgpt2、lsi_msgpt3	LSI SAS HBA
hpsa	nhpsa	HPE Smart Array

Driver 列显示的是左列的名字，说明这张卡在用旧式驱动。有对应的原生驱动，不等于你这张卡的具体型号被它支持，老型号常常不在原生驱动的支持列表里，最终以兼容性指南中 8.0 对该设备列出的驱动为准。

ESXi 6.7 主机启动停留在 ssh 怎么办

ESXi 启动时，进度条下方会滚动显示正在加载的模块和服务名称。画面长时间停在 ssh 这类字样上，只能说明启动卡在这一带，SSH 服务本身很少是原因；常见的是存储超时、启动介质损坏这类问题，屏幕上看不出来，要看日志才能确定。按下面的顺序排查：

1. 先别急着断电。 存储路径超时会让启动拖很长时间，这期间强制重启只会从头再等一遍。同时 ping 一下管理 IP，试着打开 https://管理IP/ui，确认主机是不是其实已经起来了。
2. 看实时日志。 在服务器控制台按 Alt+F12，切换到 VMkernel 日志的实时输出，看最后几十行在报什么；启动完成后按 Alt+F2 回到 DCUI。按了没有切换画面，就等主机起来后查看 /var/log/vmkernel.log。机房里的服务器通过 BMC 远程控制台发送这组按键即可。
3. 对照日志判断原因：

日志里的线索	可能原因	处理
反复出现 iSCSI 登录失败、NFS 挂载超时	外部存储或存储网络不可达，主机在逐个等待超时	先恢复存储网络；存储确实已下线的，等超时走完主机一般能起来，之后移除失效的目标
大量针对某几个 LUN 的预留冲突（reservation conflict）	虚拟机用 RDM 磁盘组建了 Windows 故障转移集群，这些 LUN 没有标记为长期预留	启动完成后，在每台能看到这些 LUN 的主机上设置 perennially reserved，命令见下方
启动设备报读写错误或超时，设备名多为 vmhba32 一类的 U 盘或 SD 卡	6.7 时期常用的 U 盘、SD 卡启动介质老化损坏	换启动介质重装并保留数据存储；顺手把启动盘换成本地 SSD 或 M.2，为升级 8.0 做准备
日志停止滚动，或出现硬件错误	阵列卡、内存、硬盘故障	查 BMC 的系统事件日志（SEL）和阵列卡状态

esxcli storage core device list | grep -i -E '^naa|Display Name'    # 找到集群磁盘的设备 ID
esxcli storage core device setconfig -d naa.600601601e203a00b4c5d6e7f8091a2b --perennially-reserved=true
esxcli storage core device list -d naa.600601601e203a00b4c5d6e7f8091a2b | grep -i perennially

设备 ID 换成实际值，每个集群磁盘都要设置。如果是打完补丁后第一次启动就卡住，在启动画面出现时按 Shift+R 进入恢复模式，可以切回补丁前的版本，先让业务恢复，再查原因。

混用不同代 CPU：EVC 与 Per-VM EVC 怎么设

同一个集群里放了不同代的 CPU，例如 E5 v2 的老主机和至强可扩展处理器的新主机，虚拟机在它们之间在线迁移时会报 CPU 不兼容。原因是虚拟机开机时看到了新 CPU 的指令集（如 AVX2），迁到不支持这些指令的老主机上就无法继续运行。EVC（增强型 vMotion 兼容性）的作用，是把所有主机对虚拟机呈现的 CPU 特性统一降到某一代的水平。它要求 vCenter，集群里的 CPU 必须是同一厂商，Intel 和 AMD 不能混用。

集群 EVC。 在 vSphere Client 里选中集群，进入“配置 → VMware EVC → 编辑”，模式选集群里最老那一代 CPU 对应的基线，比如最老的是 E5 v2，就选 Intel Ivy Bridge Generation。对话框会逐台检查主机是否兼容。注意两点：

• 已经在运行的虚拟机，如果用到了高于新基线的特性，开启 EVC 前要先关机；
• 以后退役了老主机、把 EVC 调高，正在运行的虚拟机要完全关机再开机才会用上新特性，在操作系统里重启不算。

Per-VM EVC（6.7 新增）。 6.7 起可以给单台虚拟机设置 EVC 模式，设置保存在虚拟机自身，跟着它跨集群、跨 vCenter 迁移，适合“老集群里的虚拟机要迁到新的 8.0 集群，又不想动整个集群的 EVC”这种过渡场景。条件和限制：

项目	要求
虚拟机硬件版本	14 或更高，即 6.7 及之后创建或升级过的虚拟机
修改时机	虚拟机必须关机
设置位置	选中虚拟机，“配置 → VMware EVC → 编辑”
与集群 EVC 的关系	虚拟机位于开启了 EVC 的集群时，它的模式不能高于集群的模式
能开机的主机	只能在 CPU 支持该模式的主机上开机和迁入

设完以后，可以在 Linux 虚拟机里确认基线是否生效：

grep -o -w -E 'avx2|avx512f' /proc/cpuinfo | sort -u

基线设为 Ivy Bridge 时这条命令没有输出，因为 Ivy Bridge 还没有 AVX2。反过来也要权衡：EVC 基线定得太低，数据库、压缩、加解密这类用得上新指令的业务会损失性能，所以混用只适合迁移过渡期，老主机退役后及时把基线调高。

在机房里怎么落地

升级 6.7 的工作量主要在清点和现场操作。清点阶段，要把每台宿主机的型号、CPU 和网卡、阵列卡对上号。在 机柜与资产 里，每台服务器的 CPU、内存、硬盘配置都记在台账上，人工录入的配置和下发脚本自动采集的结果同时保留，对照着就能整理出哪些机器还是 E5 v1、v2 这一代；换下来、换上去的启动盘、硬盘等部件按批次入库，型号和去向都有记录。操作阶段，挂载 8.0 的 ISO、看启动卡在哪一步、发送 Shift+R 这类按键，都可以在 IPMI 远程管理 的浏览器控制台里完成，不必为每台主机跑一趟机房。