I've been there! Last year I set up a similar cluster (except my boxes were Fujitsu) using an iSCSI SAN for Hyper V.
Actually it's not that hard, but there are going to be snags along the way. If you are colocating, I would definitely be rehearsing your installation in a server rack on your own premises before moving it to the datacentre (I used a soundproofed server cabinet for this).
Oh, one other thing in preparation, you don't mention this, but one thing I wouldn't bother with is iSCSI boot which is offered on some iSCSI systems. It's a pain to set up and it doesn't always work with redundnancy. It's always better to have one or two physical boot disks on the nodes so that if you have a network configuration problem or iSCSI issue, you can still boot them up. I use small (40GB) solid state drives in each of my servers for boot disks.
You definitely need a separate AD DC. In fact I started with a 3 node cluster and then limited this to 2 nodes, plus an unclustered 'master node' which runs backups on DPM 2010 and a virtualised DC.
You mention 6 ports, this may be enough. But allow me to illustate my node configutation which has 10 ports:
- You will always need 2 ports per node for the iSCSI network (each one belongs to a different subnet for MPIO redundancy and should be on separate NICs)
- 1 port for heartbeat that doesn't have any other traffic on it
- 1 port for live migration and transfers (this is the only one that you might want to upgrade to 10g or infiniband, but unless you are provisioning 10s of VMs per day it is not worth it)
- 1 port for remote desktop access
- 1 port for server management card
- 1 set of teamed ports that constitutes the main access network*
- 1 set of team ports that consitutes a DMZ network (optional)*
*It is often pointed out by detractors that Microsoft does not officially support port teaming (whereas VMWare does) but actually official word is that they don't discourage it, but simply feel that support is in the hands of the NIC vendors. I use Intel NICs that are of the ET generation, which have specific virtual network features and I find work very well with Hyper V. They actually allow you to split a team between switches so that if one of the switches fails you have consistent team access, a bit like MPIO but for virtual machines.
Hyper V is actually really resilient and good to use. I would approach your job in this sequence:
1) Set up the nodes individually, install iSCSI initiator, install MPIO, give your iSCSI ports, transport and heatbeat ports, management ports different subnet addresses.
2) Set up Hyper V and assign your chosen ports to your virtual network
3) Then run the cluster validation wizard and form the cluster.
You should always assign ports to your virtual network first, because this prevents them from being used by the cluster. This sounds counter-intuitive, but basically you are going to be keeping your virtual network agnostic to your cluster network. This still gives you redundancy, so don't worry. But to achieve this (and there is no other way) you are going to have to have either a separate set of switches for your cluster and hyper V (two each for redunancy) or you will need to set up VLANs on your switches. I do the latter (using untagged VLANS) and it works great.
Some other posts here have suggested that you use a consultant to do this work. If they are familiar with Hyper V, this may be a good idea. It doesn't give you the indepth knowledge that you'd otherwise acquire from DIY, but it will save you time. I had plenty of time last year, and I'm not embarassed to admit that it took me several months of work and figuring things out to get it all up and running.