2. 旧版本环境资产盘点与依赖分析

升级迁移项目失败，十有八九不是败在目标版本的技术细节上，而是败在“不知道自己有什么”。旧版本 vSphere 环境往往经过多年演进：vCenter 从 5.5 升到 6.0 再到 6.7，ESXi 主机型号混杂，存储从本地盘扩展到 FC SAN 又叠加了 NFS，网络从标准交换机逐步引入分布式交换机，还挂着一堆插件和外部系统。资产盘点的目标，就是把这些对象变成一份可核对、可排序、可判断兼容性的清单，并理清它们之间的依赖关系，为后续的升级路径设计提供输入。

一、盘点对象的分层模型

建议按“管理层—计算层—虚拟机层—存储层—网络层—扩展层”六层来组织清单，每一层都有明确的采集字段和依赖方向。依赖关系不是单向的：vCenter 依赖 ESXi 提供计算资源，ESXi 依赖存储和网络才能承载虚拟机，而插件又反向依赖 vCenter 的版本与 API。任何一层版本不匹配，都可能在升级中途卡住。

二、用脚本批量采集版本与硬件数据

手工登录每台主机记录版本，在几十台规模的环境里既慢又容易漏。推荐用 PowerCLI 做一次“只读扫描”，把结果导出为 CSV，作为后续比对的基线。以下示例脚本连接 vCenter 后遍历集群、主机和虚拟机，采集关键字段：

Connect-VIServer -Server vc-old.corp.local -User audit@vsphere.local

# 主机清单：版本、型号、CPU、内存、启动设备
Get-VMHost | Select-Object Name, Version, Build,
  @{N='Model';E={$_.ExtensionData.Hardware.SystemInfo.Model}},
  @{N='CPU_MHz';E={$_.CpuTotalMhz}},
  @{N='MemGB';E={[math]::Round($_.MemoryTotalGB,1)}},
  @{N='Cluster';E={$_.Parent.Name}} |
  Export-Csv .\hosts.csv -NoTypeInformation -Encoding UTF8

# 虚拟机清单：硬件版本、工具版本、快照数
Get-VM | Select-Object Name, PowerState,
  @{N='HW';E={$_.HardwareVersion}},
  @{N='Tools';E={$_.ExtensionData.Guest.ToolsVersionStatus2}},
  @{N='Snapshots';E={(Get-Snapshot -VM $_).Count}},
  @{N='Host';E={$_.VMHost.Name}} |
  Export-Csv .\vms.csv -NoTypeInformation -Encoding UTF8

采集完成后重点看三类异常：一是 Version 字段出现 5.5、6.0、6.5 混布，说明需要分批升级；二是虚拟机 HW 低于 9 的，升级后可能无法使用新特性；三是 Snapshots 大于 0 的虚拟机，快照会拖慢升级期间的存储迁移，必须提前合并。这些判断依据都来自脚本输出，而不是凭印象。

三、兼容性数据的获取与比对

版本清单只是“现状”，兼容性矩阵才是“能不能升”。VMware 官方提供两类关键数据源：产品互操作性矩阵（IOG）用于确认 vCenter、ESXi、vSAN、NSX 之间的版本组合是否受支持；硬件兼容性列表（HCL）用于确认服务器型号、CPU、网卡、HBA、存储阵列在目标版本下是否仍被认证。实操中建议把 hosts.csv 中的 Model 列与 HCL 逐条比对，把 vCenter 与 ESXi 版本组合与 IOG 比对，输出一张“可升级 / 需先换硬件 / 需先升中间版本”的三分类表。

四、依赖关系与外部系统梳理

依赖分析要回答两个问题：谁依赖 vSphere，vSphere 又依赖谁。前者包括备份软件（如 Veeam、NetBackup）通过 vCenter API 或 ESXi 主机直连做备份、监控系统通过 SDK 采集性能、自动化平台通过模板部署虚拟机、目录服务提供 SSO 认证。后者包括 vCenter 依赖的数据库（内置 PostgreSQL 或外部 Oracle/SQL Server）、DNS、NTP、证书颁发机构。升级 vCenter 前，如果外部数据库版本过旧，必须先升级数据库；如果证书是自签且即将过期，要先续期，否则升级后 SSO 可能无法启动。

插件是另一个高频踩坑点。旧环境里常见的插件包括存储阵列插件（VASA Provider）、网络插件（Cisco Nexus 1000V）、备份插件、硬件管理插件（如 Dell OMSA、HPE OneView）。这些插件往往与 vCenter 版本强绑定，且部分已被厂商停止维护。盘点时应记录插件名称、版本、厂商、是否支持目标 vCenter 版本，对不再支持的插件制定“先卸载、后升级、再评估替代方案”的处理顺序。

五、盘点成果的交付形式

盘点最终要形成一份可执行的资产与依赖清单，建议至少包含以下字段，并按“升级批次”分组：

这份清单不是一次性文档，而是升级过程中的“活账本”。每完成一批主机升级，就回填实际版本和遇到的问题，既用于验证盘点准确性，也为后续批次提供经验。盘点做得越细，升级路径就越清晰，临时救火的概率就越低。