To Sergiu,
C1. “Shared” can mean so many different things. In the context of CSV emphasis is on multiple machines being able to read from/write to the volume.
C2 Please see second post here blogs.msdn.com/.../10507826.aspx. That post explains how CSV decides if Direct IO is possible for the entire volume or individual files on the volume. Out of the box both SQL and Hyper-V are compatible with Direct IO. But if you install something like file deduplication or other similar solutions that might put a filters on NTFS below CSVFS then we might go redirected. For file deduplication solution from Microsoft we will go FS redirected only for the files that actually are deduplicated.
Q1. All reads and writes will go directly from any node to your LUN so there should be no bottleneck for reads and writes. All metadata (file opens and close/file renames, file size updates etc) go to NTFS, that is located on Coordinating node. Moreover all metadata updates on coordinator node are done with write-through to make sure they would not disappear in case of fail-over. For workloads that are mostly about reads and writes one or two LUNS should not make any measurable difference. For workloads that are metadata heavy having 2 LUNs might help. SQL and Hyper-V for majority of cases cause very few metadata operations. Exceptions might be initial start/boot, live migrations and dynamic VHD grow, but even there I doubt you will find that much difference.
Q2. There are disk replication technologies on the market compatible with CSV. Some of that are implemented in the SAN and are compatible with Direct IO. Others are using filter that attaches on Coordinator node, and will cause CSV to go FS redirected. You can also use Hyper-V replica that is compatible with Direct IO.
Q3. I am not an expert in Hyper-V replica, but I do believe it can.
P.S. Also check out 3rd post that explains how to use performance counters to help to find bottlenecks blogs.msdn.com/.../10531462.aspx
Thanks
Vladimir Petter
Microsoft Corporation.