目录

• 目录
• 前言
• VMware 虚拟机文件类型
• VMware 虚拟机的快照
  • Quiseced Snapshot
  • Quiseced Snapshot 的创建过程
  • 创建快照
  • 创建快照的执行过程及原理
  • 删除快照
• CBT
  • CBT 执行过程
  • queryChangedDiskAreas
  • 开启 CBT

前言

该篇博文是 VMware 虚拟磁盘编程的基础，也是编写 VMware 虚拟机保护与恢复程序的基础，属于相关知识点扫盲。

VMware 虚拟机文件类型

VMware 虚拟机在 EXSi 宿主机上的文件类型：

下面着重记录 VMware 虚拟机必备的三类文件：

• vm_name.vmdk (配置文件)：保存的是该虚拟机磁盘文件的元数据(一般包含有两类最重要的磁盘文件的基本信息)，EXAMPLE:

# Disk DescriptorFile
version=3
encoding="UTF-8"
CID=2a9d852c
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"

# Extent description
RW 8388608 VMFS "vm_name-flat.vmdk"

# Change Tracking File
changeTrackPath="vm_name-ctk.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.deletable = "true"
ddb.geometry.cylinders = "522"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "01b9f98fe5883631cfc93a082a9d852c"
ddb.uuid = "60 00 C2 92 fb ad ff ed-6e d3 c0 fc 62 15 05 73"
ddb.virtualHWVersion = "8"

• vm_name-flat.vmdk (二进制文件)：Extent description 文件，保存虚拟机实际的虚拟磁盘信息。
• vm_name-ctk.vmdk (二进制文件)：Change Tracking File 改变追踪文件，保存自从上次快照以来的虚拟机所发生变化的数据块信息。

VMware 虚拟机的快照

VMware 虚拟机快照有下列三种类型：

• 崩溃一致快照(crash-consistent snapshot)：是 VMware 虚拟机的默认快照类型，相当于电脑突然断电时磁盘的状态，闪存中的数据会丢失。
• 文件系统一致快照(file-system-consistent snapshot): 快照时间点之前，虚拟机的文件系统被冻结，内存中的脏数据刷盘，快照完成后，文件系统解冻。这样的快照能够保证文件系统的一致性，即内存中的数据不会丢失。
• 应用一致性(application-consistent snapshot)：快找时间点前，虚拟机上运行的应用被冻结，内存中应用的所有脏数据刷盘，快照完成后，应用被解冻，这样的快照能够保证指定应用的数据是完整的，但不会保证文件系统也是完全一致的。

Quiseced Snapshot

后两种快照类型，也被统称为 Quiseced Snapshot 。使用 Quiseced Snapshot 需要特别的环境配置，主要的实现方式有两种：

• 使用客户机操作系统内置的应用服务或 VMware 提供的一致性驱动：
  • 版本较新的 Windows 客户机提供了 VSS(Volume Shadow Copy Service) 服务，VSS 提供了 Requester-Writer 来满足有冻结需求的应用和文件系统，在快照时间点前进行冻结和内存数据落盘并且在快照完成后进行解冻；
  • 对于版本较老的 Windows 客户机，VMware 提供了 SYNC driver 来支持应用和文件系统一致性快照；
  • 而在 Linux 客户机上，VMware 提供的 vmsync kernel module 仅支持文件系统一致性，而不能支持应用一致性。
• 脚本程序：如果是非 Windows 客户机，那么就需要编写针对指定应用的脚本，来对应用进行冻结或者解冻。

NOTE：上述列举的 VSS、SYNC driver、vmsync kernel module 和脚本，均要依赖 VMware Tools 来调用，所以即便客户机操作系统支持上述功能，仍需安装 VMware Tools 才能完美支持 Quiseced Snapshot。例如针对 VSS，VMware tools 就提供了 VSS support 功能，它是 VMware tools 和 Windows VSS 之间交互的桥梁。要创建 quiseced snapshots，VSS support 就必须被安装。

Quiseced Snapshot 的创建过程

1. 用户发出 quiesced snapshot 创建请求给 vCenter，vCenter 再给虚拟机所在的 ESXi 的 hostd service 发出快照创建请求。
2. ESXi 上的 Hostd service 将快照创建请求传递给客户机内的 VMware tools。
3. VMware tools 以 VSS Requester 的身份通知 VSS，VSS 再通知已经被注册的文件系统和各应用的 VSS writer 执行冻结操作。
4. 一旦完成冻结和内存数据落盘，VMware tools 就将完成结果通知 hostd service。
5. Hostd service 执行快照操作。
6. 快照完成后，按照前面的顺序再对文件系统和各应用进行解冻

创建快照

VMware 虚拟机创建快照之后会生成 3 个文件：

• vm_name-000001.vmdk (配置文件)： 虚拟机快照的元数据文件，记录了该次快照相关文件的信息，其中 000001 表示第一次快照。

# Disk DescriptorFile
version=3
encoding="UTF-8"
CID=a368e4cf
parentCID=2a9d852c
isNativeSnapshot="no"
createType="vmfsSparse"
parentFileNameHint="vm_name.vmdk"
# Extent description
RW 8388608 VMFSSPARSE "vm_name-000001-delta.vmdk"

# Change Tracking File
changeTrackPath="vm_name-000001-ctk.vmdk"

# The Disk Data Base
#DDB

