I have two Lun's on one vol/vol1 of my FAS 2020. I am using 220.127.116.11 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.
Hope this helps,
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.