NetApp reclaim free space in Volume


I filled up my LUN within its volume so I deleted some files within the LUN but the Vol does not reflect the changes or reclaim the unused blocks within the LUN (which is attached to VMWare ESX host.

I have NetApp Ontap 8.0.1 with 2040 File System and VMWare ESX 4.2 U3.

I know Ontap doesn't know about the VMFS file system within VMWare where my LUN is attached. So how can I use Ontap to reclaim the space without moving data out of it, deleting and recreating?

Thanks again everyone
Who is Participating?
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Your only option is to move the VM to a new LUN/datastore.
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Install Snapdrive 6.3 and use the space reclaimation feature.  If you do not have snapdrive you can create another datastore and use storage vmotion to move the VMs to new datastore and thus only move current data
Snapdrive will only do space reclamation within a VMDK and only in an NFS environment.

The OP is asking (I think) for space reclamation within the Netapp LUN/Datastore, which to my knowledge is not currently possible.

This is one of the big advantages of using NFS over iSCSI/FC, you always get your free space back in the datastore.

For now, the only solution is to move your VMs to a new datastore. If you have NFS licensed on your filer, consider moving to NFS.
Network Scalability - Handle Complex Environments

Monitor your entire network from a single platform. Free 30 Day Trial Now!

snyderkvAuthor Commented:

I already cleared the LUN and yes the LUN is still showing full.

So your saying I have to blow away the LUN and rebuild? That's a little confusing since if I move all the data to another LUN and move the data back to the rebuilt LUN, the old LUN will be full of white space as well? I pretty much have to move the data to a new LUN and keep it there, delete old and rename the new one to the same name as the old one?

There's got to be a better way.

So snapdrive only help reclaim white space within a vmdk and when using NFS only?
You don't have to move the data twice, just create a new LUN/datastore and move the VMs to the new datastore. No need to rename anything unless you want to.

Using NFS, any free space in the datastore is automatically reclaimed. Same goes if you use dedup: any free space gained by deduplication is reclaimed automatically.

To reclaim free space within the VM, use snapdrive and NFS.
snyderkvAuthor Commented:
We try and keep naming standard throughout all sites which is why I asked.

Dedup does have some gotcha's from what I read. Can't remember if it was while upgrading ontap or what but there are reasons to have to disable dedupe temperarily which I would think you need a lot of reserve space in order to do.

We don't use NFS for specific reasons as well as being inconsistent with the rest of the sites in theatre.
We get about 50% to 75% space savings using dedupe on our NFS datastores.

In an iSCSI/FC environment, it's a bit more complex indeed.

I feel your pain... I have gone through this mess. Netapp and FC aren't such good friends.

The above information is true about NFS on iscsi, however if you wish to not have to svmotion and create new data stores every time (which is crazy, fyi...) Then you need to read into the Unmap function for vmfs/fc setups. It's a VMware function, but be warned, depending on your array and it's compatibility with VMware, this operation is very IO intensive and you WILL see your latency go up, so VM (and me!) recommend doing this after hours or low peak times on the datastore.

Please do your research first, however these are the general steps I have used:

From the esxi command line

#Check Space Use
esxcli storage core device list -d naa.<ID NUMBER HERE>

#Check for VAAI Compliance (you are looking for the Delete entry to be true)
esxcli storage core  device vaai status get -d naa.<ID NUMBER HERE>

#View Datastore Contents
vmkfstools -Ph -v 1 /vmfs/volumes/DATASTORE NAME/
(this will show the total size of all the vmdk's in the datastore, you can use this to determine the space overhead, usually ~800MB)

du -h /vmfs/volumes/DATASTORE NAME/ (again, just checking around)

#GoTo to Run Reclaim
cd /vmfs/volumes/DATASTORE NAME/
(This will switch directories on the ESX Host to perform the unmap command later)

#Verify Before During After (Run this command on the NETAPP command line to see a before and after of reclaimed space, look at the space markers)
lun show -v /vol/VOLUME NAME/LUN NAME

#Run Reclaim
vmkfstools -y % (where % is the total amt of FREE space to reclaim)
A word of warning - start off with small percents to see how the IO and latency is handled, like 5 to 10 percent at a time, you can run this multiple times, in steps. DO NO MORE THEN 60% in total!

Let me know if you have any questions. Good luck!
snyderkvAuthor Commented:
eeamodei, great writeup thanks shooting in with an alternative. I'm sure others will find this usefull as well
snyderkvAuthor Commented:
I need to update this incase someone uses it as a reference. There is a newer snapdrive that does do space reclaimation on VMDKs within a VMFS datastore, not just RDMs like the version I used on my last post I believe

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.