HPE Storage Users Group

Hi Adam,
if this is happening with your veeam environment...we ran into something similar with san or nbd restores...but the environment had to be:
1) tpvv vmfs volume on a 3par array
2) veeam as the b&r application
3) vm configured EZT
4) restore full VM from veeam with "same as source" for the disk type (aka EZT)

veeam had an issue that if it was EZT or LZT it would always restore LZT...which the 3par as a TPVV volume that is having blocks overwritten that should either be zereos or not create crazy overhead....having veeam "prep" the vmdk as EZT would alleviate the performance issue. this requires the latest version of 8 with a hotfix you need to get from support, or version 9 of veeam, and a registry entry "EagerZeroedDiskRestore" created and set to 1. this will tell veeam on a full restore of a vm or vmdk to first configure it as EZT and then restore.

if this is not your setup then it does not apply really. chjones has a long running thread in veeam forums regarding this. i pointed to it to get the hotfix last year. and resolved our direct san restore performance limit (thought not as bad as others saw)

hope this helps.

Hi, we have a similar issue not with veeam, but vmware horizon view:

viewtopic.php?f=18&t=1378

We got this analyzed by vmware and HPE, the result was that VMware handles writing to a volume (without VAAI, similar like Veaam) completely different at the SCSI-Level. So I'm not sure if this is a 3PAR-problem, or if veeam has similar issues when writing to blocks that must be zeroed out compared to blocks that already ARE zeroed out.

In our case, thin or thick did not matter, because the problem was in the VMware-thin provisioning.

_________________
When all else fails, read the instructions.

Hi

Thanks for all the assistance provided on this. We have finally got performance up to an acceptable level due to the following things;

1. Disabling the tcptime stamp on the 3Par iSCSI ports (carried out by HP support engineers)
2. Ensuring all hosts were using a HP custom image of ESXi and had the latest PSP/firmware installed (I don't overly trust HP custom images due to memory/host lockup issues with previous versions so they hadn't been used here)

The timestamp setting made the biggest difference to performance with a further improvement shown by using a customised HP image of ESXi (optimised NIC driver I guess - waiting for the next HP related ESXi issue now ).

Thanks

Adam

The release notes for 3.2.2 EMU2 lists this as fixed, FYI. We are getting the update this thursday and I'm eager to see if performance improves on our thin-deduped volumes.

Quoting myself on this one for visibility - we are seeing atleast 10x performance increase on basic stuff like creating VHDX files on a LUN. No idea if this is due to iSCSI fixes or TDVV enhancements (or both), but we're happy.