ddb.deletable = "true"
ddb.longContentID = "6f4669ab6aec6b1b2cf5cc6ca368e4cf"

• vm_name-000001-delta.vmdk (二进制文件)：被称为快照数据文件或者 redo-log 文件(在 VDDK 相关的术语中，子磁盘 child disk、重做日志 redo log、差异链 delta link 表示同一个意思)，该文件用于保存快照时间点后虚拟机所产生的新数据，即快照数据。应用了 in-file delta technology 技术，初始大小为 16MB，会随着虚拟机数据落盘操作的增多，而按照 16MB 的大小进行增长(降低 SCSI reservation 冲突)，并且该文件的大小永远不会超过 Base Disk File 的大小。
• vm_name-000001-ctk.vmdk (二进制文件)：改变追踪文件，保存了自从上次快照以来的虚拟磁盘文件所发生变化的数据块偏移量信息。

创建快照的执行过程及原理

从上图可以看出 VMware 虚拟机快照的特性为：

• VMware 虚拟机使用的是链式快照。
• VMware 虚拟机的 Base Disk File 在创建快照之后，其访问权限为 OR 只读模式。
• 快照时间点之后新落盘的数据会写入快照数据文件中。
• 快照链上的任意快照文件的损坏都会导致虚拟机无法正常运行。

删除快照

从创建快照的特性中可以理解，如果希望在删除一个快照的同时保证虚拟机能够正常运行的话，那么就需要将该快照数据文件中的数据合并到父快照数据文件中，以此来保证虚拟机磁盘数据的完整性。

删除虚拟机快照一般会是以下两种情况：

• 待删除的虚拟机快照在快照链中：delta vmdk 中的数据会向父快照的 delta vmdk 或基础虚拟磁盘文件 base vmdk 合并，然后 delta vmdk 被删除。
• 待删除的虚拟机快照不在快照链中(VMware 支持独立快照)：不需要合并，直接删除快照数据文件。

删除 VMware 虚拟机快照的特点：

• 删除快照过程包括两个异步的操作：1. 从 Snapshot Manager 中将快照删除；2. vmdk 数据合并。如果 1 成功而 2 失败，就会残留 delta vmdk 文件，这样的话就需要手工进行快照文件的合并。
• 删除快照可能会带来大量的数据写操作，有时候可能需要删除很长的时间，并且期间虚拟机的性能会受到负面影响。
• 自从 vSphere 4 Update 2 开始，优化了选择删除所有虚拟机快照的过程，不再是顺序向下一层层的合并，而是各层分别直接合并到 Base vmdk 中。

CBT

CBT 是在 vSphere 4.0 版本引入的实现增量备份的功能，增量备份表示仅会备份两个时间点之间所被改变的差异数据，而这些差异数据往往就是虚拟机的快照数据。ESXi 为每个开启了 CBT 功能的虚拟机的虚拟磁盘都创建了一个 -ctk.vmdk 文件。CBT 会对磁盘带来一些性能损失，所以虚拟机的 CBT 的配置项默认为关闭状态。

CBT 的原理就是让 VMKernel 监控自上次快照以来有那些数据块被改变了，记录下这些被改变的数据块的偏移量，从而就能够获取这些被改变了的差异的数据。

CBT 执行过程

• Step 1：进行全量备份，即备份第一次虚拟机快照的快照数据。
• Step 2：通过 vShpere API(VirtualDisk.getBacking.getChangeId) 获取 Step 1 中所创建的快照对应的的 ChangeId。
• Step 3：执行第二次快照。
• Step 4：进行量备份，调用 vShpere API(queryChangedDiskAreas)，传递 Step 2 中获取的 ChangeId 和 Step 3 创建的快照的快找对象作为参数，以此获得自第一次快照时间点(前端点)到第二次快照时间点(后端点)之间发生改变的数据块，并备份这些数据块。

queryChangedDiskAreas

CBT 变化快获取函数 QueryChangedDiskAreas 的原型:

QueryChangedDiskAreas(snapshot, deviceKey, startOffSet, changeID)

- snapshot 当前的快照对象，即后端点；
- deviceKey 目标虚拟磁盘的 device ID；
- startOffSet 开始获取变化块的 offset；
- changeID 即前端点对应的 changeId；

其输出结果类似：

(117768192, 65536)
(132120576, 65536)
(145096704, 43122688)
(265289728, 65536)
(958398464, 65536)

每项的格式均为(offset，length)，表示一个发生改变的数据块的偏移量。

NOTE：在没有虚拟机快照的情况下开启 CBT 配置项并调用 queryChangedDiskAreas 函数时，changeId 为的实参应为 *。

开启 CBT

1. 关闭虚拟机
2. 右击虚拟机，选择 「Edit Settings」
3. 点击 「Options」
4. 点击 「Advanced section」 下的 「General」，点击 「Configuration Parameters」，开启「Configuration Parameters」 窗口后，查找 「ctkEnabled」项，设置为 「true」，并设置每个磁盘的「ctkEnabled=true」。
5. 开启虚拟机

设置成功后，会在虚拟机文件目录下生成 -ctk.vmdk 文件。

NOTE： VDDK API 能调用 configSpec.changeTrackingEnabled = new Boolean(true) 来动态的设置 CBT 状态，而不需要关闭虚拟机设置后才能设置。