I have two Lun's on one vol/vol1 of my FAS 2020. I am using 126.96.36.199 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?
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
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.
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.
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:
create a new lun of the proper size
map the new lun to the same igroup as the existing lun
using the virtual center client, rescan the storage adapters on each ESX host
create a new datastore using the newly discovered lun
for each Virtual Machine on the datastore that is "too large"
power down the VM
migrate the VM to the newly created datastore
power on the VM
once you are sure that all the data is off the datastore that is "too large", remove the datastore using the virtual center client
on the NetApp controller, offline the lun
check to make sure your VMs are still working
destroy the lun
start a manual dedupe on the volume containing the lun
Keep in mind you will not get "all" the space back immediately. Any storage that is locked in a snapshot will not be made available until that snapshot is released.
If you happen to be using version 2.5 of vCenter and version 3.5 of ESX, the other option is to download and install the Rapid Cloning Utility version 2.1. The RCU will take care of steps 1-4 for you, as well as 6-10.
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.
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.
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.