本文结合 Broadcom 官方知识库 KB 318825(原 VMware KB 1025263)系统梳理 vSphere 8.x/9.x 环境下虚拟机快照(VMware Snapshots)的使用红线与架构原则。重点解析快照非备份定位、72 小时生命周期上限、快照链深度控制、严禁带快照扩容磁盘等核心约束,并给出第三方备份孤立快照排查、ESXi CLI 命令行巡检及快照整合(Consolidation)的实战运维指南。
快照核心定位与底层机制
虚拟机快照是 VMware vSphere 中用于记录虚拟机在特定时间点(Point-in-Time)状态与数据的机制。理解快照的底层实现方式,是防范性能劣变与数据损坏的前提。
快照不是备份(Not a Backup)
官方最佳实践首条明确强调:严禁将 VMware 快照作为虚拟机备份方案。
- 依赖完整基盘:创建快照后,虚拟机的基准虚拟磁盘(如
vmname-flat.vmdk)立即被置为只读(Read-Only)。ESXi 会生成一个子增量磁盘(Delta 磁盘或 SEsparse 磁盘,命名格式形如vmname-000001-sesparse.vmdk),此后虚拟机产生的所有新增或修改数据都会写入该增量磁盘中。 - 缺失独立恢复能力:增量磁盘仅记录相对于基盘的数据变更日志(Redo Log)。一旦基准磁盘发生物理介质损坏、误删除或所在 Datastore 故障,单独的快照增量文件无法还原出完整虚拟机数据。
- 无容灾隔离域:传统备份要求将数据离线或归档至独立的存储目标(如 NAS、对象存储或备份一体机),而快照默认与虚拟机存放在同一个 Datastore 中,无法防御存储阵列级灾难。
快照生命周期状态流转
虚拟机在创建、读写、提交快照时的内部流转关系如下:
Base Disk 可读写"] -->|"1. 创建快照 (Take Snapshot)"| B["快照保护状态
Base Disk 置为只读
创建 Delta/SEsparse 子盘"] B -->|"2. 持续写 I/O"| C["Delta 盘体积持续膨胀
多层快照形成快照链"] C -->|"分支 A: 回滚 (Revert to Snapshot)"| D["丢弃 Delta 写入
恢复至快照记录点"] C -->|"分支 B: 整合删除 (Delete / Consolidate)"| E["将 Delta 变更块逐层 Merge 提交至基盘
释放增量磁盘空间"] E --> F["恢复单一无快照健康状态"]
快照关联文件类型
在 ESXi 底层数据存储中,一个拥有快照的虚拟机目录通常包含以下文件:
| 关联文件类型 | 格式命名范例 | 核心职责说明 |
|---|---|---|
| 增量描述符 | <vm>-000001.vmdk | 纯文本描述符文件,记录磁盘几何结构、CID/ParentCID 链条关系,指向实际增量二进制数据文件。 |
| 增量数据盘 | <vm>-000001-sesparse.vmdk | 实际存储写入变更的差量二进制文件。VMFS6 默认采用 SEsparse 格式,旧版 VMFS5 采用 VMFSsparse(-delta.vmdk)。 |
| 快照元数据 | <vm>.vmsd | 集中式快照数据库(纯文本),记录快照树拓扑关系、UID、父子节点与快照时间戳。 |
| 快照状态文件 | <vm>-Snapshot1.vmsn | 记录生成快照瞬间虚拟机的配置参数(VMX 硬件配置)。如果勾选了内存快照,还包含运行态内存转储。 |
| 内存转储文件 | <vm>-Snapshot1.vmem | 仅在勾选“生成虚拟机内存快照”时生成,包含虚拟机 RAM 的完整映射,文件大小与分配给虚机的内存容量相当。 |
六大核心使用准则与管理红线
Broadcom KB 318825 结合生产环境故障排查大数据,制定了以下六项必须严格遵循的基准规则。
1. 坚持短周期运维定位
快照仅适用于风险前置兜底场景,例如:
- 操作系统重要内核补丁或 Service Pack 升级;
- 复杂业务中间件或数据库应用的版本迁移;
- 影响全局配置的底层环境改造。
一旦验证新版本运行平稳、变更成功,应在计划窗口内立即将快照删除(Merge 提交合并)。
2. 严格执行 72 小时保留上限 (The 72-Hour Rule)
官方红线:单个快照保留时间严禁超过 72 小时;生产环境中建议控制在 24 至 48 小时内完成整合。
长期保留快照会引发严重系统风险:
- 存储空间雪崩(Datastore Out of Space):快照增量文件按需动态增长。随着高负载应用持续写入,Delta 磁盘体积可能逼近甚至超过原始基盘大小。一旦 Datastore 存储被填满,ESXi 会直接将该存储上的所有虚拟机挂起(Suspended),引发大面积业务瘫痪。
- 读写性能骤降:读取未在 Delta 盘中命中的数据块时,存储堆栈必须逐层回溯父级磁盘。多层块映射查找会极大拉高 I/O 延迟(Storage Latency),显著损耗虚拟机 IOPS。
- 快照合并风暴与 Stun 耗时:体积数十 GB 乃至上百 GB 的增量盘在执行删除时,需要将海量数据块回写进基盘,产生持久的高负荷写 I/O,严重延长虚拟机停顿(Stun)时间。
3. 快照链深度控制在 2~3 层以内
- 理论上限 vs 推荐深度:vSphere 架构在技术层面单链最多支持 32 个快照,但该上限仅为架构能力边界,非推荐运行配置。
- 生产控制:生产集群中快照链深度应严格限制在 2 至 3 层以内。快照树层级过深会导致锁定竞争、元数据链条脆弱,在整合时极大增加故障率。
4. 严禁在存在快照时扩容虚拟磁盘 (Fatal Red Line)
[!CAUTION] 无论虚拟机处于开机还是关机状态,只要虚拟机存在快照,严禁对其任何虚拟磁盘(VMDK)或虚拟兼容模式 RDM 进行扩容! 即使通过 ESXi CLI(如
vmkfstools -X)手动修改,也同样属于严重违规操作。
底层原因与破坏机理:
- 扩容操作会直接修改基准磁盘(Base Disk)描述符中的扇区总数与物理几何信息;
- 处于顶层的快照 Delta/SEsparse 磁盘记录的是基于旧几何尺寸建立的块偏移量(Block Offset);
- 尺寸变动导致父子磁盘之间的几何映射彻底脱节,引发 CID 校验不一致与快照链断裂(Snapshot Chain Corruption);
- 一旦损坏,虚拟机将报错
Cannot open the disk or one of the snapshot disks it depends on,极难恢复。
正确处理步骤:必须先在 Snapshot Manager 中执行 Delete All 或调用 API 将全部快照完整合并,确认虚拟机回到无快照健康状态后,方可调整磁盘大小。
5. 严禁强行终止或中断快照删除/整合任务
快照删除并非简单丢弃文件,而是将差异数据安全合并(Commit)到父磁盘中。
- 在合并庞大快照时,vCenter 界面进度条常常在
99%停留数十分钟甚至数小时,这属于正常的磁盘底层数据密集写入阶段。 - 高危行为:强行重启 ESXi 物理宿主机、强制重启
hostd/vpxa服务进程或从任务列表中暴力杀死进程。 - 恶果:中断正在写入的重做日志会导致文件系统元数据撕裂、块指针丢失,造成虚拟磁盘彻底不可访问。
6. 防范第三方备份引发的“孤立快照”(Orphaned Snapshots)
主流虚拟化备份软件(如 Veeam Backup & Replication、Commvault、Veritas)利用 vStorage APIs for Data Protection (VADP) 自动创建临时快照并挂载虚拟机磁盘提取数据。
- 隐形快照成因:若备份任务因网络超时、存储高延迟或主机通信故障意外中断,备份程序可能未能发出删除指令;或者 ESXi 执行了合并但 vCenter 数据库状态未同步更新。
- UI 盲区:此类由 API 触发的异常快照,往往不会在 vSphere Client 的 Snapshot Manager 界面中列出,但其底层增量文件仍在持续写入并霸占存储空间。管理员必须依赖 CLI 或定时脚本进行底层巡检。
快照高级选项与兼容性边界
内存快照(Memory Snapshot)开销权衡
在 vSphere Client 中创建快照时,可配置两项关键开关:
- 生成虚拟机内存快照 (Snapshot the virtual machine’s memory):
- 机制:将虚拟机的内存(RAM)与 CPU 寄存器即时状态转储到
.vmsn与.vmem文件中。 - 代价:额外占用与虚拟机内存等额的物理存储空间;打快照耗时成倍增加;在恢复快照时虽然可恢复到运行中的内存态,但对生产系统性能开销过大。
- 建议:除特殊应用故障排查或软件调试要求外,生产系统默认不建议勾选内存快照。
- 机制:将虚拟机的内存(RAM)与 CPU 寄存器即时状态转储到
- 静默客体文件系统 (Quiesce guest file system):
- 机制:通过虚拟机内部安装的 VMware Tools,联动 Windows 卷影复制服务(VSS)或 Linux 的
/usr/sbin/pre-freeze-script脚本,在快照切分前将内存脏页和数据库未提交事务刷入磁盘。 - 建议:针对运行 SQL Server、Oracle 或高频事务业务的虚机,打快照前必须启用静默选项,确保文件系统达到应用一致性(Application Consistency)。
- 机制:通过虚拟机内部安装的 VMware Tools,联动 Windows 卷影复制服务(VSS)或 Linux 的
特殊磁盘类型对快照的支持矩阵
并非所有挂载到虚机上的存储设备都支持快照功能:
| 磁盘配置模式 | 是否支持快照 | 行为与注意事项 |
|---|---|---|
| 从属磁盘 (Dependent) | 支持 | 默认模式。所有数据完全纳入快照保护,快照回滚时磁盘同步回滚。 |
| 独立-持久磁盘 (Independent - Persistent) | 不支持 | 彻底从快照中旁路(Bypass)。给虚机打快照时不会为该盘生成 Delta 文件;回滚快照时该盘上的写入数据完整保留。 |
| 独立-非持久磁盘 (Independent - Nonpersistent) | 不支持 | 旁路快照机制。虚机关机或重置时,该磁盘上的所有写入会自动丢弃。 |
| 虚拟兼容模式 RDM (Virtual RDM) | 支持 | 映射 SAN LUN,但由 ESXi 虚拟化 SCSI 堆栈承载,支持生成 Delta 增量快照。 |
| 物理兼容模式 RDM (Physical RDM) | 不支持 | SCSI 指令直通底层物理存储阵列,ESXi 无法截获 I/O,无法创建快照。若虚机挂载了该类磁盘,打快照会直接报错或跳过该盘。 |
处理“需要整合虚拟机磁盘”告警
当虚拟机摘要界面出现黄色告警 Virtual machine disks consolidation is needed(需要整合虚拟机磁盘)时,说明存在未能成功收敛的增量重做日志。
排错与处理流程:
- 界面常规整合:
- 右键虚拟机 -> 快照 (Snapshots) -> 整合 (Consolidate)。
- 锁冲突导致整合失败排查:
- 若报错
The operation is not allowed in the current state或Failed to lock the file,通常是有备份代理虚拟机挂载了该磁盘未卸载,或者 ESXi 管理进程发生句柄锁定。 - 检查占用锁的主机:查看返回日志中的
bashvmkfstools -D /vmfs/volumes/<Datastore>/<VM>/<VM>-000001-sesparse.vmdkRO Owner或exclusive log owner对应的 MAC 地址,定位持有锁的 ESXi 节点。 - 若为宿主机管理进程无响应,重启 ESXi 主机管理代理:
bash/etc/init.d/hostd restart /etc/init.d/vpxa restart
- 若报错
- 静默窗口整合:针对高 I/O 写入虚拟机(如高频交易数据库),在业务高峰期执行整合可能因写入速度超越合并速度而导致任务失败。应选在业务低峰期执行整合,必要时可关机后执行整合以彻底规避 Stun 效应。
监控与防御建议
为避免快照遗忘导致的存储故障,建议在生产环境中建立以下防护网:
- vCenter 自定义警报:
- 创建针对
Virtual Machine Snapshot Size(快照容量占用)的告警阈值; - 创建针对
Virtual Machine Snapshot Runtime(快照存活时间)的警报,超过 48 小时触发警告,超过 72 小时发送紧急告警。
- 创建针对
- 备份作业完工钩子:
- 审查第三方备份软件的作业报告,确保每个 Backup Job 结束动作中包含快照验证与强制清除任务。
参考
- https://knowledge.broadcom.com/external/article/318825/best-practices-for-using-vmware-snapshot.html
- https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-virtual-machine-administration/managing-virtual-machines/using-snapshots-to-manage-virtual-machines.html
- https://knowledge.broadcom.com/external/article/316084/determining-if-an-esxi-virtual-machine.html