Is ReFS ready to host production VHDXs on Hyper-V 2012 r2 clusters?

The answer is a very clear "No".

ReFS only detects bit rot in user data if the file in question has "Integrity Streams" enabled (Sources: official TechNet docs, everyone's favorite blog post, and another spot). Oh, and you also lose COW (Copy-On-Write) when Integrity Streams are disabled. Since you cannot use a VHDX residing on a ReFS volume unless Integrity Streams is disabled, you cannot protect a VHDX against bit rot. Game Over.

It's like the same person who thought a Clustered Storage Space Pool should require at least 3 disks was also the one that made the decision to make the best thing about ReFS something you could turn off, and then got the Hyper-V people to require it to be disabled. It's hard to imagine that amount of "dumb" spread out so far across core teams like that.

Ancillary

While doing some testing, I found the following that may be useful to people who still wish to move forward:

• You can only SLM (Storage Live Migrate) an in-use VHDX to a ReFS-mirror volume if your destination is a folder where Integrity Streams have been disabled.
  • If you attempt to do SLM onto a ReFS-mirror where Integrity Streams is enabled, you'll get an error with this in it: "The destination '...' is not valid because it is configured with the integrity stream attribute. Select a destination that does not have the integrity stream attribute to continue.". You get the same error when attempting via PowerShell.
• Copying/Moving a file onto a ReFS-mirror will result in the file having its "integrity bit" set to match the setting from the destination folder.
• You cannot get/set the integrity bit of a VHDX that is in-use.
• Otherwise, the performance of a ReFS-mirror volume appears to be good enough (my opinion, of course) for Production. My "differences" test is here if anyone cares.