Decrease "Reported size" value on the vsa volume: When is it possible?

[Bianko]

Hi, I'd want to decrease the volume size on the VSA: actually it's been a mistake. I increased it but once I did it I thought it would've been a better choice to leave it untouched and to create instead a new volume. I didn't touch anything else (that is, I left untouched the vmware datastore that is mounted on the vsa volume) but that value "Reported size".  I don't have snapshots, etc on the VSA.

My worries are due to the following warnings that pop up when you try to reduce that value. Can I safley ignore them, stating the above? Thank you. Francesco

the first warning when typing a lower valuethe second warning if you hit Ok on the first one

[oikjn]

I would not shrink it.  Is this a thin provisioned LUN or thick?  If its thin, just leave it alone and don't expand the size in esx.  If this is thick, convert it to thin and do the same :)  Then just create the new LUN you thought was a better idea anyway.  Later if you want, you can always migrate the data from the existing LUN to a 3rd one as long as they are all thin provisioned you should be able to make the migration with only a temporary increase in used capacity.

[Bianko]

Thanks for the answer oikjn. It's a thin volume. Honestly I believed that wouldn't had been an issue shrinking a volume to a size greater than the actual occupied space by the "application host". Is your a techical advice or a precautional one?

[oikjn]

precautional.  The risk/reward for a thin provisioned LUN just isn't there (perticularly when your host is not configured to use more of the LUN than you wanted anyway).  You are correct that the space shouldn't be occupied, but shouldn't be is not the same as isn't.   The #1, 2, and #3 rules for storage is "protect your data" and shrinking that LUN is just an runnecessary risk to that data when the SAN doesn't not know if its removing empty or occupied data from the LUN.  

If it is a thin LUN and ESX is only reporting the part you want it to, you should ask yourself why it even matters if it is not shrunk.  

Assuming you have space reclaimation working and this really bothers you, you should just make a new LUN and migrate the data on this one to the new one and then you can shrink it or delete it.

[Bianko]

Ok, I see what you mean. What do you think instead about a snapshot taken before the shrink with all the application VMs powered off? Ie: power off all the VMs, take the snapshot of the volume, shrink the volume, power on VMs. If all it's ok I'll delete the snapshot, else I'll bring back the size to the original value and revert to the snapshot. Would it be a valid alternative?

Thank you

PS: I haven't enabled yet space reclaimation because I haven't had space issues until now.

[oikjn]

there is virtually no downside to running space reclaimation so I would enable that and rescan the LUN in esx to enable the trim/unmap function.

Are you trying to shrink this LUN in order to lower actual used storage of the LUN? I could understand the desire to shrink the LUN if it was thick provisioned, but you mentioned it was think provisioned so I'm not sure what you are actually trying to gain by shrinking this LUN.

[Bianko]

Ok, I got it. I'm going to enable the space reclaimation.

Regarding the shrinking, basically I'd want to shrink for two reasons:
- To keep a clean configuration.
- Because it's another thing to keep in mind and manage in the future... When touching the configuration, expandig the storage, monitoring actual free and provisioned space and so on. Right now it's a thorough task to calculate the real free space, since terminology in the CMC is quite messy (added to the complexity for raid 10 configuration... Divide or multiply by two where needed for example).

Basically fot these reasons. :) I undestand the "techincal" approach... Since it's thin there's no real space issue in my case.

[oikjn]

I understand.  

Assuming you have space reclaimation working and this is a VM store LUN AND you have enough free space in the cluster,  you would be safer to slowly migrate the VMs from the existing LUN to a new LUN(s).  Once that is done and all data is off the over-expanded LUN, you can either delete it or shrink it as you want.

I get it is a struggle between OCD neatness and data integrity.  The above is what I would do, but if the data is backedup up elsewhere, I can understand the desire to attempt to shrink it down.