This is the fourth in my series of what’s new in ESXi 6.5 storage. Here are the previous posts:

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

What’s new in ESXi 6.5 Storage Part II: Resignaturing

What’s new in ESXi 6.5 Storage Part III: Thin hot extend

Here is another post for vSphere 6.5 UNMAP! So many improvements and this is a big one for many users. Certainly makes me happy. Previously, in vSphere 6.0.x, when in-guest space reclamation was introduced, the enabling of change block tracking for a given virtual disk blocked the guest OS from being able to issue UNMAP to that disk and therefore prevented it from leveraging the goodness it provides. Rumor has it that this undesirable behavior continued in vSphere 6.5…

Let’s set the record straight: it works now with CBT enabled! Let’s review.

vSphere 6.0, In-Guest UNMAP and CBT

So when you add a thin virtual disk to a guest (and all of the other pre-reqs are fulfilled) the virtual disk will show up as supporting UNMAP.

There are a variety of ways to see this. Linux is a bit easier, but since Linux in-guest UNMAP didn’t even work in 6.0 (though it does in 6.5!), I will use Windows in this example.

So in this VM, I have two virtual disks (other than my boot disk). Both are thin:

I enabled CBT on the second thin disk which is at SCSI position 0:2

In Windows, there are a few ways to see VPD info. I like to use Virtual SCSI Explorer which you can get here.

Here are the printouts of the VPD B2h page for disks 1 and 2 respectively: 

You will note a few things. First, the field for “UNMAP command is supported” is turned off on virtual disk 2 (the CBT enabled one) and on for the first one (CBT disabled). Also, you will see that the second disk, while still thinly provisioned, is actually advertised as thick. You can also see this in the B2h page under the “provisioning type” field. The first disk is type 2 and the second is type 0. The SCSI block command (SBC) reference defines this field as such:

PROVISIONING TYPE field
Code Description:
000b The device server does not report a provisioning type.
001b The logical unit is resource provisioned
010b The logical unit is thin provisioned

The “b” refers to binary so basically if it is a “0b” or zero it doesn’t say what the disk type is, if it is “1b” or one it is resource provisioned (which I think means thick, but I haven’t totally verified that yet) and if it is “10b” which is two, it is thin. Which agrees with the screenshots above.

You can also see this in the Windows “Optimize Drives” utility.

Drive 1 (E:) is thin and drive 2 (F:) is just SSD. So Windows is not going to be able to issue UNMAP to the CBT disk.

So let’s look at 6.5!

vSphere 6.5, In-Guest UNMAP and CBT

This is a very different picture. So the same config. I have CBT enabled for my third disk (disk 0:2):

Now when you look in “Optimize Drives” we see both drives are thin and UNMAP will work!

So between this and Linux support (and well a million other cool features)–vSphere 6.5 is a very attractive upgrade.

So I do not have a backup product in my lab right now, but I would definitely like to hear how this interacts with backup products that use CBT. Please let me know if you do any testing.