ONTAP Discussions
ONTAP Discussions
I have two Lun's on one vol/vol1 of my FAS 2020. I am using 7.3.1.1 software. I have just enabled Deduplication on Vol/vol0 which has my CIFS shares. Vol1 has my VMware stores. I had an issue where one of my servers got several vmware snapshots on it and I had to grow the Lun inorder to delete the snapshots (lesson learned, do not keep vm shanpshots around for long). I was able to resolve that problem, but I had to use all of the space in the volume to allow for the consolidation of the snapshots. now that volume is 100% allocated and has no room for snapshots or deduplication. between the two luns I have over 500gig of unused space that I could reclaim if I could shrink the luns. Is there a better way than backing up each VM and then deleting the LUN's then rebuilding the LUN's and resotring them?
thainks
Adam
The short answer is yes, you can shrink a LUN. But you need to be cautious because it might cause data corruption. Another option might be to increase the volume size, if the aggregate has more space. -Wei
Is this correct, you are running shares out of your root volume, or are you using "vol/vol0" as just an example?
Hi Adam,
While it is possible (and quite easy) to shrink a NetApp lun, the VMFS filesystem does NOT support shrinking. If you shrink the lun you will likely corrupt your datastore.
I suggest you create a new, thin provisioned lun of the size you'd like to shrink your datastore to. You can do this in the same volume (by growing the volume now and shrinking it after you offline/destroy the old lun) or creating a new volume (possibly thin provisioned). You could then use the "storage vMotion" feature of VMware to non-disruptivly migrate your VMs to the new, smaller lun. Finally you would then offline/destroy the old lun and reclaim the space.
Hope this helps,
-Eric
I agree with Eric and recommend you forget about shrinking luns.
Bren
I can take the systems offline overnight and migrate the data store for each one leaving the Lun's empty. Once I do that should I shrink the lun's or delete them? If I can shrink them then I can keep the same ISCSI initiator strings and then migrate them back when finished. What is the command line for shrinking a lun? I do not have snapdisk software lic so I am assuming that I have to use the cli to make any changes.
Thanks,
lun resize [ -f ] <lun_path> [ + | - ] <size>
- change the size of a LUN to the input value <size>.
See "lun create" for the syntax of <size>. + or - option
may be used to increment or decrement the current size.
If a LUN is to be reduced in size, the -f option may be used
to override any warnings.
Note that administrative actions may be necessary for client
operating systems/applications to see the size change.
To prevent block-protocol accesses during the LUN resize, the
"lun offline" command may be used.
Please do not shrink the lun. Shrinking the lun will corrupt your datastore.
If you can take the virtual machines down overnight, than your best course of action is as follows:
Thank you very much to everyone. I appreciate all of the prompt feedback. I have taken down the non essential systems and am migrating them now. after hours I will take the other systems down and migrate them.
thanks again.
Hi
I noticed this post is quite a few years old now.
I am running vsphere 6 on a NetApp FAS 8020 running 8.2.3 Data ONTAP 7-mode.
I am using a flexvol, would this advice still be the same that its not advisable to shrink your LUN if you resize (downsize) your flex volume?
Many Thanks
VMware datastores cannot be shrunk
A LUN on a Windows machine is shrinkable, wouldnt recommend it as it can take plenty of time and if you shrink more than 50% you should only do so with cluster mode.
Shrinking a LUN is essentially a truncate. It doesn't try to figure out which blocks matter to you (or the file system) - it just lops off anything above the size you specify. That means anything up there is simply gone. If those VM snapshots grew, then you created something important - or ESX wrote something important - into the upper space, it won't magically move back down to lower address space, so if you shrink, it's gone.
A couple years ago, I tried shrinking a datastore that I had just grown. VMFS didn't seem to care. (This was back in 3.0.something). I didn't try grow --> fill --> shrink.
Hey Everyone, I would like to take the prior advice given and create a new side by side LUN instead of trying to shrink it.
However I am in a little bit of a pickle with available space. The LUN I would like to shrink is 16TB and has 14.07TB used (according to the SAN). The real used space (in VMware) is actually only 9.5TB though.
I would like to create a new side by side 10TB LUN to migrate to and then destroy the old 16TB LUN, but my issue is the SAN is only reporting 6TB of free/usable space.
Any help would be greatly appriciated.
You can use vmfs space reclamation to returtn unused space to NetApp. This should give you additional 4TB of storage to create new LUN.
Sorry excuse my noobishness but is there full instructions for this somewhere? This is live/production data so I don't want to take any risks.
Well, google search for "vmfs space reclamation" brings up quite a lot of hits, including VMware KB articles. If you are concerned with "no risk" I suggest you open support VMware support call and ask them.
On NetApp side you will need to disable space reservation for volume and LUN; otherwise space reclamation won't increase free space on aggregate. Also space reclamation won't free storage in snapshots.
Are you using vmware? If so the tasks depend on which version of vSphere you are on.
For ESXi 6: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2057513
For ESXi 5: https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2007427 and https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2014849
this is quite a useful post however it is out of date now but still a useful read to understand the process
http://blogs.vmware.com/vsphere/2012/04/vaai-thin-provisioning-block-reclaimunmap-in-action.html