3. vCenter清单对象模型
vCenter 的清单（Inventory）不是简单的设备列表，而是一棵有严格父子关系的对象树。理解这棵树，是后续做权限委派、资源分配、告警定位和批量运维的前提。很多“权限明明给了却不生效”“虚拟机找不到在哪台主机上”的问题，根源都在于没有理清对象之间的层级归属。
一、清单对象树的整体结构
vCenter 清单的根是 vCenter Server 本身，其下可以挂载多个数据中心（Datacenter）。数据中心是清单中最大的逻辑容器，它本身不提供计算或存储能力，只负责把清单划分为相互隔离的管理边界。一个数据中心内部，通常同时存在四类并列的层级分支：
- 主机与集群分支：数据中心 → 集群（Cluster）→ 主机（Host）→ 虚拟机（VM）；
- 虚拟机与模板文件夹分支：数据中心 → 虚拟机文件夹（VM Folder）→ 虚拟机/模板；
- 网络分支：数据中心 → 网络文件夹 → 分布式交换机/端口组；
- 存储分支：数据中心 → 存储文件夹 → 数据存储。
本节聚焦前两条分支，即计算资源与虚拟机对象的层级。需要特别注意的是：虚拟机在清单中只有一个“位置”，但它同时被两条路径引用——一条是资源路径（通过集群/资源池体现它消耗谁的 CPU 和内存），另一条是文件夹路径（通过 VM 文件夹体现它在清单树中显示在哪里）。这两条路径相互独立，是理解 vCenter 对象模型最关键的一点。
二、各对象的职责与边界
数据中心是权限与命名空间的分界。跨数据中心的同名对象互不冲突，权限也不会自动继承。实践中建议按“地域+用途”命名，例如 DC-SH-Prod、DC-BJ-DR，避免使用“Datacenter1”这类默认名。
集群是计算资源的聚合单元，提供 HA、DRS、EVC 等能力。集群下可以再建资源池，用于对 CPU 和内存做份额、预留、上限的细分。资源池只影响资源分配，不影响权限继承之外的清单显示位置。集群命名建议体现用途与等级，如 Cluster-Prod-Gold、Cluster-Test。
主机是真正提供 CPU、内存和存储连接的物理节点。主机加入集群后，其资源被集群统一调度。主机命名通常与资产编号或带外管理地址对应，例如 esxi-sh-01.corp.local，便于与 CMDB 对齐。
虚拟机是最终承载业务的对象。它的“资源归属”由所在集群或资源池决定，“清单位置”由所在 VM 文件夹决定。二者可以完全不同：一台 VM 可以显示在 /Prod/Web 文件夹中，同时运行在 Cluster-Prod/RP-Web 资源池下。
文件夹是纯逻辑容器，不消耗资源，只用于组织清单和批量授权。文件夹可以嵌套，但建议层级不超过三层，否则权限排查会变得困难。
三、命名规范建议
命名规范的目标是“看到名字就知道归属和用途”。以下是一套可直接参考的示例规则，实际使用时请结合企业现有 CMDB 编码调整：
| 对象类型 | 命名格式 | 示例 | 说明 |
|---|---|---|---|
| 数据中心 | DC-{站点}-{环境} | DC-SH-Prod | 站点用两位城市码，环境用 Prod/Test/DR |
| 集群 | Cluster-{环境}-{等级} | Cluster-Prod-Gold | 等级体现 SLA 或硬件代次 |
| 资源池 | RP-{业务域} | RP-Web | 与业务系统对应，避免按部门命名 |
| 主机 | esxi-{站点}-{序号}.{域名} | esxi-sh-01.corp.local | 与带外管理、资产编号一致 |
| 虚拟机 | {业务}-{角色}-{序号} | web-nginx-01 | 全小写，避免空格和中文 |
| 文件夹 | /{环境}/{业务域} | /Prod/Web | 与资源池命名保持对应关系 |
#、&、%），这些字符在脚本调用、URL 拼接和日志检索时容易引发转义问题。虚拟机名称建议控制在 15 个字符以内，过长会在 vSphere Client 列表中被截断。四、实操：用 PowerCLI 验证层级与命名
部署完成后，可以用 PowerCLI 快速核对清单结构是否符合规范。以下命令先连接 vCenter，再按层级输出对象路径：
Connect-VIServer -Server vcsa-sh-01.corp.local -User administrator@vsphere.local
# 查看数据中心
Get-Datacenter | Select-Object Name
# 查看集群及其下的主机数量
Get-Cluster | Select-Object Name, @{N='HostCount';E={($_ | Get-VMHost).Count}}
# 查看资源池及其父集群
Get-ResourcePool | Where-Object {$_.Name -ne 'Resources'} |
Select-Object Name, @{N='Cluster';E={$_.Parent.Name}}
# 查看虚拟机的资源路径与文件夹路径
Get-VM web-nginx-01 |
Select-Object Name,
@{N='ResourcePath';E={$_.VMHost.Parent.Name + '/' + $_.ResourcePool.Name}},
@{N='FolderPath';E={$_.Folder.Name}}
执行后应重点核对两点：一是 ResourcePath 是否落在预期的集群和资源池下；二是 FolderPath 是否与业务域文件夹一致。如果两者与规划不符，说明虚拟机在创建或迁移时被放错了位置，需要及时用 Move-VM 调整文件夹归属，或在集群间做迁移。
五、常见误区
- 把文件夹当成资源容器：文件夹不提供 CPU、内存，也不参与 DRS 调度，它只影响清单显示和权限继承。
- 在集群和资源池上重复授权：权限会沿层级向下继承，重复授权容易造成权限叠加，排查时难以判断实际生效来源。
- 用默认名“Resources”承载业务：默认根资源池应保持干净，业务资源池单独创建，便于按业务域做限额和监控。
- 命名中混入环境信息却不统一：有的用 Prod、有的用 PRD、有的用生产，会导致脚本过滤和报表统计失效。
把对象层级和命名规范一次性定好，后续的权限委派、资源监控、批量脚本和故障定位都会顺畅很多。建议在正式批量部署前，先用 2～3 台测试虚拟机走一遍完整的“建文件夹 → 建资源池 → 建 VM → 验证路径”流程，确认命名和层级符合预期后再推广。