This is the second part of this post. In the first post, I explained the fix and how it affected Windows. In this post, we will overview how the change affects Linux-based virtual machines. See the original post here:

In-Guest UNMAP Fix in ESXi 6.5 Part I: Windows

I posted about In-Guest UNMAP with Linux VMs in this post:

What’s new in ESXi 6.5 Storage Part I: UNMAP

One thing you can note is that automatic UNMAP works quite well, but manual UNMAP, like fstrim did not. So let’s revisit fstrim now that this patch is out.

To review, this patch now accepts all UNMAPs from a guest instead of blocking them if they are misaligned. UNMAPs that are aligned will be sent down to the storage, and the virtual disk will be shrunk in accordance to the space reclaimed by the guest and then UNMAP will be issued to the underlying blocks on the storage device itself so the space on the array can be reclaimed too. For misaligned UNMAPs, the virtual disk will not be shrunk, but the specific blocks will be zeroed out instead.

Manual UNMAP: FSTRIM

As explained in the original Linux post, when you mount a file system with the -discard option, Linux will issue UNMAP as soon as the file is deleted or moved to a different file system. This works pretty well out of the box with ESXi 6.5. But if you can’t enable discard (for some reason), or don’t want to–there is a manual command you can run to reclaim dead space as needed. This command is fstrim.

Unfortunately, fstrim doesn’t really adhere to alignment requests, so it just sends UNMAPs as needed. So basically the entire operation is blocked.

So, in this situation, I have some ISOs in a file system on a thin virtual disk on an unpatched ESXi 6.5 host. Here are the files in my VM, About 25 GB in total:

Here is the VMDK size on the VMFS:

And here is the hosting volume on the FlashArray:

I can then delete them. I don’t have the discard option enabled, so I have to manually run fstrim to reclaim the space. Since this ESXi host is not patched, fstrim will fail:

No space is reclaimed. Now if I vMotion this VM to a host with the UNMAP patch:

After the vMotion I will re-run fstrim:

No error! If I look at the VMFS, I see my virtual disk has shrunk from 25 GB to about 850 MB. So, certainly much better than nothing!

We can see on the FlashArray it is totally reclaimed:

This is due to the successful UNMAPs and the zeros for the misaligned ones (refer to the Windows post for more info on the zero behavior).

Automatic UNMAP: Discard Option

So does this change how automatic UNMAP behaves? Not really. I will put some files on my ext4 volume again on my thin virtual disk, so the VMDK is now ~25 GB. The VMDK called  unmaplinux_1-flat.vmdk is the one to look at here:

The array volume is back up to 15 GB (because of data reduction it is lower than what is written):

Now I will delete my files and we see the space is reclaimed and the VMDK is shrunk down to 750 MB:

Compared to the 850 MB, automatic UNMAP seems to have more aligned UNMAPs than fstrim, but not significantly. Mileage between the two methods, I would suspect, will vary depending on the files deleted etc.

From the FlashArray perspective though, it doesn’t matter. It basically 100% reclaims regardless to the method:

If I run the same test with that VM back on an unpatched ESXi host, my virtual disk is only shrunk to about 870 MB, so it is a bit less efficient without the patch due to the misaligned UNMAPs not being handled.

So definitely use this patch! Makes a big difference with Windows, and also allows the use of manual UNMAP in Linux.