ONTAP Discussions

VAAI Unmap delete status: unsupported NetApp FAS Array DataOntap 8.2.1


Hi All


Quick run up of our environment:


VMware V5.0.0 Update 3 Build 1918656 with vCenter 5.0.0 U3. 

NetApp FAS8020 running Data ONTAP 8.2.1 7-Mode using Thin Provisioning Flex Volumes

Using VSC 4.2.2 plugin    

For purposes of test this piece I created a thin provisioned 100GB LUN with a 55GB thin provisioned VM


I am looking to use the unmap to reclaim space from our thin provisioned volumes on our NetApp, we are using thin provisioned VM disks however some are thick provisioned VMs as well. When I mean the volume is thin provisioned I mean when you setup a new volume on the NetApp array and tick the option to thin provision the volume as shown below:


06-07-2015 15-01-43.jpg


however I have run into a few problems and am struggling to understand why I am unable to reclaim space on a test thin provisioned volume I created. 

As a test I storage vmotioned a VM no longer needed to a test volume which utilised the space on the LUN, I then storage vmotioned it back to another volume. it removed the space on the VMware datastore side however not on the volume capacity on the storage. However having a read of VAAI in detail I am unsure why the below is showing as thin provisioning status: unknown. I can confirm the volume is thin provisioned and NOT thick provisioned. 

06-07-2015 15-18-22.jpg


When looking at the VAAI status it shows the delete as unsupported. 

06-07-2015 15-10-00.jpg

So I attempt to use the vmkfstools command to reclaim the space: 



When I tried the vmkfstools -y percentage_of_deleted_blocks_to_reclaim command it looked like it worked, tried it few different times with different %

06-07-2015 15-23-56.jpg

Volume status on NetApp side shows that the space hasn't been recovered and still shows at 39% used, with 61.28GB even though there are no VMs on this volume. 

06-07-2015 15-24-11.jpg

On VMware side, it shows as space feed as expected. 

06-07-2015 15-27-28.jpg

Does anyone know why I might be seeing this behaviour? I know on earlier versions of 5.0 there was issues and it has to be run manually however I am on a much later release of 5.0 and I thought the vmfkstool utility allowed it to be run manually?


Any help would be most appreciated.




Re: VAAI Unmap delete status: unsupported NetApp FAS Array DataOntap 8.2.1


I have found this article which relates to what I am seeing:


VMware KB: Thin Provisioning Block Space Reclamation (VAAI UNMAP) does not work


07-07-2015 09-14-01.jpg


When I check the VMware compatibility matrix it is showing as VAAI thin provisioning space reclamation is not supported. I am using a FAS8020 array, I would have thought that this SAN considering the age would support this feature? or is it an issue elsewhere with the environment? Looking at whether I upgrade to a newer version of ONTAP or VMware ESXi it doesn't make any difference.


Is the Thin Provisioning space reclamation only a feature on very high end SANs?


Is there anything I can use to reclaim space?



Re: VAAI Unmap delete status: unsupported NetApp FAS Array DataOntap 8.2.1


Hey Mate,


You might want to check this link,



  1. In order for these features of VAAI Thin Provisioning to work as expected, the LUN must have space allocation enabled. This is NOT the default in any version of Data ONTAP. For Data ONTAP7-Mode, run the lun set space_alloc <lun path> enabled command.
    For clustered Data ONTAP, run the lun modify -vserver <vserver name> -space-allocation enabled -path <lun path> command. For more information, see 3013047: What does the LUN option space_alloc do?


It says that the configuration you have is supported for space reclaimation unless you are using NFS.

If you are running ontap version 8.2 or higher you need to set space_alloc on the lun to enable space reclaimation.





View solution in original post

Re: VAAI Unmap delete status: unsupported NetApp FAS Array DataOntap 8.2.1




Its' been a while since this post, but yes your last post I managed to find and as you say that was the exact issue, by default that setting was off on the filer.


I have to say the whole process was a nightmare, long winded using vSphere 5. My understanding is that this issue is now far better with vSphere6, we have just recently implemented this in our environment so I am eager to see if this process is better but this setting lun set space_alloc <lun path> enabled  still needs to be set on the filer before any reclaim of space takes place.



Earn Rewards for Your Review!
GPI Review Banner
All Community Forums