%20%E4%B8%8A%E7%9A%84%E5%9D%97%E4%BD%BF%E7%94%A8%E6%83%85%E5%86%B5.png)
这个问题类似于 精简配置 Linux 服务器的最佳实践（在 VMware 上）
然而我的问题略有不同。
我们已经对相当多的服务器 (win/linux) 进行了 P2V，并且我们需要使用块级复制，因此我们在迁移时使用了精简配置，并且我们已经在生产中设置了这些服务器，假设精简配置的使用将与服务器使用的实际数据一致，但事实证明我们错了，因为我们看到 VMDK 增长，尽管由于日志/备份/其他进程接触块，客户虚拟机内的实际磁盘使用率很低，并且 VMDK 只能增长而不能缩小。
我们不希望这种情况在数据存储区完全填满的某个晚上对我们造成影响。
我们研究了 sdelete / punching zeros 等工具，但这需要我们删除所有快照，而我们的备份系统使用 CBT，因此我们无法做到这一点。此外，这不适用于 Linux。
我们还研究了一些建议，我们应该只使用 V2V 并创建一个不同大小的新磁盘，但考虑到服务器已经上线，这项工作量太大了。
我没有对设置进行大的更改，而是考虑使用 Windows/Linux 磁盘工具将操作系统内的 FS/Volumes 缩小到合适的大小，这样即使一个虚拟机使用了其所有可用空间，主机也不会耗尽数据存储空间。
示例数字：我们的数据存储：1 TB。虚拟机的预配置使用量：2TB（THIN）虚拟机的实际使用量（100 GB）
现在，如果我们使用 Windows 中的 DiskMgmt 工具将基本卷缩小到大约 200 GB，并在 Linux LVM 中将 LV / VG 和分区更改为大约 200G，这样 VM 就有一定的增长空间，但不会增长太多。
我的问题是，这是否可行，即 vmdk 增长将在 OS 磁盘部分的大小时停止，并且这是否会成为精简/厚配置之间的一种中间立场，或者这是否不起作用并且说精简配置的虚拟机 VMDK 仍然会大大超出我们在操作系统级别设置的分区/卷限制？
一个附带问题是：如果数据存储区填满了，会发生什么情况？我们是否仍然可以使用 Vsphere Web 客户端/等或 ssh 轻松地将一些虚拟机移动到另一个数据存储区，或者这是否会是一场纯粹的灾难？
答案1
我自己来回答这个问题。
缩小文件系统确实可以解决问题，即磁盘使用率不会超出某个限制，但是当文件系统缩小时会出现一些问题，操作系统会移动所有文件/根据分区开头的磁盘映射对它们进行排序，而这个操作实际上会导致 Think 配置的 VMDK 增长到相当大的大小，最高达实际大小的 2 倍。
就我们个人而言，我们最终对每台服务器进行了 V2V，并将超额配置调整到可管理的大小，这比缩小/使用 FS 级别要容易得多，而且耗时更少。