Recently, Clement Huge, our DBA, attended a series of high-level meetings relating to virtualization with VMWare or HyperV for the data tier. The meetings considered physical HA installations (SQL server cluster, oracle RAC   on machine with geographical redundancy, etc...) and VMWare or HyperV HA virtualization. The meetings produced some concrete conclusions, which he summarizes as follows.  

• Virtualization can be a very good HA solution*: VMware for example will expose the database "engine" as a stand-alone entity for the DBA and the DBA would not be responsible for the HA solution. The system engineer, in charge of the virtualization will bear the responsibility for ensuring continuity.  Virtualization has become mature in developing such solutions. In essence VMWare would manage the two virtual nodes and as this is the database engine, shared disk resources do not present a problem anymore as you can add more disk in a much easier way by virtualization.  Downtime would be probably a bit longer perhaps 2 minutes, instead of 1 minute on a physical installation but this is still reasonable timeframe from a DBA perspective. 
• Virtualization is not the same as a physical device*: Database virtualization requires a thorough knowledge and expertise in the field. Virtualization applied poorly at the data tier will almost certainly produce very poor performance at the database engine level. We have seen degradations in performance from equivalent physical to virtual servers as high as 30%.  Using a virtual machine is not the same as using a physical device and this is a very important point to bear in mind.     
• No virtualization at the storage level*: The operating system will handle logically all things such as partition alignment and cluster size *64k* however the physical hard drives simply present a pool of storage to the virtual machine which can then allocated from that pool creating virtual hard drives.  In our experience one of the most debilitating problems for databases to deal with is hard drive I/O, for that reason we always play close attention to the hard-drives/controllers etc.  We do not recommend any virtualization at the database storage level, drives should be physical and individually identifiable.  Also remember that with a SAN or any attached device there are still elements of a single point of failure.  Lastly, if there needs to be a connection from the database engine to an attached storage device it should be gigabit Ethernet at a minimum and preferably fiber channel
• Be aware of OEM Vendor support*: Microsoft does not support SQL Server running on a non-Microsoft virtual solution and this is an important consideration if support is required from Microsoft.