Some administrators choose to place Hyper-V hosts outside of the domain for a variety of reasons. For single hosts, a workgroup configuration is sometimes chosen. Systems running Hyper-V are simply never joined to the domain, therefore a compromised Hyper-V Server system theoretically does not place the domain at any risk. Whether or not this is an effective strategy is simply not relevant when it comes to a cluster. A computer that is not an Active Directory member cannot participate in a Microsoft Failover Cluster. If it is imperative to move the Hyper-V hosts outside of the primary domain, the next best option is to create another domain. This domain can be a new forest. It can be a subdomain of your existing domain. Either way, it sets up a very effective security boundary that separates your Hyper-V hosts from your other systems. A concept diagram is shown as follows:

These Hyper-V Server hosts have been placed into a completely separate forest from the primary domain. This creates a completely disconnected domain system. An alternative would be to use a subdomain. In that configuration, universal groups would be able to cross the domain boundaries a little more easily, although a trust relationship would still be required for meaningful management. Making the trust one-way prevents accounts in the trusting domain from accessing resources in the trusted domain. So, in the above diagram, members of Domain Admins in techstra-hv.local would not have any rights or permissions in techstra.local. It would be possible for members of the Domain Admins group in techstra.local to access resources in techstra-hv.local, but only if they have been explicitly granted permissions.

A complete discussion of Active Directory domains and trusts exceeds the scope of this book.

Misconfiguration of a trust can reduce security, which is clearly worse than not using a trust at all. If you are interested in forming a solution similar to the above, please consult with an Active Directory expert. Keep in mind that every domain needs at least one domain controller. A single domain controller cannot host more than one domain.

Hyper-V Server itself provides a significant level of isolation for the virtual machines. Interactions between the host and guest are limited to what is provided by the Hyper-V Integration Services, if installed. For the most part, data transactions are limited to exchanges of key-value pairs. If a compromised virtual machine were able to interact with the host, it would do so through the Hyper-V Virtual Machine Management service. This service runs under the Local System on the Hyper-V host, which by default has no permissions anywhere else in the domain.

In conjunction with the built-in isolation of the hypervisor, virtual machines can be effectively walled off using networking equipment. The Hyper-V virtual switch that your virtual machines connect through has the same isolation capabilities as a standard network switch. The following diagram illustrates one way this could be put into practice:

In this scenario, the Hyper-V Virtual Switch is assigned to a physical adapter that connects directly to an Internet firewall. Incoming connections connect directly to that virtual switch and any virtual adapters assigned to it. Other physical adapters are attached to an internal switch that has assigned their traffic into VLANs. An adapter intended to carry iSCSI traffic is connected to a switch that has been set aside for that purpose.

It's not required that you connect all virtual machines to the same virtual switch. You don't even need to connect all the adapters in any given virtual machine to the same virtual switch.

You can create multiple external Hyper-V virtual switches as long as you have the physical adapters to support them. They can then be connected into your networking hardware to suit your security requirements.

Not all the concepts around isolation, security, and the Hyper-V virtual switches are presented here, so don't worry if you don't completely understand these diagrams and scenarios. They will be much more thoroughly examined in further chapters on networking. As you design your hosts and network environment, you only need to understand that if you wish to perform physical isolation of the virtual network adapters, you'll need to assign physical adapters in the host for this purpose. If you intend to use those adapters in a team environment for redundancy and load-balancing, you'll need to provide sufficient physical adapters to satisfy that need.