在实际运维中，特别是p2v后的虚拟机，占用存储空间较大，能否收缩磁盘占用存储空间大小呢？

实际测试发现可行。

1.首先虚拟机存储占用空间查看方法：1）client在虚拟机概要面板右边存储使用情况中，浏览存储中进入虚拟机文件夹也可以看到vmdk大小。2）web client也是在概要面板查看，但没有刷新按钮，存储大小有更新，不方便了解情况。

2.测试虚拟机增加大文件后删除大文件，在存储空间查看界面就可以看到存储使用变大，但删除文件后，存储空间不会变小。

3.此时就要采用方法进行压缩磁盘。

方法如下：

首先要在系统上，把所有没用的数据写零，特别特别注意，执行下列命令之前，请确保存储空间剩余空间超过硬盘置备大小减去实际占用大小。及日常使用增长情况估算，对数据写零操作跟硬盘大小有关，硬盘较大，时间也较长。

linux下执行

dd if=/dev/zero of=/bigemptyfile

rm /bigemptyfile

windows下执行

sdelete -c -z C:\

再关闭系统，开始压缩硬盘文件

vmkfstools -K /path/to/disk-name.vmdk


注意：一些网站上介绍可以采用存储vmotion可以压缩，实测发现是有条件的，必须二个存储块大小不一致，而实际中，公司存储块大小基本是一致的，所以网上介绍的不对，详情请参考如下：


英文文档请参考链接http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004155

Storage vMotion to thin disk does not reclaim null blocks (2004155)

Symptoms

  • When using Storage vMotion to move a thin disk between two VMFS volumes with the same block size, null blocks are not reclaimed.

  • Null blocks are copied from source to destination resulting in a VMDK that is the same size, despite thin being chosen as the destination disk type.

  • When attempting to thin a disk after either using VMware Tools Prepare to shrink option or using a third-party product to zero disk blocks within a guest operating system, null blocks are copied.

Cause
This issue occurs when the destination datastore is of the same block size as the source datastore, regardless of whether the datastores are VMFS3 or VMFS5.

When the source filesystem uses a different  blocksize from the destination filesystem, the legacy datamover (FSDM) is used. When the blocksizes of source and destination are equal, the new datamover (FS3DM) is used. FS3DM decides if it will use VAAI or just the software component. In either case, null blocks are not reclaimed.
Resolution
This is expected behavior.

To work around this issue, Storage vMotion the virtual machine or VMDK to a datastore that has a different block size. This reclaims the zeroed out disk space.

To shrink a thin provisioned disk (VMDK):

  1. Use a third-party tool within the guest operating system to zero-out disk blocks that may have previously been written with data, but have subsequently been deleted.

  2. Storage vMotion the virtual machine or VMDK to a datastore formatted with a different block size.

For example, if the VMDK is on a datastore formatted with 2 MB blocks, format the target VMFS datastore with a 1 MB, 4 MB, or 8 MB block size.


To reclaim the unused space of a virtual disk in ESXi/ESX 4.1 or later:
Note: Where vmkfstools supports the -K option ( --punchzero), you can reclaim the zeroed blocks of thin-provisioned virtual disks without the need to clone to another VMFS datastore with a different block size.

  1. Ensure the disk has no Snapshots.

  2. In a Windows virtual machine, use the SDelete command (or a tool with similar functionality) to zero out all unused space. The syntax for the SDelete command is SDelete -z <driveletter>. If you use SDelete, ensure that you use version 1.6 or later.

    Note: Zeroing all unused blocks inflates the disk to its full size and converts it into an eagerzeroed disk. If the original disk is a thin provisioned disk, ensure there is sufficient space on the datastore to allow the disk to grow to its full size. For more information, seeDetermining if a VMDK is zeroedthick or eagerzeroedthick (1011170).

  3. Shut down the virtual machine or temporarily remove the virtual disk from the virtual machine to ensure it is not in use.

  4. Erase all unused blocks by running the command:

    vmkfstools -K /path/to/disk-name.vmdk

This option de-allocates all zeroed out blocks and leaves only those blocks that were allocated previously and contain valid data. The resulting virtual disk is in thin format. For more information on the vmkfstools command, see Removing Zeroed Blocks in the ESX Configuration Guide.
See Also
Request a Product Feature
To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.