Unfortunately, you cannot remove disks from a VNX storage pool once they have been configured as part of the pool...

Based on the description above, your best bet would be to add new disks to your "production" pool, so as to minimize overall impact to your array environment.

Obviously, this assumes that you have drive slots available and the ability to add more physical disks to your existing VNX5200 configuration...

Hello Henry,

Like Alexander mentioned, pools cannot have capacity taken away from them, they can only be expanded.

I want to add that you may want to consider other options, like increasing the pool's capacity efficiency by using compression or dedupilcation:

https://support.emc.com/docu48711_VNX2-Deduplication-and-Compression---Maximizing-effective-capacity-utilization.pdf?lan…

Just keep in mind the potential performance impacts of using these features. All details are mentioned in the above document.

Thank you guys for the answers,

Unfortunately we don't have free slots and the capacity of the VNX is at max (disks), so the only option I see is to create new LUNs in the QA pool and assign them to the storage group where the production servers are attached.

What do you think about this solution?

Thanks

If the array is maxed out from a physical disk perspective and no further disk additions can be performed, then if you have space in the "QA pool" I suggest you utilize it.

Obviously, you will be adding additional workload to the "QA Pool", so best to check the current performance profile of the pool to make sure you will not impact the on-going activities. If it is not being over utilized, then you should be okay. If it is being highly utilized, then you might only make matters worse...

Also keep in mind that with the recent VNX2 OE for Block release, which went GA earlier this week, you now have the option of performing a data-in-place upgrade of your VNX5200 up to a higher array model. This could allow you to upgrade to a VNX5400, thereby doubling your physical disk count from 125 to 250, or greater depending on the VNX upgrade performed. Obviously, this has a price associated with it.

If any of the LUNs in the Pool are "Thin" LUNs, you could try shrinking the LUNs on the host side - deleting files and such, then if your server OS supports the TRIM/UNMAP function you could run that from the hosts. This would free up space in the Pool. This would not work for Thick LUNs. If you have Windows 2012 R2 servers and are using a VNX2 with the latest flare release (33.119), the TRIM works fine. ESX also has the UNMAP function that seems to work fine. Be sure that the array is running the latest Flare as there have been issues with some of the older versions that could cause performance issues when running the TRIM/UNMAP. In Windows this is part of Disk Optimization that was introduced in Win 2008 and runs by default.

Using space in the QA pool would work, but you should be careful. If the workload was designed for certain Pool characteristics, you could unbalance the Pool.

You should be reserving at least 5%-10% free space in each Pool to allow Auto-Tiering to work efficiently.

glen

Thank you Guys,

I will consider all your suggestions.

At the end we proceeded to create and assign LUNs to the productions servers,  obviously considering the LUN performance.