on my Netapp i habe a volume that is 6TB. Available Space is 2,4TB. On this volume i have a LUN with 6TB and it is used 100% (full). No Space left. The LUN is thin-provisioned and mapped RAW to an ESXi VM (Fileserver). How can i get back the free space on my LUN?
It sounds like ESX is reporting the LUN full but there is actually free space. This could be down to either storage efficiencies that ESX does not understand so cant also report the savings, or deleted blocks in the ESX filesystem that the storage cannot map - so does not delete and just sits there.
Assuming you have space capacity in the aggregate, the easiest thing is to create a new LUN/datastore and Storage vMotion the contents of the full LUN into that one. Then delete the old LUN to release the blocks.
Here we discussed that the LUN does not reflect the storage efficiencies seen in the volume (which is why you have free space in the volume). Unfortuantely, while there are blocks available in the volume the LUN will report 100% full. In these situations we need to monitor the volume capacity and the OS filesystem, to make sure they do not run out of space.
If the volume fills then regardless of how much space the LUN thinks it has, it will go offline (unless space_alloc is implemented where it will remain online but read only) and writes will stop.
In your case, assuming ESX also reports it has free space and not full, I wouldn't be too concerned about the LUN being at 100%, since the volume still has space.
Since the volume has space, and assuming ESX can see that free space i.e. is is not 100% full, then you are safe to ignore the LUN capacity. We have many LUNs that are close to or at 100% full, but since our volumes and file systems have free space there is no problem - the LUN will only run out of space if the volume (or aggregate) is full (assuming the file system is not the reason the LUN is full!)
Since the LUN does not reflect the actual free space available, you need to monitor the OS file systems free space as well as the volume free space only, ignoring the LUN.
Hopefully a clearer answer for you??? Let me know.
If ESX is reporting it is short of space then it needs to be addressed, despite the free space in the volume.
It sounds like the datastore is reserving space, e.g. lazy zeroed thick VMs. In this case the space is reserved in the datastore allowing you to directly manage capacity however those zeros are not written to the storage, so the capacity does not match.
I'm not convinced we have a problem with deleted data not being released on the storage, that space reclaimer would help address, since this would mean we have more space consumed on the storage than the datastore, which isn't the case here. But one definitely to be aware of, also addressed by the use of the space_alloc LUN option that allows the supported OS to tell the storage that the blocks can be safely deleted.
Hi Rene, in short...the guest will not see any of the storage efficiency savings; you can't claim that space back for the file system to use.
In your thin provisioned environment (both LUN and volume), the storage efficiency savings are at the storage layer only and release blocks back to the aggregate to allow you to create additional volumes/LUNs. The space savings for block based (SAN) storage is on the storage, unlike file based (NAS) storage that passes those savings to the clients. To realise storage efficiency savings directly on the hosts you will need to use NFS datastores.
You will need to increase the size of the RDM LUN on the storage and make that available to the Windows server to expand the file system.
Again, just to point out that since you've thin provisioned both the volume and LUN, you only need to monitor the space of the volume (and aggregate) as well as the file system. You do not need to worry about the LUN itself being 100% full. It is also good practice to regularly run (out of hours) SnapDrive Space Reclaimer (only supported on physical RDMs) or enable the space_alloc feature on the LUN to release those deleted blocks.
If you have a 6Tb volume with a 6Tb LUN on it but it says the volume has 2.4Tb available, then I suspect you have storage efficiency enabled and it has compressed the LUN. If someone shrinks the volume (who wouldn't want to reclaim 2.4Tb of unusable space?) and the volume is not configured to autogrow back to at least 6Tb, then you would be in real danger of the LUN going offline as soon as it becomes less compressible (ie: data changes).
Hello, to confirm, in this case since the volume is thin provisioned the 2.4TB free space is already available in the aggregate - no need to resize the volume to release the space.
As I stated above, you do need to actively monitor the free space in the volume (and aggregate), then you can ensure the volume has enough space to prevent the LUN going offline. Obviously, also not forgetting to also monitor the space on the host file system.