Final result:
We reported the problem and got an official response I'm very unsatisfied with.
I provided a SQL trace of 7 minutes of processing that generated 180MB of transaction logs. But it appears they didn't look at it.
They said to:
* Check the SQL Server Version is supported - standard stuff
* Shrink the Transaction Log File - Useless advice, we explained in our report that the MDF and LDF file sizes were not an issue. we were doing TRN backups every 15 minutes....it was the sheer volume of transactions and subsequent large backup files that was the issue.
* Finally they said to check SIMPLE vs FULL recovery mode...We were told to use SIMPLE. Well in our report, we explained we were using FULL because we wanted point-in-time recovery. But they avoided that completely by telling us we must use SIMPLE.
Result, I didnt want to argue with VMWare since our Sysadmins were willing to give up point-in-time recovery for a Differential backup every 6 hours and the ability to recover back to then...they seemed to be ok with potentially losing 6-hours of stats, etc...
But whoever sees this, I hope you understand that VMWare did not really understand the issue: Why is their application generating so much TLOG activity?....and that they are in effect stating they do not support SQL Server's ability to restore to a point-in-time because when this happens they "Punt" to SIMPLE recovery mode. I am a DBA, not a sysadmin and this drives me crazy...but I have other things to work on.