We are running a Windows Server 2012 R2 Hyper-V Cluster. Since we migrated the storage from 7-mode to cmode 9.1 we are not able to reclaim lun space via the Powershell Toolkit.
Tested the latest releases 4.3 and 4.4 of the Data Ontap Powershell Toolkit. Here is the output:
PS C:\Windows\system32> Invoke-NcHostVolumeSpaceReclaim C:\ClusterStorage\Volume2
Reclaim volume free space
Are you sure you want to reclaim free space on volume C:\ClusterStorage\Volume2\?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y
Invoke-NcHostVolumeSpaceReclaim : SCSI command failed: Illegal request, ASC = 21, ASCQ = 0
At line:1 char:1
+ Invoke-NcHostVolumeSpaceReclaim C:\ClusterStorage\Volume2
+ CategoryInfo : InvalidOperation: (:) [Invoke-NaHostVolumeSpaceReclaim], Exception
+ FullyQualifiedErrorId : QuickReclaimVolume failed,DataONTAP.PowerShell.SDK.Cmdlets.Windows.InvokeNaHostVolumeSpaceReclaim
I was able to get this command going by enabling maintenance mode on the CSV volume... only one "small" issue with that... data will not be accesible during that process AND... I still no see any change on the disk usage from Netapp GUI
Allright... I figured this out --- I even opened up a support ticket and they weren't able to figure it out. So...
long story short The "Hyper-V" setting for the "iGroup" and the the "OS Type" when you create the LUN should ONLY be used when you are using NetApps Managment Applications like SnapDrive... If you just want to run the native Microsoft solutions you must use the OS Type of "Windows 2008 or Greater" which means the iGroup needs to be Windows...
I was runinng Hyper-V 2012 R2 and now Hyper-V 2016 since they both support the inline SCSI unmapping that works automagically (no additionally software needed). The only additional thing that must be changed on the NetApp side is the "space-allocation" option must be enabled on the LUN, its disabled be default.
So if you need to run the Powershell tookit still it should run after these settings although you shouldn't need it...
If you need to run unmapp in Windows forcefully you can just run
This will list all volumes (make sure you are on the host that owns the Volume)
copy the label and run this command
Optimize-Volume -FileSystemLabel <Label Name> -ReTrim –Verbose
example: Optimize-Volume -FileSystemLabel '3TB Test Volume' -ReTrim –Verbose
Here is some links that help me get to the solution...
Scroll to the "LUN types to use for hosts and guest operating systems" section
This article talks about the "space-allocation" option
I hope this helps save you from the months of frustration it caused me...
I am glad you found a way to fix it in your enviroment. I will share my experience.
I went through a lot of testing and opened a ticket with Netapp which helped to come to two conclussions:
1. What seems to be a key factor, as you said, from Netapp is the "space_allocation" parameter on the LUN. Unfortunatelly the LUN must be set offline which is a big downside on production environments as it is only "doable" moving forward). ¿Why disabled by default? Doing online unmapping will affect negatively performance.
2. From the OS side, Windows MUST detect the drive as "thin provisioned" for the trimmming/optimize/unmapping process to work. This will ONLY happen if "space_allocation" was enabled on the LUN prior the drive was initialized for the first time on Windows Disk Management. Subsequent changes will not work as the drive will remain detected as a regular hard disk therefore not optimization/trimming will take place.
These two concepts were the only ones relevant for this feature to work, whether LUN Windows 2008 and/or HV type worked the same way for this particular configruation.
Hope this helps!
Hey, thanks for your message!
I must be missing some previous steps as mountvol /R removes non exisitng volumes from the system but they still show up as active on the system therefore no data is removed/refreshed.