This is a good Reddit article explaining the benefits of using Quiesced snapshot method (enabling the “Quiesce VM” option in the VMware Backup job) in DataCenter 7.2.1 (and newer) for VMware snapshot backups where the guest OS uses Microsoft SQL / Exchange and other VSS and I/O heavy applications:
So firstly, when neither Memory State, nor Quiescent options are selected, the VM is snapped in what is called a Crash Consistent state. That is, when recovered, the VM is powered back on, and the "previous shutdown was unexpected." It basically behaves like a blue screen recovery. Any data not committed will have been lost, SQL server will roll back transactions if you're lucky, etc.
A quiesced snapshot is one where the VMWare Tools are used to access the OS and gather an application consistent snapshot. In non-Windows, and pre-2008 Windows operating systems, the tools include a VMWare VSS writer. In Server 2008+, the Windows VSS writers are used instead.
See Additional Information in this article.
So any application that is supported by Windows VSS writers have all transactions written before the snapshot is taken - and I/O is frozen until the snap is completed. SQL Server is a perfectly acceptable candidate for application consistency with quiesced snapshots, and most major SQL Backup vendors use the same mechanism as a quiesced snapshot for their SQL backup. This means that when you take a quiesced snapshot, a backup event is written to the SQL log, and database backup history as well. For high I/O applications such as exchange, there are recommendations out there for stopping those services before the snap to ensure that the VSS writers don't time out.
Now, here is an important distinction, which most people in this thread are getting incorrect. A QUIESCENT SNAPSHOT DOES NOT STUN THE OPERATING SYSTEM!! A quiescent snapshot utilizes the VSS writers to snap the running applications in a backup-suitable state. So SQL takes the same process it does any time a backup is taken - it prevents new transactions writing to disk, rolls forward transactions, etc., and puts the SQL instance in an application consistent state, and then the backup is taken. The OS doesn't freeze, the applications do.
As for the memory state, this is a default option. This option is what causes the state of the operating system to become stunned, and the duration of that OS stun is dependent on the memory utilization, the IO, etc. When the memory state is snapped, you can return to a running virtual machine. This backup takes the longest, and cause the most "downtime" in regard to the OS. In my environment, we do not snap the virtual memory, but we do quiesce the OS.