XtremIO recommended settings for VMware

Yes, the recommendation for best performance (from VMware and EMC) is to use “Thick Provision Eager Zeroed” datastores.

The advantage is that at the storage level, we would not have to do ANY operations to write the zeroes. See a related blog article at http://www.xtremio.com/saved-by-zero. We don’t even need to write a single zero block or consume any metadata (aka fingerprint or hash address) storage because of our architecture.

With vSphere 6 expanding EZT VMDK disks looks to pause the VM and eager zero the added space, then un-pause the VM.  vSphere 5.5 and below changed disk type to LZT and did not pause the VM for any substantial length of time.

With vSphere 6 expanding a VMDK 500GB pauses VM for 1 minute for a friends testing environment 

With VPLEX metro and mirrored XtremIO LUNs across datacenters expanding a VMDK 500GB took 25 minutes for me, unfortunately this was production so was a significant event.  I am looking into seeing if this is expected w.r.t time it took, but VMware senior support claims this change in vSphere 6 was considered a bug fix from the vSphere 5.5 behavior. Even if it was 1 minute, I would not like this new behavior.

Eager Zero seems to now have a significant consideration on XtremIO from my perspective, in my implementation.  I am considering Lazy zeroing everything now on XtremIO, but would love to hear if others found this issue and if so what their thoughts are about this.

Before vSphere 6 I was a big proponent of EZT on XtremIO.

My google skills did not find much on this, so I replying to the most pertinent post on this issue.

Cheers,

John

It looks like VMware created a KB on this issue:

Extending an eager-zeroed virtual disk causes virtual machine stun in ESXi 6.0 GA/ 6.0 U1 (2135380)

You probably already saw this, but according to the KB, 'This issue is resolved in VMware ESXi 6.0 Update 1b'. 

You could also expand the VMDK and then do an advanced storage vMotion (just select Eager Zero Thick when moving the applicable VMDK), then move it back to the original location. This will convert the VMDK back to an Eager Zero Thick format while leaving the VM online without the possibility of a 'stun' situation.