Solutions for Virtualizing Domain Controllers Part 1.

Back when we were originally architecting our virtualization infrastructure, there was the question of which domain we should join our virtualization hosts to. And the conclusion was to simply join them to the primary DC in our single forest arrangement, but this caused obvious problems. For one, the moment we virtualize that DC, we are in a precarious and untenable ‘nested’ dependency situation: the DC which is required to maintain the integrity of our HV cluster is itself hosted on a member cluster node, an impossibility. And so the backoff position was to move away from domain joined cluser nodes to a simple workgroup, while dropping the CSV and cluster failover functionality for the moment (which requires domain joined nodes). But ultimately, we do need that cluster failover functionality along with the other management benefits that are only conferred on domain joined machines. One solution is to commission a pair of highly available physical(!) machines as a primary and secondary DC as part of an entirely orthogonal forest for the sole and exclusive purpose of managing the virtualization cluster. But what an inefficient use of hardware, when one of the primary purposes of virtualization is hardware efficiency and consolidation! The link here discusses the workgroup and ‘separate domain’ options in further detail. I am also investigating the creation of a read-only physical backup DC which can exist in support of the primary forest, keeping the number of forests at one and allowing for the safe virtualization of the primary DC 0n a cluster node joined the the same domain.