Trim/Unmap support on GuestOS using FALLOC_FL_PUNCH_HOLE on HostOS (Thick provisioned vmdk)

Trim/Unmap support on GuestOS using FALLOC_FL_PUNCH_HOLE on HostOS (Thick provisioned vmdk)

0 Kudos


I'm spinning multiple VMs on top of a ZFS filesystem dataset

Each VM has its disk fully allocated (Thick Provisioned), but given that ZFS support native compression (and deduplication of data too) the actual on-disk-size of each vmdk file is only as big as the written data (or even 1 / N with dedup)
Generally speaking this is what should happen on any modern FileSystem than support sparse-file / Fallocate/ Hole-Punching
(This setup is better than sparse vmdk because it have superior performance generally and extra far better storage efficiency if combined with ZFS native compression and on-line data deduplication )

This work good and well while the GuestOS write data, but then when such data is deleted it is never freed-up on the Host side because the HostOS can never know (if not hinted) that this range of the vmdk file has been "released" by the upper GuestOS

For this, at least on linux based OSes there is the fallocate( FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE ) that can "punch hole" in the file and free the not used space (logical size of the file stay the same but physical on-disk size shrink as needed)

But when configuring a VM on Workstation 17 with:
- Thick Provisioned Disk (single file)
- I/O controller : LSI Logic SAS
- Disk Type : NVMe

The GuestOS (Windows11) report that the disk do not have Trim support
But Trim support in this case should be supported and then converted in a fallocate call on the vmdk file by the HyperVisor (VMWare Workstation)

How can I can enable this behaviour? I already tried adding to the .vmx configuration file:
- nvme0:0.virtualSSD = "TRUE"
- disk.scsiUnmapAllowed = "TRUE"

But GuestOS is still reporting no Trim support


Also posted here


My preference would be a Guest should NOT have trim support.    The idea behind virtualization is to 'hide' the underlying physical hardware.   I would step back and look how I could support this on the host machine and disks.



It is impossible for the host machine to know which data in the guest disk it is actually used and which is not
For a full explanation on why see my answer in the other thread

While it is true that the Trim command (that is a sata command) is mostly associated with ssd it also true that the SCSI variant UnMap (that is the same thing) exist for this exact purpose of virtualisation and disk-provisioning