04-虚拟机生命周期管理

概述

前一篇完成了 vCenter Server 部署，vSphere 环境已经从单台 ESXi 主机管理进入集中控制阶段。到了这一篇，管理对象从平台本身转向虚拟机：如何创建一台标准虚拟机，如何把它转换成可复用模板，如何通过克隆、内容库、自定义规范和资源策略交付一致的工作负载，如何在运行期处理快照、迁移、扩容、VMware Tools、虚拟硬件版本和退役归档。

虚拟机生命周期管理不是“会点右键菜单”那么简单。生产环境里，虚拟机数量一旦超过几十台，随意创建、随意命名、随意打快照、随意扩盘和随意删除，最终会变成资产不清、权限混乱、存储爆满、备份不可恢复、性能问题难以定位。真正可靠的 vSphere 运维，需要把虚拟机看成有状态资产：从申请、设计、创建、交付、变更、保护、迁移到下线，每一步都能被记录、验证和回滚。

本文目标：

1. 建立虚拟机生命周期的完整运维模型，而不是只掌握单个菜单操作。
2. 设计一套适合中小型 vSphere 环境的虚拟机交付标准。
3. 完成新建虚拟机、模板化、克隆、客户机自定义、快照、迁移、资源调整和退役流程。
4. 理解快照、模板、克隆、vMotion、Storage vMotion、VMware Tools、虚拟硬件版本之间的边界。
5. 建立可检查、可审计、可自动化的日常管理基线。

本文默认环境延续前文：vCenter Server Appliance 8.0 Update 3 系列，ESXi 8.0 Update 3 系列，至少两台 ESXi 主机，具备一个管理网络、一个虚拟机业务网络，以及可供演示的本地或共享数据存储。若只有单台 ESXi 主机，也可以完成创建、模板、克隆、快照和资源调整；但 vMotion、HA、DRS、跨主机迁移等能力需要 vCenter 与合适的集群、网络和存储条件。

生命周期视角

虚拟机生命周期可以分成八个阶段：需求进入、规格设计、创建交付、标准化封装、运行变更、保护恢复、迁移优化、下线归档。每个阶段的产物不同，风险也不同。

图中把虚拟机从需求进入到下线归档的关键控制点串起来，强调创建只是生命周期中间的一环，真正的治理还包括标准、变更、保护、迁移和退役记录。 这张图的重点在于：虚拟机创建只是中间一环。很多生产事故不是创建时发生的，而是发生在后续变更，例如长时间保留快照、扩容前没有检查备份、迁移前没有核对网络、删除前没有确认资产归属。

为了让生命周期可控，建议每台虚拟机至少维护以下基础信息：

如果没有这些字段，后续任何自动化都会缺少判断依据。比如批量扩容无法知道哪些机器属于生产，批量下线无法知道哪些机器仍有审计保留要求，批量快照清理无法知道哪些快照是变更窗口内的临时保护点。

交付标准先于创建动作

在 vSphere Client 中新建虚拟机非常容易，但生产环境不应从“点 New Virtual Machine”开始，而应先定义交付标准。标准越清晰，后面越少靠个人经验补救。

命名与清单结构

建议虚拟机名称同时服务于人读、自动化和搜索。一个可落地的命名方式如下：

<业务缩写>-<环境>-<角色>-<序号>

示例：
erp-prod-app-01
erp-prod-db-01
ops-test-log-01

命名不要塞入过多变化信息，例如 IP、CPU 数量、项目阶段。IP 会变，资源会调，项目阶段会变；虚拟机名称一旦被备份、监控、日志、CMDB、脚本引用，频繁改名会制造额外成本。变化信息应放在标签、备注、CMDB 或自动发现字段里。

vCenter 清单结构建议按管理边界而不是个人偏好设计：

Datacenter
  Cluster-Production
    Folder-ERP
    Folder-MES
    Folder-Infra
  Cluster-Test
    Folder-Dev
    Folder-Training

如果企业已经有 CMDB 或资源申请系统，vCenter 文件夹不要重复承载所有业务分类，只保留足够支持权限、批量操作和视图过滤的层级。过深的文件夹会让 DRS 规则、权限继承和自动化路径更难维护。

