VMware 虚机磁盘在 ESXi 宿主机上的文件
虚拟机的虚拟磁盘由ESXi宿主机上的三个文件组成,下面是虚拟机centos(虚拟机名称)第一个磁盘对应的三个文件：
centos.vmdk （配置文件，大小 633 字节）
该文件保存的是磁盘的元数据，包括下面两个文件的信息centos-flat.vmdk （二进制文件，大小 12884901888 字节）
该文件是 Extent description 文件，二进制数据保存在这个文件中。下面会介绍使用API获取该文件中数据的方法。centos-ctk.vmdk （二进制文件，大小 78694 字节）
该文件是 CTK 文件，CBT（数据块修改跟踪）启动时自动生成该文件。
快照（Snapshot）
虚拟机的快照是虚拟机在某个时间点的状态和数据，其中，状态是指虚拟机的状态，包括运行状态、配置等；数据是指虚拟机磁盘中的数据。
快照的基本操作包括：
创建快照（create）
删除快照（delete）
合并快照（consolidate）
恢复到快照（revert）
创建快照
在虚拟机上创建一个快照，除了快照定义文件以外，磁盘中新增了三个文件：
centos-000001-ctk.vmdk –> ctk 文件
centos-000001-delta.vmdk –> delta 文件
centos-000001.vmdk –> 非二进制文件
如果再创建第二个快照，文件变化如下：
图中绿色部分是从虚拟机角度看数据；中间的红框是delta vmdk中的数据；最下面的红框是base vmdk中的数据。
现在简单总结下VMware快照的特点：
快照保存虚拟机在某一个时间点的状态和数据；
对虚拟机做快照，相当于将虚拟机当前的磁盘设为只读模式，然后创建 delta vmdk 文件，它将会接受新的数据写操作。在存在多个快照的情况下，之前的快照磁盘都变为只读；
写损失，写数据遵循Copy-on-write 机制，按照数据分块，当需要修改某一块中的数据时，先将它从父vmdk中拷贝到 delta vmdk，然后再对它修改；
读损失，读取某一块数据时，ESXi 需要判断从哪里去读，对于没有修改的数据块，从父vmdk读；对已经修改了的数据块，从 delta vmdk 读。可见，客户端的一次读操作，可能需从不同的vmdk上读取数据；
delta vmdk 的大小不会超过base vmdk的大小，因为极限情况是所有的数据都被拷贝到delta vmdk，并且都没修改；
由于快照会带来读和写损失，因此一个虚拟机不能有太多的快照，vSphere 限定一个虚拟机最多有32个快照，但是建议最多只有2-3个，而且快照的保留时间不超过一天。
删除快照
快照只是虚拟机内部数据，保存的是过去某时间点虚拟机的状态，对外部不可见，因此，删除快照不能影响虚拟机当前的状态和数据。
删除快照有如下三种可能：
1.快照是基于原始虚拟机的：delta vmdk 中的数据会向 base vmdk 合并，然后delta vmdk 被删除。（如图中s1）
2.待删除快照在虚拟机的数据路径上：delta vmdk 中的数据会向父快照的vmdk合并，然后delta vmdk被删除。（如图中s2）
3.待删除快照不在虚拟机的路径上：不需要合并，直接删除。（如图中s3）
总结下删除快照的特点：
删除快照意味着快照之后的改变会被合并进快照之前的数据，因此，虚机再也无法回到所做快照之时的状态了。
删除快照过程包括两个异步操作：从 Snapshot manager 中将快照删除； vmdk 数据合并。如果第一步成功而第二步失败，那么将有残留的 delta vmdk 文件被保留下来，这是就需要下面将介绍的手工合并操作。
删除快照可能会带来大量的数据写操作，这期间，虚机的性能会受到影响。
删除快照有时候要花费很长的时间，特别是对于长时间存在的大容量磁盘的快照。 VMware 专门出了一个接口来让用户估计所需要的时间：Estimating the time required to consolidate snapshots during the snapshot removal for VMware ESX and VMware ESXi (2053758)
当删除所有快照时，自从 vSphere 4 Update 2 开始起过程有了优化，不再是重定向一层一层地合并，而是各层都直接合并到 base disk
快照合并（consolidation）
上面谈到了快照删除后 vmdk 数据合并可能会失败。这种失败会带来很多问题，包括不必要的磁盘空间占用，以及虚机性能下降。
因此，当出现这种情况时，vCenter 会向用户提示需要做合并了。该操作会检查虚机当前所有的 vmdk 分层，将冗余的 delta 文件先合并再删除。
恢复到快照（restore）
恢复到快照就是将虚拟机的base vmdk指向目标快照的vmdk，其结果是自目标快照创建后的一切改动都没有了。
VMware API
VMware 提供非常丰富的API，如下图所示：
其中，我们可以将与备份相关的API分为两类：
一类是控制平面的API，它们主要用做管理 vSphere 虚拟化环境；
另一类是数据平面API，它们用于操作虚机的虚拟磁盘。
VMware API 和SDK
VMware 通过 Web Service 向客户端提供访问接口，这些接口可用于管理虚拟机和其他虚拟设备， 包括数据存储（datastore）、网络（network）等设备； 它还提供了包括Java、.NET、Python、Perl、REST以及Ruby等几种语言。对于其他语言，则需要通过 SOAP 协议访问其 web service， gSoap 是一种比较常见的用于C/C++语言编写 web service 客户端程序的套件。
VDDK 和VADP
VDDK 全称是 Virtual Disk Development Kit（虚拟磁盘开发包），它能帮助开发人员创建访问虚机存储的应用。
VDDK 基于 Virtual disk API。Virtual disk API，即 VixDiskLib，是一组操作 VMDK 格式的虚拟磁盘文件的函数。它的主要功能包括：
create, convert, expand, defragment, shrink, and rename 虚拟磁盘文件
创建 redo logs 和 删除 vmdk 文件
访问 vmdk 文件中任意数据，以及读取元数据
连接到远端 vSphere 存储，使用高级传输方式，包括 SAN （备份程序所在的服务器能够直接通过 FC 或者 iSCSI 和虚机磁盘所在的存储连接），hotadd （虚拟磁盘附加到备份程序所在虚机成为其一个磁盘） 和 LAN （备份程序通过 LAN 访问虚拟磁盘）
VADP 全称是 VMware Storage APIs - Data Protection（VMware存储API-数据保护），它使用 virtual diskAPI 和部分 vSphre API 来创建和管理虚机的快照，支持全量和增量备份。
(Changed Block Tracking， 块修改跟踪)
CBT 是 VMware 在 vSphere 4.0 版本引入的为了实现增量备份的一个功能。
相对于全量备份时将vmdk 的全部数据块都保存下来（左图），基于 CBT 的增量备份只保存自从上次备份以来的发生了变化了的数据块（上图）。
ESXi 为每个开启了 CBT 的虚机的虚拟磁盘都创建了一个 ctk 文件，它用于保存变化块的元数据。
该功能将会对磁盘带来一点性能损失，因此，不使用的时候，可以关闭它，但是它对备份带来的好处是显而易见的。
虚拟磁盘传输模式（Tranport modes）
这个传输模式是指虚拟机或者虚拟机快照的虚拟磁盘中的数据被传送到备份程序的传输方式。
VMware 在不同的环境中支持使用不同的传输模式，好的传输模式能大大提高传输传输效率。
SAN 模式
这种模式要求 VMware 备份程序所在的物理服务器能够通过 FC/iSCSI/SAS SAN 网络访问到虚拟磁盘。
对备份来说，这是效率最高的传输模式。这种传输模式下，VADPAPI 从vCenter 或者 ESXi 上获取 VMFS LUN 的信息，然后再基于这些信息从 VMDK 所在的 FC/iSCSI/SAS LUN 中直接读取数据。下图是一个示例：
要使用这种模式：
备份程序需要运行在物理服务器之内，该服务器必须能够通过SAN网络访问到VMFS LUN。
SAN 模式对备份来说是最佳选择，但是对恢复来说却不是。
LAN(NBD) 模式
这种模式下，ESX/ESXi 主机从其存储中读取数据，再通过 LAN 网络发到备份程序所在的主机。
这种模式支持任何类型的存储。备份程序可以运行在一个虚机之内。需要的时候，可以使用 SSL 加密（NBDSSL）。
HotAdd 模式
当备份存储运行在虚机之内时，可以利用 ESXi 的 SCSI HotAdd 特性来将虚拟磁盘直接挂在到该虚机上成为其一个本地磁盘。
这种模式只能用于 SCSI 模式的虚拟磁盘，而不适用于 IDE 类型的。
如果虚机的快照有两个虚拟磁盘，当备份程序在其所在的虚机（proxy）上使用 hotadd 模式连接到第一个磁盘后，你可以在 proxy 上看到该磁盘以及它的两个分区
传输模式的选择
备份程序都是调用 VDAP 的 Connect/ConnectEx 接口来和 vmdk 建立连接的。
如果不指定传输模式的话，VADP API 会按照顺序，依次尝试 san，hotadd 和 nbd 三种模式，直到有一种成功或者全部失败。
当有成功时，客户端程序可以调用GetTransportMode() API 返回该连接所使用的传输模式。
当然，客户端程序也可以指定特定的传输模式。在操作结束后，客户端程序需要调用 Disconnect API 来断开已经建立的连接。
