We are new to 3PAR and just putting our first vm's on. I created four 4TB virtual volumes in the IMC as thin with zero detect. I presented those to my ESXi 5.1 hosts and created a datastore cluster out of them so that I could use sDRS in VMWare. I am now migrating existing vm's from an EVA8400 to the 3PAR volumes with svMotion. When I do my svMotion I am changing destination format to Lazy Zeroed to Eager Zeroed Thick (EZT).
All has been going well but now I have a problem/question. My virtual volume on the 3PAR is working great - says that of the 4TB only 2TB is used, however, VMWare is calculating the VMFS space based on an EZT vmdk and is calculating the thick size. SO....what is being stored as 2TB on my 3PAR is showing up as 3.4TB in vSphere so it thinks the volume is almost out of space. I am not sure how to reconcile this. I suppose I could do thin on thin and then the VMFS would match what is happening on the 3PAR (?) but I have heard this isn't necessarily the best way to go.
Any suggestions?
Actual Disk space vs VMFS space (tpvv and EZT)
-
mlwilliamson
- Posts: 7
- Joined: Tue Oct 23, 2012 2:36 pm
Actual Disk space vs VMFS space (tpvv and EZT)
- Attachments
-
- vsphere.jpg (76.18 KiB) Viewed 16534 times
-
- imc.jpg (65.43 KiB) Viewed 16534 times
Re: Actual Disk space vs VMFS space (tpvv and EZT)
Hi,
The idea with the 3PAR is that you can over-subscribe your storage and make better us of the actual physical disk space, albeit paying attention so you don't end up way oversubscribed and filling up the actual 3PAR disks... As an example, we're up to 137% presented out to hosts, but only using 70% of the actual physical disk capacity.
Your easiest option, i think, would be to create and export another vvolume, add it as an additional VM datastore, and let the 3PAR deal with the "thin" side of things. If you start doing thin on thin, you then run the risk of filling up both the vmfs store and the exported vlun without warning; if a lot of data is added and the vmdk's need to expand beyond what vmfs sees as datastore size, I assume the VM;s will just freeze/shutdown? We're using thin on the 3par, and datastore clusters in vsphere, that way, vsphere might be using 80-85% of what it sees, but the 3par vvolumes are sitting down at 50-60%.
Hope that helps.
Cheers,
Will
The idea with the 3PAR is that you can over-subscribe your storage and make better us of the actual physical disk space, albeit paying attention so you don't end up way oversubscribed and filling up the actual 3PAR disks... As an example, we're up to 137% presented out to hosts, but only using 70% of the actual physical disk capacity.
Your easiest option, i think, would be to create and export another vvolume, add it as an additional VM datastore, and let the 3PAR deal with the "thin" side of things. If you start doing thin on thin, you then run the risk of filling up both the vmfs store and the exported vlun without warning; if a lot of data is added and the vmdk's need to expand beyond what vmfs sees as datastore size, I assume the VM;s will just freeze/shutdown? We're using thin on the 3par, and datastore clusters in vsphere, that way, vsphere might be using 80-85% of what it sees, but the 3par vvolumes are sitting down at 50-60%.
Hope that helps.
Cheers,
Will
-
mlwilliamson
- Posts: 7
- Joined: Tue Oct 23, 2012 2:36 pm
Re: Actual Disk space vs VMFS space (tpvv and EZT)
Thanks Will that does help. That is pretty much the conclusion I had come to and so I did just that added the extra volumes. Being new it is a little hard to get comfortable with the large amount of overprovisioning going on in the 3PAR although I certainly agree with the concept. It is good to have that validated. Thanks for the response!