I am curious to the replies to this topic as I am in the same boat myself. I do share the same opinion though that Data availability and Application availability goes hand in hand (by application, you mean the SQL Server services itself, not the applications connecting to it).
Yes VMware snapshot technology is a nice to have for the likes of patching etc - however my understanding this that this does not work with shared disk storage and Microsoft clustering. Is this the case?
I think I've read some articles that in order to do Microsoft clustering, the disks has to be presented as RDM (Physical compatibility). And if the disks are presented as RDM, the snapshot capability is disabled. but that's for the data. If the OS itself though is presented as VMDK, then patching, and snapshots can still be done, it just doesn't affect the disks that were RDM (p).
Data availability - well snapshots of the data can be taken at a SAN level but is this the best method to employ.
Would a Single VM machine running SQL server and possibly deploying SQL Mirroring be a valid option here and give greater coverage incase of an outage. VM could be snapshot - data would be mirrored elsewhere - downtime and data loss kept at a min?
These are the same idea that is playing on my thoughts: On having a single VM, I would recommend testing out the vMotion of this single VM to another host. But it seems that having a cluster is still the better idea, just in case the host go down, or the application going awry, or if you want to do some patching on that one VM, if you want to do some configuration changes, etc.
On another hand, deploying SQL mirroring along with clustering seems to cover both data availability and application availability.
I am still in the "Virtualize or Not" cross-road. Are you able to successfully implement SQL Server on a VM? (I would probably need to spin up another thread for this question)