At 2 AM, my phone vibrated uncontrollably. The Zabbix monitoring system was flashing red: a 10TB storage LUN on the company’s SAN had less than 150GB of free space remaining. This was a critical alert. If the physical disk fills up, all virtual machines (VMs) will be suspended immediately, causing a total system outage.
After a quick check, I found a Windows Server 2019 instance consuming 500GB of physical space on the SAN. Curiously, Windows reported only 120GB of data being used. Why was there a ridiculous 300GB discrepancy? How could I reclaim this storage without reinstalling the OS? Drawing from my experience managing an 8-host ESXi cluster, I’ll show you how to resolve this once and for all.
Why do VMDK files expand but never shrink automatically?
The main culprit is Thin Provisioning. Think of it like a balloon: it’s easy to blow air in, but when you let the air out (delete data), the balloon’s skin (the VMDK file) retains its stretched size. When you delete a file in Windows or Linux, the operating system only marks those blocks as “free” at the software level. VMware, at the lower level (Hypervisor), still sees those blocks as containing old data and refuses to release the space.
Method 1: Shrinking VMDK on VMware Workstation (For personal use)
If you’re running VMs on a laptop or PC, VMware Workstation has a built-in GUI tool to do this quickly.
First, clean up the VM internally. Go into Windows, delete temporary files, empty the recycle bin, or run Disk Cleanup. This ensures old data blocks are freed as much as possible before shrinking.
Next, use the Clean Up Disks feature:
- Shut down the VM completely (Power Off).
- Right-click the VM name and select Settings.
- Select Hard Disk, look to the right for the Utilities button, and choose Clean Up Disks.
The system will scan and reclaim empty blocks. However, if the disk is heavily fragmented, this tool may not always be as effective as expected.
Method 2: Shrinking VMDK for Windows (100% effective on both ESXi and Workstation)
This is a “brute force” but extremely effective method that I use frequently. We’ll use the SDelete tool from Microsoft’s Sysinternals suite.
Step 1: Fill free space with zeros. Download SDelete to the VM, open CMD as Administrator, and run:
sdelete.exe -z c:
This command writes zeros to all currently free space on drive C. Don’t panic if you see the .vmdk file ballooning to its maximum size. We are intentionally filling it up to prepare for the “trimming” step next.
Step 2: Perform the Shrink. Once SDelete finishes, shut down the VM. If using Workstation, open CMD on the host machine and run:
"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -k "path-to-your-file.vmdk"
For ESXi environments: You need to SSH into the host, navigate to the VM’s directory, and use the vmkfstools command with the -K (Punching holes) option:
cd /vmfs/volumes/your-datastore/vm-directory/
vmkfstools -K your-disk.vmdk
The -K command identifies blocks containing zeros and releases them back to the storage pool. During that night shift, this command helped me reclaim over 300GB in just 20 minutes.
Method 3: Handling Linux VMs with the dd command
For Linux distributions like Ubuntu or CentOS, we don’t use SDelete. Instead, we use the legendary dd command to create a junk file filled with zeros.
Run this inside the Linux VM:
dd if=/dev/zero of=/wipefile bs=1M
rm /wipefile
The command above creates a file named wipefile that consumes all remaining free space on the disk, then deletes it. At this point, the free blocks are filled with zeros. Finally, just shut down the VM and run the vmkfstools -K command on the ESXi host as described above.
Battle-Tested Experience: Critical Notes
Interfering with virtual disk file structures always carries risks. Here are three rules I always follow:
- Backup is Mandatory: Clone the VM or back it up with Veeam before proceeding. If there’s a power outage or the host hangs during shrinking, the .vmdk file’s structure can easily be corrupted.
- Delete All Snapshots: You cannot shrink a disk if the VM still has snapshots. Consolidate all snapshots before starting the process.
- Check Physical Capacity: When running SDelete, the VMDK file will temporarily expand to its Maximum Provisioned size. Ensure your physical hard drive has enough space for this temporary increase.
If you’re using ESXi 6.7 or later and your SAN supports VAAI, look into the UNMAP command. It allows Windows to reclaim space automatically without manual intervention. However, for older systems or complex configurations, the manual techniques above remain the most reliable solution.
I hope this article helps you successfully rescue drives crying out for space. If you encounter a “Failed to open the disk” error, leave a comment below and I’ll help you out!
