This is the background:
LUN thin provisioned of 700Gb
Datastore thin provisioned of 700Gb
The Datastore space reached almost 100% of the space and I'd had to delete a few VM off the datastore and run a few unmap commands on the ESXi server.
After the deletion. nothing seems to have changed in terms of free space fromt the vSphere web client and the ESXi SSH session.
The output of the dl -h command shows that the datastorage is at 97% of the DS size and you get the same number from the datastorage vSphere view.
If I go to System Manager or VSC, the LUN free space is 90%, nonetheless.
So, there havent been any change in terms of free storage after the deletion.
Could someone tell me where's the space free after the VM machines deletion?
DEDUPLICATION CONSIDERATIONS WITH VMFS AND RDM LUNS
Enabling deduplication when provisioning LUNs produces storage savings. However, the default behavior
of a LUN is to reserve an amount of storage equal to the provisioned LUN. This design means that
although the storage array reduces the amount of capacity consumed, any gains made with deduplication
are for the most part unrecognizable, because the space reserved for LUNs is not reduced.
To recognize the storage savings of deduplication with LUNs, you must enable NetApp LUN thin
Note: Although deduplication reduces the amount of consumed storage, the VMware administrative
team does not see this benefit directly, because its view of the storage is at a LUN layer, and
LUNs always represent their provisioned capacity, whether they are traditional or thin
provisioned. The NetApp Virtual Storage Console (VSC) provides the VI administrator with the
storage use at all layers in the storage stack.
When you enable dedupe on thin-provisioned LUNs, NetApp recommends deploying these LUNs in
FlexVol volumes that are also thin provisioned with a capacity that is 2x the size of the LUN. When the
LUN is deployed in this manner, the FlexVol volume acts merely as a quota. The storage consumed by
the LUN is reported in FlexVol and its containing aggregate.
I missed to say that dedup is enabled but LUN space reservation and Volume Fractional Reserver are disabled. Snap server is set to 0%.
It's a single LUN-Volume.
There are a few VM snapshots within that store.
But the Datastore free space remains the same even after deleting VMs.
There's no Snapshots at the Storage Array level.
> If I go to System Manager or VSC, the LUN free space is 90%, nonetheless.
I could only find out "% Used" column in System Manager. Do you mean "% Used" is still 90% even after you have deleted files on DataStore?
Used space at LUN level does not reflect usage of filesystem level. Once actual block is allocated from aggregate, its is counded as "used" and is never freed even after removing files from VMFS. Of cource, this "used" blocks are reused by VMFS.
Usage statistics at LUN is useless for users and admins, so ignore difference between "df" on ESXi and LUN used space on ONTAP.
> I could only find out "% Used" column in System Manager. Do you mean "% Used" is still 90% even after you have deleted files on DataStore?
Yes, that's what I'd like to mean.
> Used space at LUN level does not reflect usage of filesystem level. Once actual block is allocated from aggregate, its is counded as "used" and is never freed even after removing files from VMFS. Of cource, this > "used" blocks are reused by VMFS.
> Usage statistics at LUN is useless for users and admins, so ignore difference between "df" on ESXi and LUN used space on ONTAP.
I deleted the VM machines and afterward, I ran an unmap command over the Datastore to give back the freed blocks to the LUN. I thought that Storage Array takes advantage of VAII and VASA to solve these kind of issues.
I found a similar issue, are you sure that the unmap command has actually ran? Is delete status supported? To check run "esxcli storage core device vaai status get". If delete status is unsupported run "lun set space_allo <lun path> enable". I removed a 6TB vmdk and 6 weeks later i'm still having to reissue the unmap command from the vm host. Apparently there is a bug in 7-mode which has been made publicly known yet which causes the unmap command to time out (it took me 6 weeks of speaking to support to find this out). You can see if it's making any progress by running esxtop, select u for disk device view then f, o and p. Take a look at the MBDEL/s column, if there's anything in there unmap is still running (very slowly in my case), if not issue another unmap and see if anything appears.
I had the same issue and we use FC LUNS, presented the same way like how you do it. I did have to run specific flags