Software-based VM-centric and flash-friendly VM storage + free version
-
brbr5041
- Posts: 3
- Joined: Sun Feb 05, 2023 7:10 pm
Sat Feb 11, 2023 9:21 am
I'm looking to design a 2 node HyperConverged Starwind vSAN setup but would like to avoid the use of physical domain controllers as this would add additionally unwanted hardware/management/.... Now sadly live Hyper-V requires kerberos for Live Migration so there's no way out of not using Active Directory. Additionally (and sadly) Fail Over Clustering does not support AD DS so the Hyper-V hosts cannot be domain controllers themselves as a lab test showed that CSV's could not be created in the cluster.
However I realized why not just use two virtual DC's hosted on the two Hyper-V nodes. These DC's would be in their own "resource" forest completely separate from the production Forest. Their soul purpose would be to provide Live Migration authentication and since they would run outside of the Fail Over Cluster they would also avoid the chicken and egg problem (if the DC's were part of the fail over cluster) in case all Hyper-V hosts were brought down for some reason and the fail over cluster can't be brought up before the DC's inside of it.
Would this be a sound design? To avoid using physical domain controllers? An overview of this design is shown below where the "Cluster Forest" is the forest meant only to allow Live Migration. Additionally was also planning on using the ISCSI nic for these DC's as their traffic would be very limited.
-
brbr5041
- Posts: 3
- Joined: Sun Feb 05, 2023 7:10 pm
Sat Feb 11, 2023 4:20 pm
Agreed I have seen this KB too but here you talk about the DC being a physical device. I'm asking if there would be any inherit flaw in running the DC as a VM split over the two hosts OUTSIDE of the cluster. So if the complete cluster goes down you don't run into the circular issue of the fail over cluster and DC's needing each other to come up.
-
yaroslav (staff)
- Staff
- Posts: 4309
- Joined: Mon Nov 18, 2019 11:11 am
Sun Feb 12, 2023 2:18 am
When running locally DCs do not fail over. They are local VMs without failover capability: their storage is LOCAL and compute resources are not clustered, hence failover is not possible by design. One of them is primary another is secondary. They ARE to be out of the cluster as the failover cluster depends on DC. Having the domain down, while all the controllers are in the cluster introduces more complexity for troubleshooting. To sum up, the article discusses how to set up DCs to be OUT of the cluster.
Sure, you can set up redundant DCs in VMs outside of the cluster nodes.
Please note that StarWind VSAN does not require a domain for its operation, therefore designing and fine-tuning the domain is not related to StarWind VSAN operation. Please consider contacting your MSP or network specialist for any improvement of the suggested configuration.
-
brbr5041
- Posts: 3
- Joined: Sun Feb 05, 2023 7:10 pm
Sun Feb 12, 2023 7:24 am
yaroslav (staff) wrote:When running locally DCs do not fail over. They are local VMs without failover capability: their storage is LOCAL and compute resources are not clustered, hence failover is not possible by design. One of them is primary another is secondary. They ARE to be out of the cluster as the failover cluster depends on DC. Having the domain down, while all the controllers are in the cluster introduces more complexity for troubleshooting. To sum up, the article discusses how to set up DCs to be OUT of the cluster.
Sure, you can set up redundant DCs in VMs outside of the cluster nodes.
Please note that StarWind VSAN does not require a domain for its operation, therefore designing and fine-tuning the domain is not related to StarWind VSAN operation. Please consider contacting your MSP or network specialist for any improvement of the suggested configuration.
Thanks for the answer yaroslav this is also what I assumed. We would like to avoid physical DC's as the whole point of the datacenter is to converge everything to these 2 physical nodes and thus keeping the virtual DC's outside of the cluster is the best method for us.
-
savannah
- Posts: 1
- Joined: Fri Jan 05, 2024 2:40 am
-
Contact:
Fri Jan 05, 2024 2:44 am
It is definitely a good design. This approach avoids physical domain controllers and prevents chicken-and-egg dilemma.
-
jamesalan
- Posts: 2
- Joined: Tue Feb 20, 2024 4:54 pm
- Location: US
-
Contact:
Tue Feb 20, 2024 4:57 pm
Avoiding physical domain controllers and instead going for virtual DCs on those Hyper-V nodes sounds like a sleek move, especially to streamline and simplify your setup. Keeping them outside the cluster to dodge the whole chicken-and-egg scenario is smart thinking. Plus, leveraging the iSCSI NIC for those DCs seems like a solid plan given the minimal traffic they'd handle.
-
miloz
- Posts: 1
- Joined: Mon Sep 15, 2025 1:09 pm
Mon Sep 15, 2025 1:12 pm
Running virtual domain controllers outside the StarWind vSAN cluster sounds like a smart workaround. It avoids the “chicken-and-egg” problem, and since Microsoft supports this setup in Windows Server 2016 and later, it should work reliably.
-
infMatejM
- Posts: 2
- Joined: Thu Sep 25, 2025 12:49 pm
Thu Sep 25, 2025 2:38 pm
Just a heads up, Windows Server 2025 doesn't require a domain joined hosts anymore for live migrations (live migrations are now supported in workgroup failover cluster). The only major limitation is, that the failover cluster in this configuration doesn't support a file server role, but that should be self-evident. For pure Hyper-V role it works perfectly.
But if you do want to use DCs, don't install the role on physical hosts, just don't. It will work, but if anything bad happens to the physical host, have fun restoring both the DC, Starwind and Failover Cluster roles from backup at the same time (it will probably be easier to just build a new node from scratch).
What you should do is create 1 VM Domain Controllers on each node and don't add them to the Failover Cluster (leave them standalone).
