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.
7 Replies to “What’s new in ESXi 6.5 Storage Part IV: In-Guest UNMAP CBT Support”
Hi Cody, this is great! Did you test with local disks ?
I replied on Twitter, but for anyone else that is curious this was only tested on SAN storage, so I am not sure if it will work on local storage. I am not entirely sure if thin reduction support to the guest requires UNMAP support on the array. My guess only EnableBlockDelete requires this. After thinking about it, I would suspect that this will work on local disks as long as you are using thin virtual disks.
good stuff….keep it coming!!!