One of the most frustrating things about Hyper-V Replica (which I believe is the best feature of Hyper-V Server 2012 and truly a game changer to SMBs) is the lack of totally CLEAR and UNAMBIGUOUS up front information relating to the support of mission critical systems like SQL Server and Exchange.
Both SQL Server and Exchange databases have one thing in common - they write out to a log whenever data is committed before they write out to the main data store. This ensures consistency under all recovery situations with excellent performance and the ability to replay transactions etc etc. Best practice is to put the logs and databases onto 'different disks' to improve performance/recovery. In the context of Hyper-V this is interesting as it means placing a Hyper-V vhd(x) file onto it's own physical disk. Either way that is a different discussion.
However, this is the undoing of Hyper-V Replica since it does not guarantee that writes to different disks will be applied to the replica in the same order. This could create disastrous results where the log and main data store are subtly out of sync whilst fooling the administrators of the system that everything is working perfectly. That is the worst possible scenario. During a planned fail-over when the primary is closed down in an orderly manner it would appear to work beautifully as the disks would all be sync'd but come the day of disaster and the writes have not been applied in the correct sequence it would not work correctly and you are out of business - literally. There should be far more on this subject.
The worst aspect is that you have to know the problem might exist to start hunting down the answer and that means you will be trawling around for a while looking for reasonably definitive information. Those unaware of the foibles of SQL, Exchange et al are waiting to fall at the first unplanned fail-over.
At time of writing I found that SQL Server is supported
http://support.microsoft.com/kb/956893
and Exchange is not supported
http://blogs.technet.com/b/rmilne/archive/2013/07/29/exchange-and-hyper-v-replica-support.aspx
However, I cannot see any reason why Exchange not using DAGs would not work perfectly. I suspect that DAGs are the supported option so that is what you are forced to use. The Hyper-V replica is certainly much easier to set up and maintain for smaller organisations with say 1 Exchange server than a DAG. I can see Hyper-V replica and DAGs together would be a very poor idea.
When Hyper-V 1 first came out (remember the 180 day promise after Server 2008 RTM!) I ran a Blackberry Enterprise Server 4.1 on it even though it was not supported. I knew it would just work and it did for several years until the BES Server was replaced. I did not expect any support from anyone but that is always the best way so you know in your own mind you are doing it right!
So if you want to use a SQL Server workload you will need to use the EnableWriteOrderPreservationAcrossDisks flag on replica creation using the
Set-VMReplication cmdlet.
This means you must use PowerShell to create the replica as unfortunately this flag is not available in the GUI so the unknowing will not set it or be aware of it.
This flag should be in the GUI, and it should have comments like:
This feature ensures data writes are consistent across disks for Enterprise database systems such as SQL Server
This flag should be set if you are running a SQL Server workload - see KB111111
Exchange workloads are specifically not supported - see KB222222
For other workloads please read KB333333
What I don't understand is that if there is little performance loss or other downsides (I don't know) then setting that flag ON should be the default behavior when you create a replica and not a hidden away afterthought.
