Apologies, I was unaware that VAAI for NAS would offload a VMware snapshot to the array. My understanding was that the snap primitive was used to clone a VM -- the primitive names are sometimes misleading and confusing. I'm trying to find more information on exactly how the snapshot offload works. VMware KB 1021976 doesn't have nearly enough details. Is the VM still stunned when creating the snapshot? When the snapshot is deleted, is there still the potential for a very long commit period? I'm fairly certain the commit details are not significantly different, based on what I've seen (even though I didn't know I was using the offload feature), and commits are where all our issues have been with VMware snapshots.
As for the feedback on the previous page, we all know that there is a lot more to designing a backup architecture than just the primary storage device. The backup target design and network architecture design are incredibly important, as well. Also, 600GB is only 5% of the T540 capacity. In a rather small environment I was managing previously, we were backing up something like 10TB from a T540, and the backup target was an older DataDomain (daily incrementals and weekly fulls). We had a few very active SQL servers and a couple other high IO systems, and we would regularly have significant issues with backup performance and snapshot commits (and yes, we did have the Tintri VAAI for NAS vib installed to all hosts). The VMstore wasn't working hard enough to be a concern, and thankfully it's per-VM QoS is good enough that no other systems were ever impacted. Throughput issues were typically a result of job configuration + DataDomain, but throughput was secondary. The timing of the application issues we'd encounter could near always be traced to the snapshot commit period. In a much larger environment I helped design, we had EMC Clariion's with hundreds of spindles, and we'd have the same issues with snapshot commits.
In the end, my experience is that if your VMs are sufficiently busy, you will have problems with VMware snapshots, regardless of the storage solution and how fast it is. So yes, I advocate for avoiding VMware snapshots, and offloading snapshots and commits to the storage array entirely.
The ideal workflow to me would be for Veeam to quiesce the VM, then send the Tintri VMstore the command to snapshot the VM, then release the VM, then copy the snapshot from the VMstore to the backup target, then delete the Tintri snapshot. Note the data path there -- from the VMstore to the backup target -- not from the VMstore to the vSphere host to the backup target. Also note in this workflow that there may be very little interaction with vCenter or the vSphere hosts.
I see another use case for Veeam integration with storage/Tintri snapshots, though. It would be wonderful to utilize storage snapshots as the first tier backup, with a backup copy job to copy the snapshots to another storage device. Backups would then be nearly instant, and the backup copy of the snapshot would be "out of band" in a sense so it would not impact performance of the VM in any way.