1. 升级迁移全景与目标定义
vSphere 旧版本升级迁移，本质上不是“把 ESXi 装高一个版本”这么简单，而是一次涉及计算、存储、网络、虚拟化平台管理层与业务连续性的系统性变更。以 5.5、6.0、6.5 这三个典型旧版本为例，它们分别面临不同的处境：5.5 已完全停止通用支持，6.0 与 6.5 也已进入终止支持或仅限延长支持阶段，硬件兼容性、安全补丁、vCenter 单点登录与证书体系、外部 PSC 架构、VMware Tools 与虚拟机硬件版本等，都会成为升级路径上的约束。因此，在动手之前，必须先建立“全景视角”：明确为什么要升、能升到哪里、哪些东西不能动、怎样算成功。
一、典型驱动：为什么必须升级
升级的驱动力通常来自四个方向。第一是安全与合规：旧版本不再获得安全补丁，一旦出现类似 OpenSLP、vCenter Server 漏洞，修复只能靠升级或打补丁，而 5.5 已无补丁可打。第二是硬件与生态兼容：新一代服务器 CPU、NVMe 设备、25GbE 网卡、vSAN 新版本、备份软件新版本，往往只支持 6.7 或 7.0 以上，旧平台无法识别或无法获得厂商支持。第三是功能与运维效率：6.5 之后 vCenter 采用基于服务的架构，6.7 引入 vCenter Server Appliance 的增强链接模式，7.0 强化了生命周期管理（vLCM）与原生密钥提供程序，这些能力直接影响日常运维成本。第四是业务连续性风险：旧版本一旦出现故障，备件、驱动、第三方集成都可能无法及时获得，故障恢复时间不可控。
二、约束条件：哪些因素决定路径
升级路径不是自由选择的，而是被一组硬约束“框定”的。最关键的约束包括：
- 源版本与目标版本：5.5 不能直接升到 7.0，通常需要先升到 6.0 或 6.5，再继续向上；6.0 到 6.7 也有明确的升级顺序。
- vCenter 架构：5.5/6.0 常见 Windows 版 vCenter + 外部 PSC，6.5 之后推荐 VCSA，6.7 起外部 PSC 逐步被弃用。架构不同，迁移方式（升级、迁移、新建）完全不同。
- 硬件兼容性：目标 ESXi 版本是否在服务器 HCL 中，BIOS/固件、网卡、HBA、存储阵列是否支持。
- 虚拟机兼容性：虚拟机硬件版本、VMware Tools 版本、EVC 基线、GPU 直通、裸设备映射（RDM）等。
- 网络与存储：分布式交换机版本、NSX、iSCSI/FC/NFS 配置、vSAN 磁盘格式。
- 业务窗口：可接受的停机时间、回退窗口、变更审批与备份策略。
这些约束共同决定了你是走“原地升级”“迁移到新平台”还是“新建后逐步搬迁”。
三、成功标准：怎样才算升级成功
成功标准必须在开始前定义，而不是事后补。建议从五个维度衡量：
- 平台可用性：vCenter、ESXi、集群、HA/DRS 全部正常，无告警。
- 业务连续性：关键虚拟机开机、网络连通、存储访问、应用响应时间在可接受范围内。
- 数据完整性：虚拟机文件、快照、备份链、复制关系未损坏。
- 可管理性：备份、监控、日志、权限、证书、SSO 全部恢复并验证。
- 可回退性：在约定窗口内，若出现不可接受故障，能按预案回退到原状态。
四、端到端流程框架
从评估到切换，整个升级迁移可以抽象为一条“评估—设计—准备—实施—验证—切换—收尾”的主链路。下面这张图把关键阶段、输入输出与判断点放在一起，便于在项目启动时统一认知。
五、从评估到切换的关键动作
在评估阶段，建议先做一次“版本—硬件—虚拟机”三张清单。版本清单记录 vCenter 与 ESXi 的精确 build 号、是否外部 PSC、SSO 域、证书类型；硬件清单记录服务器型号、CPU、内存、网卡、HBA、存储阵列与固件版本；虚拟机清单记录虚拟机硬件版本、VMware Tools 版本、EVC 基线、快照数量、RDM/GPU 等特殊配置。把这三张清单与 VMware 兼容性矩阵比对，就能快速识别“必须换硬件”“必须改架构”“必须重建”的对象。
在设计阶段，核心是选择路径。若 vCenter 是 Windows 版且版本较旧，通常建议新建 VCSA 并迁移数据，而不是原地升级；若 ESXi 主机硬件支持目标版本，可采用滚动升级，逐台进入维护模式，利用 DRS 迁移虚拟机；若硬件不支持，则需先扩容新集群，再通过 vMotion 或冷迁移搬迁。回退方案必须与升级方案同时设计，例如保留旧 vCenter 虚拟机快照、保留旧 ESXi 安装盘、保留原分布式交换机配置备份。
在准备阶段，备份是第一优先级。vCenter 需做文件级与数据库级备份，ESXi 需备份主机配置，分布式交换机需导出配置，虚拟机需确认备份链完整。证书与 SSO 是旧版本升级中最容易出问题的环节，5.5/6.0 常见外部 PSC 与证书过期问题，必须在升级前修复，否则升级过程中会直接失败。固件与驱动也应在准备阶段完成，避免实施阶段因硬件不识别而中断。
实施阶段要控制节奏。vCenter 先升级或迁移，再逐台升级 ESXi，最后处理虚拟机硬件版本与 VMware Tools。每台主机升级后，先检查 HA/DRS 状态、网络连通、存储挂载，再继续下一台。虚拟机硬件升级应分批进行，避免一次性全部升级导致回退困难。验证阶段要覆盖平台层与业务层：平台层检查 vCenter 服务、集群告警、证书有效期、备份任务；业务层抽查关键虚拟机开机、网络、存储、应用响应。切换阶段调整 DNS、证书、入口负载均衡，并保留观察窗口。收尾阶段下线旧平台、更新文档、复盘问题。
总体来看，升级迁移的全景可以概括为：以业务连续性为目标，以兼容性为边界，以评估和设计为起点，以准备和验证为保障，以切换和收尾为闭环。理解这条主线，后续每一章的具体操作才有统一的判断依据。