You just purged 300 GB of legacy database files inside a Windows VM, but checking the vSphere Client, the Datastore remains glowing red at 92% capacity? Not a single megabyte was released. This is a classic scenario that every sysadmin managing Thin Provisioned virtual disks has encountered.
The root cause lies in how guest operating systems handle file deletions. When you delete a file, the guest OS merely updates its index table (the MFT on NTFS or Inodes on ext4/xfs). It marks those blocks as “available for overwrite” without zeroing out the actual data. The underlying ESXi hypervisor receives no notification of this release, so it continues to allocate those blocks for the VMDK file. Over time, virtual disks expand continuously, needlessly consuming valuable capacity across your SAN/NAS array.
In our infrastructure—an 8-node ESXi cluster hosting over 140 virtual machines connected to a Dell Unity storage array via 16Gbps Fibre Channel—we run this exact procedure during every major maintenance cycle to reclaim terabytes of wasted storage.
Three Common Methods for Space Reclamation
Depending on whether the VM can be powered off and your Datastore architecture, there are three primary approaches:
- Method 1: Storage vMotion with disk format conversion — Migrate the VM to another datastore, convert it temporarily to Thick Eager Zeroed, and migrate it back to Thin.
- Method 2: Guest OS Zeroing combined with vmkfstools disk shrinking — Fill free space with zeroes inside the guest OS, then run a punch-zero command from the ESXi shell.
- Method 3: SCSI UNMAP (esxcli) or native VMFS-6 automation — Issue SCSI UNMAP commands to release unallocated datastore blocks back to the SAN/NAS array.
Detailed Comparison of Pros and Cons
1. Storage vMotion
- Pros: Handled entirely through the vCenter UI with zero downtime, keeping virtual machines online throughout the process.
- Cons: Requires a secondary datastore with free capacity at least equal to the VM size. The migration also heavily consumes storage network bandwidth (often pushing throughput to 300–500 MB/s).
2. Guest OS Zeroing Combined with vmkfstools Punch Zero
- Pros: Shrinks the
-flat.vmdkfile down to its actual used size. Highly effective for standalone VMs after massive data cleanups. - Cons: Requires VM downtime. The initial zero-writing phase can spike storage IOPS and temporarily inflate the VMDK file to its maximum provisioned size.
3. SCSI UNMAP Command (esxcli) and Automatic UNMAP in VMFS-6
- Pros: No VM downtime required. VMFS-6 runs automatically in the background using asynchronous space reclamation, throttled at 25 MB/s to 100 MB/s.
- Cons: Only reclaims space at the datastore level (e.g., after deleting entire VMs or snapshots). It does not shrink active VMDK files unless guest-level blocks have already been handled.
Which Method Should You Choose in Production?
- When a maintenance window (downtime) is available: Use Method 2. This is the most thorough way to shrink specific VMDK files.
- For 24/7 mission-critical production systems: Leverage Storage vMotion if your infrastructure has adequate spare datastore capacity.
- After deleting 5–10 lab VMs totaling hundreds of gigabytes: Execute
esxcli storage vmfs unmapto immediately reflect freed space on your SAN/NAS storage array.
Step-by-Step Implementation Guide
Step 1: Clean Up Stale Blocks Inside the Guest OS
First, we need to zero out unallocated space so ESXi can identify which blocks are truly empty.
For Windows Server: Download the official SDelete utility from Microsoft Sysinternals. Open PowerShell as Administrator:
# The -z switch zeroes out all free space on drive C:
sdelete64.exe -z C:Note: While SDelete is running, the VMDK file will inflate to its full provisioned capacity. Ensure the datastore has sufficient free space before proceeding.
For Linux (RHEL, Ubuntu, Rocky Linux):
# Run fstrim to discard unused blocks (requires VM SCSI controller compatibility)
sudo fstrim -avIf the disk does not directly support TRIM, fill the free space with a zero-byte file and then delete it:
# Write zeroes to a dummy file until the disk is full, then delete it
dd if=/dev/zero of=/var/tmp/zero.fill bs=1M status=progress; rm -f /var/tmp/zero.fillStep 2: Shrink the VMDK File Using vmkfstools (Offline)
Power off the target virtual machine. Establish an SSH session to the ESXi host hosting the VM and navigate to the VM directory:
# 1. Navigate to the VM directory
cd /vmfs/volumes/Datastore_SSD/AppServer01/
# 2. Check for snapshots (THERE MUST BE NO SNAPSHOTS)
ls -l *delta* *sesparse*
# 3. Shrink the disk (punch zeroes)
vmkfstools -K AppServer01.vmdkThe vmkfstools -K command scans the entire disk file. Wherever zeroed blocks are found, ESXi unmaps the metadata pointers and frees the physical storage blocks. A 500 GB virtual disk containing only 120 GB of actual data will shrink down to exactly 120 GB on the datastore.
Step 3: Reclaim Datastore Space Back to SAN Storage (UNMAP)
Once the VMDK has been shrunk, or after completely deleting large VMs, instruct the SAN array to reclaim unmapped physical storage:
# List datastores and retrieve the Volume UUID
esxcli storage filesystem list
# Run UNMAP with a 200 block count to prevent storage I/O congestion
esxcli storage vmfs unmap -u 652a9f14-38b81234-5678-001b21xxxxxx -b 200Each block corresponds to 1 MB. The -b 200 flag limits reclamation to 200 MB chunks per cycle, safeguarding the SAN array’s I/O queue against saturation.
Three Essential Rules to Avoid Risk
- Consolidate and remove all snapshots before running vmkfstools: Executing
vmkfstools -Kon a base disk while delta snapshots exist can corrupt the entire snapshot chain. - Do not set the block count (-b) too high: Values exceeding 500 can overwhelm the SAN array’s queue depth, resulting in elevated I/O latency for all VMs sharing that LUN.
- Prefer VMFS-6: Always format new datastores with VMFS-6 so that automatic asynchronous UNMAP operates in the background, eliminating the need for manual off-hours operations.
