XenServer中VM的存储格式对空间以及性能的影响

 在XenServer中，基本的存储库（SR）、物理块设备、虚拟磁盘映像、虚拟块设备之间的关系如下图：

其中，PBD为物理存储设备的抽象，基本无法改变，SR为XenServer对物理存储设备的抽象，起到组织管理的作用，SR的类型对虚机VDI的格式以及性能有一定的影响，但是SR的类型受限制于物理存储的形式，所以，暂停也跳过，VBD与VDI对应，而最终VM拿到的虚拟块设备VBD，则为VDI的虚拟，所以，SR中VDI的格式对存储空间消耗以及性能产生比较重要的影响。

基于不同的SR，一般情况下，VDI的物理保存方式有三种：

• File-based VHD（基于文件的VHD）：VM的image将会以精简置备（thin provisioning）的VHD格式保存在本地的EXT格式的SR或者共享的NFS的存储上。
• LVM-based VHD（基于LVM逻辑卷的VHD）：默认XenServer连接光纤（LVMoHBA）、iSCSI（LVMoISCSI）或者SAS（LVM0HBA）的本地存储，以及基于SAN附加的LUN，这些类型存储上的VDI，都是卷管理器中的卷，并以VHD格式保存，以支持快照和克隆引用节点的精简置备。
• LUN per VHD（每个LUN作为一个VDI）：这种类型主要指Netapp，Equallogic或者StorageLink提供的存储类型，这种方式由于会有特殊的插件提供支持，所以VDI会直接抽象为存储中的一个LUN，然后直接附加到VM。很明显，该种方式对存储性能的利用最好，而且能够更方便的管理存储，因为都是基于存储的管理功能，而不是XenServer本身的功能。

每种VHD类型，有每一种的特点，以及对存储空间的占用，存储的性能损耗都不一样：

首先说明一下，在XenServer中，模板生成虚机都是采用VDI连接的形式进行管理的。

由于每VDI使用一个LUN，这种形式，VHD的管理由存储控制器来管理，所以，其大小和性能由存储的管理方式来决定，所以这里就不准备详细讨论了， 但相对于其他两种形式而言，每VDI一个LUN的形式，其性能最高。比如，存储支持Thin Provisioning，那么空间占用将会由实际大小决定，不管XenServer声明该VHD的大小是多少，如果不支持，那么声明多少，将占用多少。性能，由存储管理方式决定，比如，跨多少磁盘，RAID的级别等等。

下面，主要介绍基于LVM和文件的两种VHD对存储空间的占用大小以及管理方式。

如上图：假设，XenServer创建一VM，并分配20G大小的空间给VM，VM实际使用数据空间为10G，然后我们基于该VM复制两个出来，然后第一个VM，改变了5G的数据后，做快照，成为最终的VM1，而VM2虚机改变了2G的数据。

基于该假设，存储中，VDI的空间消耗如上图所示。

首先，基于LVM的VHD格式，最开始20G的VM，需要消耗20G空间，在转成模板以后，copy出VM1和VM2以后，原始VM空间将会压缩到实际大小10G，然后形成两个链接，供VM1和VM2使用，VM改变5GB大小以后，快照，则，快照只保存更改的数据5GB，新的VM1，将会占用20G空间，而VM2 copy出来也会占用20G空间。

而基于文件的VHD格式，很容易理解，再任何时候，VM以及快照的大小为实际改变大小。

基于VHD克隆或者copy的VM，每个子VM都会形成一个链，修改写入新的VDI，读取则从父模板读取，如果进一步，讲子VM在克隆，这样，链接将会越来越长，存储的性能也会越来越差。XenServer中，最大的链接长度为30，使用copy命令复制VM，讲会将链接长度重置为0.

VHD链的合并

VHD链接树会不断的创建、修改、删除。在删除链中的VDI时，XenServer会合理化链中的其他VDI，并删除非必要的VDI。合并过程为异步运行，且对于SR来说，永远只有一个合并过程处于活动状态，该过程由SR主节点主机的线程处理。

这里说明一点，VDI的删除，会导致VHD链的合并，但不是马上合并，该操作为异步执行，但最终会合并，而不是只删除链接节点名称保留直接链接。