Community

Subscribe
Highlighted

NFS Volume Space not reclaimed after Storage vMotion

My appologies if this has been addressed before.

I have an NFS volume on my FAS2240 that does not reclaim disk space when I move a VM off via Storage vMotion.  All other volumes do.

For Example:

Move 40GB VM from Saphire_Datastore to Gold_Datastore.

Volume free space prior to move:

Saphire - 108GB     Gold - 328GB

Volume free space after move:

Saphire - 108GB      Gold 290GB

I am relatively new to both VMware and NetApp storage, so I am unsure what direction to take.  I have looked online, but most of the leads I have located relate to deleting VMs or reclaiming snapshot space.

Thanks,

Re: NFS Volume Space not reclaimed after Storage vMotion

Update:  I just noticed in OnCommand System Manager that there are a group of tabs at the bottom of the Volume pane.  The Saphire volume has 423GB of Snapshot data even though I have left the snapshot space at the default 5%.  I guess it is safe to delete the larger snapshots, but I wonder why they would be so big in the first place.  One snapshot is 256GB at was taken at 4:00 p.m. yesterday.  It just happens that I was migrating a 250GB VM from Saphire to another datastore at about that time.  Has anyone seen this type of behavior? 

Re: NFS Volume Space not reclaimed after Storage vMotion

I believe I have figured out my issue:  My snapshots were configured to run at the default times.  One of those times is 4:00 p.m.  The snapshot is so huge because the file was still in the process of being copied.  Well, now I have a good reason to change those times!

Re: NFS Volume Space not reclaimed after Storage vMotion

You got the point!

;-)

NAScimento

NetApp - Enjoy it!

Re: NFS Volume Space not reclaimed after Storage vMotion

If you have 100GB of data, create snapshot and delete data, those 100GB are accounted to snapshot. That's how snapshots work ...

Re: NFS Volume Space not reclaimed after Storage vMotion

you don't want snapshots just go to the volume resize and

Snapshot reserve (%):00,

Then it will show, total allocated space as volume space.

Snapshot is working on copy on first write technology,so what ever may be updates happen it will take as snap that's why when you migrate the 250GB VM its taken entire snap.

Re: NFS Volume Space not reclaimed after Storage vMotion

Was your question answered correctly? If so, please remember to mark your question Answered when you get the correct answer and award points to the person providing the answer. This helps others searching for a similar issue.

Re: NFS Volume Space not reclaimed after Storage vMotion

Was this ever answered?

We have about 50GB of files that were deleted from a VOLUME over a month ago. THe problem is that none of the space seems to have been reclaimed. This is a netapp 250 running ontap 7.2.xx. It is used as an nfs server for a couple of Solaris boxes in out network

Re: NFS Volume Space not reclaimed after Storage vMotion

Do you have snapshots on this volume? Check with "snap list".

Re: NFS Volume Space not reclaimed after Storage vMotion

yes they do use snapshots. Weird thing is when on the solaris hosts I do a du-h command on the .snapshop dir and it seems like it's as big (168GB) as the volume itself

netapp2>df -h

....

/vol/vMedia/          200GB      170GB       29GB      85%  /vol/vMedia/

/vol/vMedia/.snapshot       50GB     5705MB       44GB      11%  /vol/vMedia/.snapshot

netapp2>

netapp2> snap list

Volume vMedia

working...

  %/used       %/total  date          name

----------  ----------  ------------  --------

  0% ( 0%)    0% ( 0%)  Apr 04 09:26  netapp1(0084329016)_vMedia.1266 (snapmirror)

  0% ( 0%)    0% ( 0%)  Apr 04 08:00  hourly.0

  1% ( 0%)    0% ( 0%)  Apr 04 00:00  nightly.0

  1% ( 0%)    0% ( 0%)  Apr 03 20:00  hourly.1

  1% ( 0%)    1% ( 0%)  Apr 03 16:00  hourly.2

  1% ( 0%)    1% ( 0%)  Apr 03 12:00  hourly.3

  1% ( 0%)    1% ( 0%)  Apr 03 08:00  hourly.4

  2% ( 0%)    1% ( 0%)  Apr 03 00:00  nightly.1

  2% ( 0%)    1% ( 0%)  Apr 02 20:00  hourly.5

  3% ( 2%)    2% ( 1%)  Mar 31 00:00  weekly.0