标签和自定义属性

vSphere Tag 是虚拟机治理的重要工具。建议至少建立以下 Tag Category：

标签的价值不在于好看，而在于能被查询和联动。备份软件可以按标签绑定策略，监控平台可以按标签设置告警，自动化脚本可以按标签过滤对象。不要把标签做成几十个相互重叠的分类，也不要允许每个人随意新建含义相近的标签。

虚拟硬件与操作系统基线

虚拟硬件版本决定虚拟机可以使用的虚拟设备、功能和兼容性。vSphere 8 环境通常可以使用较新的虚拟硬件版本，但不要把“最新”当成无脑默认。虚拟硬件升级后，旧版本 ESXi 可能无法运行该虚拟机，回退也不如普通配置变更简单。

建议策略：

1. 新建虚拟机使用当前集群兼容的标准虚拟硬件版本。
2. 模板升级虚拟硬件前，先确认集群中没有老版本 ESXi 主机。
3. 对关键业务虚拟机，硬件版本升级与 VMware Tools 升级分开安排，便于定位问题。
4. 不为了解决普通性能问题随意升级虚拟硬件；先看 CPU Ready、内存交换、存储延迟和客户机指标。

客户机操作系统类型必须准确选择。它会影响默认虚拟硬件、VMware Tools、驱动、热添加、时间同步和自定义规范行为。比如 Windows Server、Ubuntu、RHEL、SLES、Debian 的客户机自定义机制不同，不能仅凭“Linux 64-bit”一项带过。

创建虚拟机

在 vSphere Client 中，右键目标文件夹、集群或主机，选择 New Virtual Machine。常见创建方式有四种：

新建向导关键选择

新建虚拟机时，不要一路默认下一步。以下项目需要明确：

一个典型 Linux 应用服务器起步规格：

CPU 与内存不要一开始过配

很多人认为虚拟机给更多 vCPU 就更快，实际并不总是如此。vCPU 增多后，ESXi 调度器需要为虚拟机找到更多可运行时间片，过多 vCPU 会增加 CPU Ready，尤其在物理核心紧张或过度分配严重的集群中更明显。

初始规格建议遵循三个原则：

1. 从业务厂商最低建议和历史负载起步，不凭感觉给大规格。
2. 先给可观测空间，再根据性能数据扩容。
3. 数据库、中间件、批处理和实时系统分别评估，不套统一模板。

对内存也是一样。给太少会导致客户机交换，给太多会降低集群整合率，并可能掩盖应用内存泄漏。生产环境应在 vCenter、客户机和应用三层同时观察：vCenter 看到的是宿主侧争用，客户机看到的是操作系统内存压力，应用看到的是堆、缓存和连接池状态。

磁盘置备选择

虚拟磁盘常见置备类型包括 Thick Lazy Zeroed、Thick Eager Zeroed、Thin Provision。多数通用场景可以使用 Thin，但前提是数据存储容量监控和告警可靠。核心数据库、强一致性能需求或特殊功能要求的虚拟机，可以按厂商建议选择厚置备。

不要把 Thin 当成无限容量。Thin 的风险是“每台 VM 看起来都有足够空间，但底层数据存储没有”。一旦数据存储爆满，影响的不是单台虚拟机，而是同一数据存储上的一组虚拟机。建议为数据存储配置 70% 预警、80% 处置、90% 禁止新增的运营规则。

模板、克隆与内容库

当一台虚拟机的操作系统、补丁、基础组件、安全基线、VMware Tools、云初始化或自定义脚本都准备好后，就可以把它转换为模板。模板是标准交付的基础。

模板交付的关键是从干净基线出发，并通过内容库、版本记录和克隆规范保持可审计。 这张图体现模板的关键：模板不是随便挑一台现有业务机转换，而是从干净基线构建。模板里不应残留业务数据、临时密码、旧 IP、旧 SSH host key、测试 agent 注册信息或过期补丁状态。

模板制作清单

Windows 模板建议检查：

