Data ONTAP Discussions

NFS Data Storage on ESXi 4.1 with VSC4.1 Plugin

Dear All

I can not understand the following event:

I have an NFS Data Store which I have cleaned up, I have moved all VMDK Files and have deleted some orpahn VMDK's, because I have space problem on this data Stor,

therefore I have now only just some VSC snapshot backups on this NFS Data Store and nothing else, but when I look at the snapshot size of this volume I can see the following picture:


(NetApp Release 8.1 7-Mode: Thu Mar 29 13:56:17 PDT 2012)

SANAASAN02*> snap list ESX_OS

Volume ESX_OS



  %/used       %/total  date          name

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

34% (34%)   27% (27%)  Feb 08 04:00  SANDDSAN01(1573969455)_ESX_OS.924 (snapmirror)   

39% (12%)   34% ( 7%)  Feb 07 01:21  smvi__Consistent_20130207010003

40% ( 2%)   35% ( 1%)  Feb 06 01:22  smvi__Consistent_20130206010004

41% ( 2%)   36% ( 1%)  Feb 05 01:22  smvi__Consistent_20130205010005

42% ( 3%)   38% ( 2%)  Feb 04 01:27  smvi__Consistent_20130204010006


Filesystem               total       used      avail capacity  Mounted on

/vol/ESX_OS/            1152GB     1039GB      112GB      90%  /vol/ESX_OS/

/vol/ESX_OS/.snapshot      128GB      486GB        0GB     380%  /vol/ESX_OS/.snapshot

I can see that 486GB are used for the snapshot's on this Data Store, but when I look this Data Store in my vCenter console, then I see that the same Data Store are displayed as Space Utilized as other with the size of 967.36GB,

As I had already explained I have moved or deleted all VMDK Files from this Data Store, actually I have only the VSC Snapshot Backup on this Data store, and normaly nothing else therefore I can not understand exactly what occupies this space, Its very strange for me.


Re: NFS Data Storage on ESXi 4.1 with VSC4.1 Plugin

If you deleted VMDK files from the NFS share, then they will get locked into snapshot. That's why your snapshot space is so out of whack.

To fix this, delete your snapshots and then create a new backup to ensure you have a fresh copy of your desired VMDKs.

Since this issue was in early Feb, I assume the problem started to resolve itself once backups rolled off.