HPE Storage Users Group

Hi Team,

we have two T400 running with 2.3.1 MU3 IOS software. Recently we have deleted around 30 vmware VM's and also storage vmotion around 50 VM's to differnet datastore part same esx 4.1 cluster. But due to the current esx 4.1 with IOS 2.3x limitation these space were not reflecting on repstive VV on 3par. I am aware these issues are resolved in esx 5.0 running with 3.1.1 IOS but we are not in a postion to upgrade the os and firmware at this moment. I know the workaround-create new datastore and move the repecitve VM to this 3par datastore. Once moved then delete the old VV from 3par. I thought before doing that let me check with you guys is there any alternative way at the 3par level?

Currently our windows VV never had this issue becasue all the physical and windows VM's are running with sdelete to write to zero's to enable the 3par thin persistence to get the space back.

Also currently we are running out of space ,we will be adding 8 new FC magazine(300x4) to the existing array. Since the new spindles are not automatically appear on the existing CPG, I am planning to perfom following steps as a workaround.

1) create new cpg
2) Tune existing VV to new cpg
3) Once moved then delete the Old CPG

My concern is since we are running RCIP, can we do this on fly? should I need to stop the replcation prior to tune the VV? Also once tuning completed can we get the space back automatically from all the old LD(from old CPG)?

Also suppose if I am not perfoming above 1 -3 stepts what will be impact if the array reached peak space? Is it start using newly added spindle/space automatically on all the existing CPG's ?

Appreciate any opinion and comments with regards to this

Thanks and regards

Shyju.

shyju,

Perhaps this topic is of any use:
http://www.3parug.com/viewtopic.php?f=18&t=90

psshyju wrote:1) create new cpg
2) Tune existing VV to new cpg
3) Once moved then delete the Old CPG

Thats the procedure I am using today on Inserv 2.31, however if you do upgrade to 3.x you can use the tunesys command instead.

Regarding VMware, VMFS and zeroing... There are some options on the VMwares forums. One is to zero out the freespace from the console exactly as one would do in linux/unix. Instead of sdelete they use a dd command to create files loaded with zeros, then delete the files.

http://communities.vmware.com/message/1596020#1596020


Note: X has to be replaced with (1M,2M,4M or 8M) and Y with a multiple of X, e.g. dd if=/dev/zero of=xxx.zero bs=1M count=254, will create a 254 MB file with zeros

Remember to set the vv policy to zero_detect on the 3PAR luns first =)

To get space back from the CPG (LDs), you can run a compact CPG task from right clicking the CPG.

I have a question for you... since you do thin provisioning at the storage level, why type of VMDKs do you use? Do you use thin provisioning at the VM level as well?

Thanks, and I hope this helps.

Hi Richard,

Oops..My apology ..Thanks for the dealy in response=Sorry for the delay in repose.. I need more sleep .

We are only using thin provisinong at the storage levvel not at the vmware level,vmwer level everything is thick. As advised I have added new 8 drive magazines and and moved all the voumes to the new compact CPG and deleted old CPG. All looks good now. I am not yet started running the script to zeroing the space on the vwmare. Is there any impact associcated with it while runnig this command? or anything needs to cautious?

Thanks and regards,

Shyju.

I would have to defer you to the ESX forums via that link provided.

Since you're using thick provisioning at the VMware level... zeroing out freespace will be a challenge. To completely zero all free space out, you would have to run the equivalent script/process on each guest as well... something I don't think is ideal.

We're in the process of upgrading to ESX5 and the thin persistence is somewhat automatic between the 3par and ESX due to enhancements.

Hi Richard,

Thanks for the reply.We are also in the process of upgrading the array firmware to 3.1.1 MU1 and ESX to 5.0 .Even I hope these changes will make huge difference to manage thinly provisioned volume capacity management.

Cheers,

Shyju.

I would like to hear how things are working with 3.1.1 and vSphere 5.0. We're planning our 3.1.1 MU2 upgrades now.