我有以下环境
- VMware ESXi 5.5 U3 免费，使用 VAAI 数据存储
- Linux 虚拟机
- CentOS 6.8，2 个精简配置磁盘（PVSCSI 精简 VMDK）
- 第一个磁盘具有参考操作系统分区（用于启动的分区，然后是具有常规 root/home/swap LV 的 LVM）
- 第一个磁盘是 100GB 精简配置的精简 VMDK（约 12GB 物理空间）
- 第二个磁盘是我添加的 2TB 精简配置精简 VMDK 磁盘
- /opt 文件夹目前是空的
- 操作系统是最近安装的，所以没有什么问题
我打算使用第二个磁盘来托管 /opt 挂载点，因为我将添加将来可能需要增加的数据。
这里的问题是通过 GUI LVM 管理器添加第二个磁盘。LVM 管理器可以正常查看磁盘。将磁盘添加到现有卷组或新卷组似乎可以正常工作。添加没有文件系统的新逻辑卷似乎可以正常工作，而不会导致底层 VMDK 文件扩展。
但是，当我尝试配置 ext4 文件系统并点击“确定”时，LVM 管理器 GUI 停止响应，底层 VMDK 文件开始膨胀。从表面上看，它似乎正在执行某种完全格式化，写入精简配置的磁盘，导致其膨胀。
有没有办法避免在添加 LV 时导致底层 VMDK 文件的物理大小增加？扩展是由于完整格式，还是因为 LVM 试图将 /opt LV 挤压到文件系统的中间，因此它实际上是将操作系统数据复制到分区的末尾（这意味着只需等待，它最终会完成而不会导致磁盘完全膨胀）
更新-1
做了一些实验，似乎对于 2TB 精简配置的 VMDK，ext4 格式化既慢又导致大约 32GB 膨胀。所以至少不是完全膨胀。在 VM 停止的情况下，使用 vmkfstools 的 punchzero 操作恢复了大约 31GB 并缩小了 VMDK，如果随后执行 VAAI UNMAP，还将从后端数据存储中完全释放 31GB。清理操作是 IO/IOps 密集型的，因此请为数据存储的痛苦做好准备。有很多手动步骤，但如果您有一个一次性数据存储并且正在构建 VM 模板，这可能是值得的。
部分解决方案可能是sparse_super对 LVM LV 进行格式化，因为这将导致 ext4 在写入块时即时格式化，但这会推迟痛苦，并且无法从 LVM GUI 执行此操作。