I won't bore you with the whys or hows, but just know that there are certain configurations of Windows Server 2012 clustering that are perfectly ok to run on vSphere. Let's take, for instance, the cluster nodes that use in-guest iSCSI to connect to shared storage. Those virtual machines do not traverse the hypervisor storage stack to get to their storage and work just as they would on physical servers, so why call that unsupported? How about the use of SMB 3.0 as a target for shared storage for a failover cluster? That also uses the virtual machine network stack and avoids the hypervisor storage stack, so why would that be called unsupported?
Well, it's not unsupported, as of now. It's perfectly fine! The fact is, it's not VMware's place to support these configurations. They pass the failover clustering validation wizard, which means, Microsoft sees no problem with them. VMware has acknowledged this in the latest revision of KB article 1037959 (http://kb.vmware.com/kb/1037959), not directly but take a look at the support matrix and you will be pleasantly surprised. Also take a look at the various footnotes as there are some details around specific configurations.
Windows Server 2012 clustering is still not supported when using the more traditional method of mapping shared disks using fibre channel raw-device maps directly to virtual machines using a shared SCSI bus. Nonetheless, we are making progress. There are more ways to skin this cat, VMware customers realize this, and that's why this update in support was made.
A couple of other notable additions include the calling out of SQL AlwaysOn Availability Groups and Exchange 2013 DAG on Windows Server 2012. Of course both of these are non-shared disk clustering technologies, but the fact that they use components of Windows failover clustering brought the supportability into question. Question answered.
Cluster (somewhat) freely my friends, but do so only when you need to. Remember, a failover in a Windows cluster may only take 30 seconds to recover, but a VM can typically boot up in less than 60. Is that amount of time worth it for you to add complexity to your environment? I’m just asking the question, don’t point that gun my way…
-alex
In case you didn't catch it: http://kb.vmware.com/kb/1037959
