I don’t think that I clearly understand your plan, but this does not sound like the approach that I would take.
I would use tiered Storage Spaces. Let the system automatically manage all of your storage in a single pool.
Then just create VHDXs for the virtual machines as normal. I do not see a reason to create one massive all-encompassing VHDX.

thanks for all the many great articles about the usage of Hyper-V in daily life. After watching quite some trainings and reading a lot of material about it, I mostly miss information, what some of the things really mean be choosing a, b or c.

We are a creative company and run an SBS2011, first on a dedicated on dedicated hardware and later virtualized on Hyper-V. Now, time has come to replace it. We got a new HW and plan to completely set it up new. No migration of AD or Exchange. This will give us a new fresh start.

Our plan is to run Windows Server 2016 Standard with HV-role. Then, 2 VMs: VM1 = ADDC, DNS, DHCP and File Server, VM = Exchange 2016

For the files we use frequently, we got a 1TB NVMe SSD, all other data is on a hardware Raid5 (4 x 4 TB HDDs). So if I understand it right, I create a VHDX of the maximal size, format them with NTFS and create the shares.

I’m just a bit unsure, to use 10 TB VHDX is fine. With Altaro Backup we backed up only the VMs in the past. Now, we include the VHDX with all the data as well. Is that correct so?

I haven’t operated many VMware environments, certainly not enough to comment on that part of what you said. I never did anything like that at all. That’s not a value or judgment statement.
As I think through all of the ways that I could configure storage for Hyper-V, I don’t see anywhere that this sort of configuration would make sense over some other alternative. If you were trying to use a virtual machine to fool Hyper-V into using a loopback network-based storage mechanism, then the “best” configuration for the VM would be to use some sort of SMB 3 technique which still wouldn’t require or benefit from pass-through. But, I may not be entirely envisioning the use case that you’re talking about. I don’t want my guests to be aware of things like disk failure predictions because that sort of thing should be a host problem. I’m thinking that what you’re presenting here is one of those edge cases. It’s not normative in Hyper-V.

On VMWare, it’s fairly common to set up a storage VM that has direct access to disks (either via RDMs or having a controller passed through to the VM directly), then having that VM export iSCSI or NFS to the same host the storage VM is running on. This essentially allowed you to use software defined storage and skip the traditional hardware RAID controller. VMWare’s VSAN came along a while later as an option, but it’s expensive, and requires a minimum of 3 hosts. With a storage VM based on QuadStor (one of my favorite choices), it’s easy to set up a 2 node share-nothing storage cluster with no cost other than a decently fast interconnect between nodes (10Gbps, for example).

It was (and still is as of ESXi 6.0 Update 2) impossible to have the storage VM put it’s disks into virtual disks (VMDKs), because ESXi will have a small fit as soon as you put a VM on the disks the storage VM provides. It appears to be something to do with the nested virtual disks causing ESXi to going into a death spiral. The host stops responding completely in short order.

Looking towards Hyper-V, I would be inclined to use pass-through disks or a pass-through storage controller in the same manner as I’ve done in the past with VMWare. Maybe Hyper-V doesn’t suffer the same issue as ESXi with the nesting? I haven’t tested it. However, it would make more sense to use pass-through disks or controller for a storage VM anyway, so the storage VM’s OS can get direct access to the disks (this is important for file systems like ZFS and for disk failure prediction).

So there you have it – another use for direct disk access *grin*.

On VMWare, it’s fairly common to set up a storage VM that has direct access to disks (either via RDMs or having a controller passed through to the VM directly), then having that VM export iSCSI or NFS to the same host the storage VM is running on. This essentially allowed you to use software defined storage and skip the traditional hardware RAID controller. VMWare’s VSAN came along a while later as an option, but it’s expensive, and requires a minimum of 3 hosts. With a storage VM based on QuadStor (one of my favorite choices), it’s easy to set up a 2 node share-nothing storage cluster with no cost other than a decently fast interconnect between nodes (10Gbps, for example).

It was (and still is as of ESXi 6.0 Update 2) impossible to have the storage VM put it’s disks into virtual disks (VMDKs), because ESXi will have a small fit as soon as you put a VM on the disks the storage VM provides. It appears to be something to do with the nested virtual disks causing ESXi to going into a death spiral. The host stops responding completely in short order.

Looking towards Hyper-V, I would be inclined to use pass-through disks or a pass-through storage controller in the same manner as I’ve done in the past with VMWare. Maybe Hyper-V doesn’t suffer the same issue as ESXi with the nesting? I haven’t tested it. However, it would make more sense to use pass-through disks or controller for a storage VM anyway, so the storage VM’s OS can get direct access to the disks (this is important for file systems like ZFS and for disk failure prediction).

So there you have it – another use for direct disk access *grin*.

I don’t know enough about the applications of RDM in VMware to speak intelligently to that.
I have seen a handful of attempts to gather performance metrics of pass-through against VHDX in more recent versions, but they are not conclusive. With the variety of hardware quality and acceleration features available, pass-through is sometimes a bit faster, sometimes a lot slower. Pass-through is never a lot faster, though. If what you’re virtualizing is fit for virtualization at all, pass-through won’t speed it up enough to be worth the trade-offs.
The lone exception might be when you need to share storage between virtualized cluster members, but only so far as 2012 R2. Shared VHDX in 2012 R2 has a lot of the same limitations as pass-through.

Pass-through is the Hyper-V equivalent of RDM in VMware. If you are intent on duplicating your VMware environment in Hyper-V, then pass-through is the answer. I would not duplicate the environment, if it were me, but that’s not my decision to make.
There are no recommendations around LUN assignment. Assign as many or as few as you like. The nice thing about using a few large LUNs is that you need less overall slack space. The nice thing about many smaller LUNs is that the loss of one has reduced impact. Cluster Shared Volumes use volume identifiers that you will mask behind friendly names, so there are no drive letters in use.
If you are creating a true guest cluster in Hyper-V in which you require the use of a shared VHDX, then it’s not currently a wonderful technology although it is still better than pass-through. I’m not certain where you heard that CSV doesn’t support it, though. I don’t know any other way to create a shared VHDX. 2016 introduces a much superior solution for shared VHDX, if you’re willing to wait a month. All of that said, SQL can now operate from SMB 3 storage and that would be better than either pass-through or shared VHDX. That particular line of questioning is better handled by SQL experts.

I am actually looking into an enterprise NAS solution now. I’m not sure what I can say about it because of the hospital’s requirements around non-disclosure of configuration so I think I’ll leave it there. Preliminary results are promising. It offers native SMB 3 so we’ll be using it as though it were just a gigantic scale-out file server.