1. 安装 VMware Tools，确认设备管理器无异常驱动。
2. 安装最新安全补丁和常用运行库。
3. 配置时间同步策略，避免客户机和域控漂移。
4. 设置本地管理员密码策略，生产环境交付后立即轮换。
5. 清理事件日志、临时目录、浏览器缓存和安装残留。
6. 确认 Windows 激活、KMS 或订阅策略。
7. 使用自定义规范或 Sysprep 处理 SID、主机名、网络和域加入。

Linux 模板建议检查：

1. 安装 open-vm-tools 或发行版推荐的 VMware Tools 包。
2. 配置 cloud-init、NetworkManager 或目标发行版网络栈。
3. 清理 /etc/machine-id、旧 SSH host key、临时日志和包缓存。
4. 配置 sudo、SSH、审计、时区、NTP、DNS。
5. 写入统一监控、日志、配置管理 agent 的安装入口，但避免预注册唯一身份。
6. 明确磁盘分区、LVM、文件系统扩容策略。

Linux 模板清理示例：

sudo cloud-init clean --logs
sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo rm -f /etc/ssh/ssh_host_*
sudo rm -rf /tmp/* /var/tmp/*
sudo journalctl --rotate
sudo journalctl --vacuum-time=1s

不同发行版对 machine-id、网络配置和 cloud-init 的处理方式不完全一致。模板正式进入生产前，应从模板部署一台测试 VM，确认它能生成新的主机身份、拿到正确网络、被监控系统识别为新资产。

克隆现有虚拟机

克隆适合复制环境和问题复现，但它的风险比从模板部署更高。克隆出来的虚拟机可能保留原机的主机名、IP、应用节点 ID、数据库复制身份、备份 agent ID、监控对象 ID 和安全证书。如果直接开机接入生产网络，可能引发 IP 冲突、集群脑裂、日志混乱或授权问题。

克隆前应确认：

克隆生产数据库做测试时，建议优先选择备份恢复或存储复制的受控流程，而不是随手克隆运行中的虚拟机。虚拟机层面的克隆只能保证虚拟磁盘在某个时点的文件视角，不能替代数据库一致性保护。

内容库

Content Library 适合在多个集群、数据中心或站点之间分发模板、ISO、OVF 和脚本。小环境可以先使用本地模板；当模板数量增加、站点变多、团队协作变复杂时，再引入内容库。

内容库设计建议：

1. 本地库用于主站点模板管理。
2. 订阅库用于分发到分支站点或隔离环境。
3. 模板名称带版本，例如 tpl-ubuntu-2204-base-2026q2。
4. 模板更新采用新版本并行，不直接覆盖旧版本。
5. 每次模板发布记录补丁日期、Tools 版本、基线变更和验证结果。

快照管理

快照是 vSphere 运维中最容易被误用的功能。它适合短时间变更保护，例如系统补丁、应用升级、配置调整前的快速回退点；它不适合长期备份，也不适合替代备份系统。Broadcom 的快照最佳实践明确强调：不要把 VMware snapshot 当成备份，单个快照不应长期保留，快照链过深会影响性能和稳定性。

快照应嵌入变更流程并短期保留，长期恢复能力仍然依赖备份和恢复演练。 这张图说明快照应该嵌入变更流程，而不是变更人员的临时习惯。快照创建前要确认备份，快照创建时要写明用途，变更结束后要删除并检查整合状态。

快照文件和行为

在 VMFS 数据存储上，创建快照后，虚拟机会产生 delta 或 sesparse 文件。新的写入进入快照子盘，读取可能同时涉及基盘和 delta 链。快照保留时间越长、写入变化越多、链越深，性能和整合风险越高。vSphere 8 与 VMFS6 环境中，快照文件格式和行为会随数据存储类型变化；vVols 场景下，快照更多由阵列和 VASA/SPBM 机制参与处理。

常见快照文件：

内存快照可以回到运行状态，但创建和回退成本更高，并且会 stun 虚拟机。Quiesce 快照依赖 VMware Tools，让客户机文件系统进入更适合备份的一致状态。内存快照和 quiesce 不是同一个目标，不能混为一谈。

快照命名和保留策略

建议快照命名包含三个信息：

CHG-20260527-before-os-patch-expire-20260528

命名字段包括变更单、用途、过期时间。不要使用 test、before change、snapshot1 这类无法追责的名称。

快照运营基线：

1. 生产 VM 快照原则上只服务于短时间变更窗口。
2. 快照保留超过 24 小时必须有负责人确认。
3. 快照保留超过 72 小时必须进入异常清理清单。
4. 禁止在存在快照时扩展虚拟磁盘。
5. 删除快照后检查是否需要 Consolidate。
6. 备份软件创建的快照也要纳入检查，不能只看 UI。

可以使用 PowerCLI 定期扫描：

Connect-VIServer vcsa01.lab.example.com

Get-VM | Get-Snapshot |
  Select-Object VM, Name, Created, SizeGB, Description |
  Sort-Object Created |
  Format-Table -AutoSize

检查需要整合的虚拟机：

Get-VM | Where-Object {$_.ExtensionData.Runtime.ConsolidationNeeded -eq $true} |
  Select-Object Name, PowerState

如果发现长时间快照，不要第一反应就是删除。应先确认数据存储剩余容量、虚拟机 I/O 高峰、备份窗口和业务影响。大快照删除和整合可能造成长时间 I/O 压力，必要时安排维护窗口。

迁移与放置

虚拟机迁移包括计算迁移、存储迁移和两者同时迁移。vMotion 迁移运行中的虚拟机计算位置；Storage vMotion 迁移虚拟机文件所在数据存储；冷迁移可以在关机状态下跨主机、跨数据存储调整位置。

迁移不是单纯“搬家”。它涉及 CPU 兼容、网络端口组、共享存储、vMotion VMkernel 网络、许可、集群规则、数据存储容量、快照状态和业务窗口。

迁移决策

迁移决策必须同时检查计算兼容、存储容量、网络一致性和业务窗口。 迁移前最容易漏的是网络。源主机有某个端口组，不代表目标主机也有相同端口组；标准交换机尤其容易出现名称相同但 VLAN 不同，或者名称不同但实际网络相同的情况。使用 vSphere Distributed Switch 可以降低这类不一致，但仍要检查上游交换机 trunk、VLAN 允许列表和物理网卡绑定。

vMotion 前置条件

典型前置条件包括：

1. 源主机和目标主机由同一个 vCenter 管理。
2. 主机有可用 vMotion VMkernel 适配器，网络互通。
3. CPU 兼容，或集群启用合适的 EVC 模式。
4. 目标主机可以访问虚拟机所需网络。
5. 目标主机资源足够，且不违反 DRS/反亲和规则。
6. 若只迁移计算位置，目标主机能访问相同数据存储。

迁移前检查示例：

# 在 ESXi 上查看 VMkernel 网络
esxcli network ip interface list

# 查看 VMkernel 适配器标签和 IP
esxcli network ip interface ipv4 get

PowerCLI 查看 VM 所在主机和数据存储：

Get-VM -Name erp-prod-app-01 |
  Select-Object Name, VMHost, @{N="Datastore";E={$_.DatastoreIdList}}

生产环境建议把大批量迁移拆成小批次执行。先迁移低风险 VM，观察 vMotion 网络、目标主机 CPU Ready、存储延迟和业务监控，再推进关键 VM。不要在备份窗口、存储重平衡窗口、杀毒全盘扫描窗口和业务批处理窗口叠加大规模迁移。

运行期变更

虚拟机运行后，常见变更包括增加 CPU、增加内存、扩展磁盘、增加网卡、修改端口组、调整资源份额、启用热添加、升级 VMware Tools、升级虚拟硬件。每种变更的回滚难度不同。

资源调整原则

资源调整要基于证据。以下指标比“业务说慢”更适合作为决策依据：

扩 CPU 前先看 CPU Ready。若一台 VM 从 4 vCPU 扩到 8 vCPU 后变慢，原因可能不是 CPU 不够，而是调度等待更严重。扩内存前先看客户机是否真的交换，应用是否有内存上限，JVM 或数据库是否需要单独调整参数。

磁盘扩容

磁盘扩容前检查：

1. 是否存在快照。存在快照时不要扩展虚拟磁盘。
2. 数据存储是否有足够容量和增长空间。
3. 备份是否支持扩容后的磁盘大小。
4. 客户机分区表和文件系统是否支持在线扩展。
5. 是否需要应用维护窗口。

Linux LVM 扩容示例：

# 假设 /dev/sdb 扩容后作为 PV
sudo rescan-scsi-bus.sh
sudo pvresize /dev/sdb
sudo lvextend -r -L +100G /dev/vgdata/lvdata
df -h

如果是分区盘，需要先扩分区：

sudo growpart /dev/sda 3
sudo pvresize /dev/sda3
sudo lvextend -r -l +100%FREE /dev/mapper/vgroot-lvroot

Windows 扩容通常在磁盘管理或 PowerShell 中完成：

Get-Disk
Get-Partition -DriveLetter D
Resize-Partition -DriveLetter D -Size (Get-PartitionSupportedSize -DriveLetter D).SizeMax

扩容后必须验证应用是否看到新容量，备份策略是否仍然成功，磁盘告警阈值是否需要调整。只在 vCenter 里把 VMDK 改大，不等于业务可用容量已经增加。

VMware Tools

VMware Tools 提供驱动、时间同步、心跳、客户机操作、IP 汇报、脚本执行、quiesce 等能力。Linux 环境通常优先使用发行版维护的 open-vm-tools，Windows 环境使用 VMware Tools 安装包并纳入补丁维护。

Tools 状态要作为交付检查项：

不要把 Tools 升级当成永远无风险。网卡驱动、存储驱动、客户机服务都可能受影响。关键业务建议先在同模板测试 VM 上验证，再分批升级。

虚拟硬件升级

虚拟硬件升级通常需要关机或重启，并且影响兼容性。建议只在以下场景升级：

1. 需要新硬件版本支持的功能。
2. 升级 vSphere 后模板基线需要统一。
3. 厂商明确要求某个虚拟硬件版本。
4. 安全或兼容性基线要求。

升级前应确认：备份可恢复、目标集群全部 ESXi 主机兼容、没有旧版本恢复需求、测试环境已验证。升级后验证虚拟网卡、磁盘控制器、启动顺序、EFI/Secure Boot、Tools 状态和应用服务。

权限、资源池与保护边界

虚拟机生命周期管理还涉及谁能操作、操作到什么程度、资源如何隔离。不要让所有应用管理员都拥有 vCenter Administrator 权限。权限应按角色拆分。

常见角色设计：

资源池适合表达资源边界，但不适合当作文件夹使用。资源池会影响 CPU 和内存份额、预留和限制。若只是为了分类，使用 VM Folder；若确实需要资源治理，再使用资源池。

不建议随意给 VM 设置 CPU 或内存 Limit。Limit 会造成看似资源充足但 VM 性能受限的隐蔽问题。Reservation 也要谨慎使用，它会影响 HA 准入控制和集群可用容量。多数通用工作负载使用默认 Shares 即可，关键业务再按证据设置资源策略。

退役与归档

删除虚拟机是生命周期里风险最高但最容易被轻视的动作。生产环境不应直接右键 Delete from Disk。推荐采用四段式退役：

退役流程先证明依赖已解除，再完成归档、清理和可追溯删除。 这张状态图强调删除前的等待和确认。很多“已经没人用”的虚拟机，在关机后才会暴露依赖，例如定时任务、接口回调、旧报表、授权服务、堡垒机脚本或第三方系统白名单。

退役检查清单：

1. 业务负责人确认下线。
2. 技术负责人确认应用、数据库、计划任务、接口依赖。
3. 监控平台进入维护或下线。
4. 备份完成最后一次归档，并记录恢复期限。
5. DNS、负载均衡、CMDB、资产、堡垒机、EDR、日志平台同步更新。
6. 关机观察至少一个业务周期。
7. 删除前导出配置摘要和标签信息。

PowerCLI 导出待下线 VM 信息：

$vm = Get-VM -Name erp-old-app-01
$vm | Select-Object Name, PowerState, VMHost, NumCpu, MemoryGB, UsedSpaceGB |
  Export-Csv ./erp-old-app-01-summary.csv -NoTypeInformation

Get-HardDisk -VM $vm |
  Select-Object Parent, Name, CapacityGB, Filename |
  Export-Csv ./erp-old-app-01-disks.csv -NoTypeInformation

删除后仍要回看数据存储容量、备份目录、监控对象和 CMDB 状态。虚拟机从 vCenter 里消失，不代表所有外围系统都已经清理干净。

故障排查 Runbook

虚拟机生命周期问题通常集中在创建失败、部署后无法入网、快照无法删除、迁移失败、扩容无效、Tools 异常、性能下降。排障时不要只盯 UI 报错，应从任务事件、主机日志、客户机日志、存储容量和网络一致性一起查。

图中把生命周期故障拆成创建/克隆、部署后网络、快照整合和 vMotion 几类路径，并给出对应证据入口。排障时先收集任务事件、VM 日志、主机日志、存储路径和网络连通性，再修改配置。

创建或克隆失败

检查顺序：

1. 目标文件夹、资源池、数据存储权限是否足够。
2. 数据存储容量是否满足置备需求。
3. 模板是否可访问，是否位于目标主机可访问的数据存储。
4. 客户机自定义规范是否匹配操作系统。
5. 内容库订阅是否同步完成。
6. vCenter 任务事件中是否有更具体错误。

常用检查：

Get-Task | Sort-Object StartTime -Descending | Select-Object -First 20
Get-VMHost | Select-Object Name, ConnectionState, PowerState
Get-Datastore | Select-Object Name, FreeSpaceGB, CapacityGB

部署后无法入网

重点检查：

1. VM 网卡是否 Connected、Connect at power on 是否开启。
2. 端口组是否正确，VLAN ID 是否匹配。
3. 目标 ESXi 主机物理上联是否允许该 VLAN。
4. 客户机网卡名称是否变化导致配置未生效。
5. 克隆 VM 是否保留旧 IP、旧 MAC 或旧网络规则。
6. DNS、网关、防火墙策略是否同步。

Linux 客户机检查：

ip addr
ip route
resolvectl status
nmcli device status
ping -c 4 <gateway-ip>

vSphere 侧检查：

Get-NetworkAdapter -VM erp-prod-app-01 |
  Select-Object Parent, Name, NetworkName, Type, ConnectionState, MacAddress

快照删除或整合失败

先检查数据存储容量和备份任务是否仍在运行。删除快照需要把 delta 数据合并回基盘，空间紧张时可能失败。不要取消正在运行的删除或整合任务；取消可能带来更复杂的数据一致性风险。

检查命令：

Get-VM erp-prod-app-01 | Get-Snapshot
Get-VM erp-prod-app-01 | Select-Object Name,@{N="ConsolidationNeeded";E={$_.ExtensionData.Runtime.ConsolidationNeeded}}

如果 UI 显示需要整合：

1. 确认没有备份任务占用。
2. 确认数据存储有足够空闲空间。
3. 低峰期执行 Consolidate。
4. 观察 VM 事件和主机 vmkernel.log。
5. 整合后再次扫描快照和数据存储容量。

vMotion 失败

常见原因：

1. vMotion VMkernel 网络不可达。
2. 目标主机没有相同网络端口组。
3. CPU 兼容性不足或 EVC 未配置。
4. 虚拟机挂载本地 ISO、直通设备或不支持迁移的设备。
5. DRS 规则、反亲和规则或资源不足。
6. 大内存 VM 在高写入负载下迁移收敛困难。

处理建议：先迁移一台低风险小 VM 验证路径，再迁移目标 VM；必要时关机冷迁移。对于长期失败的 vMotion，不要反复重试挤占 vMotion 网络，应先收集错误、确认前置条件。

自动化基线

手工生命周期管理适合学习和少量环境，但生产环境应逐步自动化。自动化不一定一开始就上复杂平台，PowerCLI 就可以先解决批量检查和交付一致性。

批量检查快照和 Tools

Connect-VIServer vcsa01.lab.example.com

$report = Get-VM | ForEach-Object {
  $vm = $_
  $snapshots = Get-Snapshot -VM $vm -ErrorAction SilentlyContinue
  [PSCustomObject]@{
    Name = $vm.Name
    PowerState = $vm.PowerState
    VMHost = $vm.VMHost.Name
    ToolsStatus = $vm.ExtensionData.Guest.ToolsStatus
    SnapshotCount = ($snapshots | Measure-Object).Count
    OldestSnapshot = ($snapshots | Sort-Object Created | Select-Object -First 1).Created
    ConsolidationNeeded = $vm.ExtensionData.Runtime.ConsolidationNeeded
  }
}

$report | Export-Csv ./vm-lifecycle-audit.csv -NoTypeInformation

这个报表可以作为每周检查的起点。后续可以加入标签、备份策略、数据存储、VM 硬件版本、Tools 版本、资源过配等字段。

从模板部署的最小流程

$template = Get-Template -Name "tpl-ubuntu-2204-base-2026q2"
$cluster = Get-Cluster -Name "Cluster-Production"
$datastore = Get-Datastore -Name "vsanDatastore"
$folder = Get-Folder -Name "Folder-ERP"
$network = Get-VirtualPortGroup -Name "PG-APP-PROD"

New-VM -Name "erp-prod-app-02" `
  -Template $template `
  -ResourcePool $cluster `
  -Datastore $datastore `
  -Location $folder

Get-VM "erp-prod-app-02" | Get-NetworkAdapter |
  Set-NetworkAdapter -NetworkName $network.Name -Confirm:$false

真实生产脚本还应接入 IPAM、DNS、CMDB、备份策略、监控注册和审批系统。本文示例只展示 vSphere 侧最小动作，不应直接当成完整交付流水线。

生命周期标签自动检查

建议建立规则：

1. 没有 Environment 标签的 VM 不允许进入生产备份策略。
2. 没有 Owner 标签的 VM 进入资产异常清单。
3. Lifecycle=Retiring 的 VM 禁止新增磁盘和扩容。
4. BackupPolicy=None 的生产 VM 必须有豁免单。
5. 存在快照超过 72 小时的 VM 自动通知负责人。

这类规则可以先用报表执行，再逐步接入自动告警或工单。不要一开始就自动删除或自动回滚，生命周期自动化应先做到可见，再做到提醒，最后才做到闭环执行。

实战交付案例

假设要交付一台 ERP 应用服务器 erp-prod-app-02，要求是 Ubuntu 22.04、2 vCPU、8 GB 内存、系统盘 80 GB、数据盘 200 GB、接入生产应用 VLAN、纳入 Gold 备份策略。

1. 设计记录

2. 从模板部署

从 tpl-ubuntu-2204-base-2026q2 部署，使用 Linux 客户机自定义规范设置主机名、IP、DNS、时区和初始 SSH 策略。部署完成后先不开启业务，而是做基础验证。

3. 客户机验证

hostnamectl
ip addr
ip route
timedatectl
systemctl status open-vm-tools
df -h
lsblk

确认主机名、IP、路由、NTP、Tools 和磁盘均正确后，再安装应用依赖。

4. vSphere 侧验证

Get-VM erp-prod-app-02 |
  Select-Object Name, PowerState, NumCpu, MemoryGB, VMHost

Get-NetworkAdapter -VM erp-prod-app-02
Get-HardDisk -VM erp-prod-app-02
Get-TagAssignment -Entity erp-prod-app-02

5. 保护策略验证

备份系统按 BackupPolicy=Gold 标签自动纳入策略后，执行一次手动备份和一次文件级或整机恢复演练。只有恢复验证通过，才算交付完成。没有恢复验证的备份，只能算“看起来有任务”。

6. 交付记录

交付记录至少包括：VM 名称、模板版本、创建时间、创建人、IP、负责人、备份策略、监控对象、恢复验证结果、初始资源规格。后续扩容、快照、迁移、下线都应追加记录。

常见反模式

反模式 1：把快照当备份

快照依赖原始虚拟磁盘，基盘丢失时快照无法独立恢复。长期快照还会拖累性能和增加整合风险。正确做法是：快照服务短期变更，备份服务灾难恢复。

反模式 2：克隆生产机直接开机

克隆 VM 保留旧身份，直接接入网络可能造成 IP 冲突、域身份冲突、应用集群冲突和监控混乱。正确做法是：克隆后先接隔离网络，改名、改 IP、重新注册 agent，再进入目标环境。

反模式 3：资源越大越好

过多 vCPU 会增加调度等待，过多内存会降低集群利用率并掩盖问题。正确做法是：以基线起步，用指标驱动扩容。

反模式 4：模板长期不更新

过期模板会把旧补丁、旧 Tools、旧 agent 和旧配置复制到所有新 VM。正确做法是：模板按季度或补丁周期发布新版本，旧版本保留一段时间后退役。

反模式 5：删除前不关机观察

直接删除“没人认领”的 VM，可能影响隐藏依赖。正确做法是：先打 Lifecycle=Retiring 标签，关机观察，确认备份归档，再删除。

运维检查清单

每周检查：

1. 是否存在超过 72 小时的快照。
2. 是否有 ConsolidationNeeded=True 的 VM。
3. 是否有 VMware Tools 未安装、未运行或版本过旧的 VM。
4. 是否有数据存储使用率超过阈值。
5. 是否有无 Owner、无 Environment、无 BackupPolicy 标签的 VM。
6. 是否有长时间 Powered Off 但未进入退役流程的 VM。

每月检查：

1. 模板补丁和 Tools 版本是否需要更新。
2. 备份恢复演练是否覆盖关键业务。
3. VM 资源使用是否存在明显过配。
4. 是否需要整理文件夹、标签和内容库版本。
5. 是否有虚拟硬件版本升级需求。

重大变更前检查：

1. 备份是否成功且可恢复。
2. 是否需要短期快照，快照过期时间是谁负责。
3. 是否存在磁盘扩容、网络切换、Tools 升级、硬件版本升级等不可快速回退动作。
4. 是否避开备份窗口、批处理窗口和存储维护窗口。
5. 是否准备了业务验证脚本或检查项。

总结

虚拟机生命周期管理的核心是把 VM 当成可治理的资产，而不是一组孤立的虚拟硬件参数。创建虚拟机前要有命名、标签、模板、资源、网络、备份和权限标准；运行期间要用指标驱动扩容，用短期快照服务变更，用 vMotion 和 Storage vMotion 服务维护与优化；下线时要经过关机观察、备份归档、外围系统清理和审计确认。

本篇完成了从创建、模板、克隆、快照、迁移、资源调整、VMware Tools、自动化检查到退役归档的完整流程。下一篇将进入 vSwitch 与网络配置，重点讨论标准交换机、分布式交换机、端口组、VLAN、VMkernel 网络、上联冗余和虚拟机网络故障排查。

验证环境说明：

• vCenter 版本：vCenter Server Appliance 8.0 Update 3 系列
• ESXi 版本：VMware ESXi 8.0 Update 3 系列
• 管理方式：vSphere Client 与 PowerCLI
• 实验拓扑：两台 ESXi 主机，一个生产 VM 网络，一个管理网络，一个共享或可迁移数据存储
• 本文撰写日期：2026-05-27

参考资料

1. Broadcom Knowledge Base: Best practices for using VMware snapshots in the vSphere environment - https://knowledge.broadcom.com/external/article?legacyId=1025279
2. Broadcom Knowledge Base: Overview of virtual machine snapshots in vSphere - https://knowledge.broadcom.com/external/article?articleNumber=342618
3. Broadcom Knowledge Base: Understanding virtual machine snapshots within Virtual Volumes - https://knowledge.broadcom.com/external/article/341651/understanding-virtual-machine-snapshots.html
4. Broadcom Knowledge Base: Rightsizing virtual machines on ESXi 8.0 - https://knowledge.broadcom.com/external/article/438023/rightsizing-virtual-machines-on-esxi-80.html
5. Broadcom Knowledge Base: Configuration Maximums - https://knowledge.broadcom.com/external/article/317882/configuration-maximums.html
6. Broadcom TechDocs: VMware vSphere 8.0 Product Documentation - https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0.html