First, identify the physical network adapters. On the Local Server tab in Server Manager (shown previously), click on the blue text after any of the network adapters to be taken to the network adapter configuration screen. Ensure you use consistent names for your adapters so that they are easily identifiable. Preferably, use a name that allows you to determine which physical adapter it represents. The simplest way to determine this is to either unplug the physical cable or disable its switch port in the switch's interface. Conversely, you can start with all adapters unplugged and connect them one at a time while you rename the adapters. The following screenshot shows an adapter being renamed:

You can rename an adapter by highlighting it and pressing F2 or by right-clicking and choosing Rename.

In the R2 series of products renaming the adapters may be unnecessary due to a new feature called Consistent Device Naming (CDN). If Windows is able to determine names from compliant hardware, it will automatically use them. They will show up with designators such as NIC 1 and SLOT 5.

Next, you'll want to create any teams that you intend to use. On the Local Server screen in Server Manager, click on Disabled next to NIC Teaming. You'll be presented with the Nic Teaming window. Click on the Tasks drop-down list in the Teams section and click on New Team. The following screenshot shows this:

In the screen that appears, first give the team a name. If you are teaming adapters for a specific purpose, such as Live Migration, name the team accordingly. If you are teaming for converged fabric (this concept is explained in detail in Chapter 5, Network Design), use a generic name. Next, check the adapters that will be used in this particular team. Finally, click on the drop-down list for Additional properties and set these items accordingly. If you're not certain what to choose, pick the Switch Independent teaming mode, as the other two require special settings on your switch. Clicking on the link after Primary team interface allows you to set the traffic on the new logical adapter so that it is tagged for a specific VLAN. Unless you have a specific need of this, it is recommended that you leave it in the default VLAN.

If you want the team to participate in a specific VLAN, it is preferred to use your switch's interface to place the switch ports in a native VLAN instead of tagging in the operating system. VLAN tagging at the team level is strongly discouraged if the team will host a Hyper-V virtual switch.

Once the team is created, it will appear in the previously empty boxes in the NIC Teaming window. You can double-click on these new objects to make any necessary changes. After creating or making changes to an LACP team, it is normal for it to show LACP negotiation errors for a short time after creation. If these don't disappear after a few minutes, check your physical switch configuration. Not all switches support all possible LACP methods. As with converged fabric, the teaming mode and load-balancing modes are explained in greater detail in Chapter 5, Network Design. They can be modified later, so don't worry too much about making an incorrect decision.

The creation of a team also makes a new logical adapter to represent it. This is now visible in Server Manager (after it refreshes) while the physical adapters that comprise it are now hidden. If you access the Network Connections screen, it will appear there as well, and you can configure it like any other adapter. Notice that the member physical adapters are still visible in Network Connections but are now unbound from everything except Microsoft Network Adapter Multiplexor Protocol. If the team will be used for a single purpose, you'll make any necessary changes (like IP addresses and DNS server entries) on the new logical adapter. If you'll be using the team to host a Hyper-V virtual switch included as a converged fabric, don't assign IP information.

After the above options have been set, configure the system's roles. In Server Manager, you can click on Manage and then Add Roles and Features or you can click on 2 Add roles and features from the dashboard. Screenshots are included previously in the section on adding the management tools to a Windows Server installation. This time, you'll want to select Hyper-V on the roles page and Failover Clustering on the features page. If you haven't already installed the related management tools, you will be prompted upon choosing the role or feature.

When installing Hyper-V as a role in this fashion, additional screens are added to the wizard. The first is simply informational. The next allows you to create a Hyper-V virtual switch. It is highly recommended that you create the switch later. If you create it now, you will not be able to set SR-IOV or the QoS method. The switch must be destroyed and recreated to set either. If you choose to create the switch now, you must ensure that you do not select a physical adapter that is part of a team. Instead, pick the logical adapter that represents the team as shown in the following screenshot:

The next screen is for non-cluster Live Migrations. Since you will be creating a cluster, you can simply skip past this screen. However, cluster members can still perform Shared Nothing Live Migrations to each other and to any other Hyper-V Server hosts in this or a domain with a proper trust configuration, so you may elect to set these options now. Of course, they can also be set later, so there is no wrong way to configure this screen.

The third and final new screen will involve storage of virtual machines. Ideally you'd like to give these targets a shared location. However, this node doesn't yet know about those locations. They can be changed later by accessing the Hyper-V Settings screen of the node in Hyper-V Manager. Proceed through the rest of the wizard.

When the installation completes, you'll need to reboot the server. You can do this by switching to the All Servers tab, right-clicking on the server, choosing Shut Down Local Server, setting the options accordingly, and clicking on OK.

If you chose to create a switch during the Hyper-V role installation, the management operating system will now have a virtual adapter on that switch which has any of the IP settings that were set on the adapter you assigned for the switch. If you don't want this adapter, the later sections of this chapter on Hyper-V Manager and PowerShell will show you how to remove it.

Before you can create a virtual switch, you'll need to know the Description of the network adapter you'll create it on. Open Network Connections. Each adapter will have a description field which is light gray in color in the default view. It will contain the hardware label, and if there are multiple adapters of the same manufacturer and type, a number. Since this is a long name, you can move the mouse cursor over each adapter to show the tooltip with the full name. You can also switch the view to Details mode. Refer to the screenshot in the previous section, Renaming network adapters, for examples.

Open Hyper-V Manager. Highlight the node in the left pane. Right-click on it and choose Virtual Switch Manager. Alternately, click on the link with the same name in the right pane. New virtual switch should already be highlighted. Ensure that External Switch is highlighted in the right pane and click on Create Virtual Switch. The following screenshot shows the resulting dialog with the information filled in:

You need to provide a name for the switch, which is vSwitch in this scenario. Under External Network, you must select the Description of the adapter you want to create the switch on. In this case, the Microsoft Network Adapter Multiplexor Driver is the description of the teamed adapter that was created in the preceding steps.

If you click on the checkbox to Allow management operating system to share this network adapter, a new virtual adapter will be automatically created and assigned to the management operating system. All settings from the selected adapter will be transferred to this new virtual adapter. The selected adapter will be transformed into a switch and will no longer have any TCP/IP settings of its own. You do not need to select this option now; it can be selected at any time. You can also use PowerShell to add virtual adapters (shown in the PowerShell portion of this chapter). They will be discussed in Chapter 5, Network Design.

As the dialog warning text indicates, you must select SR-IOV now if you wish to use it. It cannot be changed later. This checkbox has no effect if your network hardware does not support SR-IOV or if you create the switch on a team. SR-IOV is given in detail in Chapter 6, Network Traffic Shaping and Performance Enhancements.

This part is optional, and you will only need to follow it if you intend to use converged fabric. Please review Chapter 2, Cluster Design and Planning, if you need an explanation of this technology, or Chapter 5, Network Design, if you need more in-depth information. In order to make converged fabric work, you must create virtual adapters that are assigned to the management operating system. Currently, there is no method within the GUI to create these adapters. Please refer to the PowerShell section given later in this chapter, create the necessary adapters, and continue with the next section.

This is performed in the Network Connections window, and the process is the same as configuring static IP addresses on any other Windows installation. However, only the adapter you have designated for the management role should have assigned gateway and DNS addresses. Others should have only an IP address and a subnet mask. Furthermore, all adapters aside from the management adapter should be excluded from participating in DNS. More explanations will be provided in Chapter 5, Network Design.

If you don't recall how to get to the Network Connections screen, look under the Rename Network Adapters section. Right-click on an adapter and click on Properties. Double-click on the Internet Protocol (TCP/IP) with the version in use on your network (typically version four). Enter the IP address on the first page. To disable the registration of an adapter in DNS, click on the Advanced button, switch to the DNS tab, clear the checkbox titled Register this connection's addresses in DNS, and click on OK all the way back to the Network Connections window.

The management network and the Live Migration network must have their own IP addresses. It is recommended but no longer required that you have a network dedicated to the cluster communications role as well. These IP addresses must be in separate subnets. These IPs must also be on distinct physical or logical (team or virtual) adapters. Additionally, if your connection to shared storage is over an IP network, you will need at least one address and adapter for that, also in a separate subnet.

Joining the management operating system to the domain is performed just like any other Windows Server installation. You can start on the Local Server page in Server Manager and click on the workgroup name to get started. If you didn't rename the system at the beginning of these steps, don't forget to do so.

The complete cmdlet for setting all necessary roles and features is shown in the following command:

Add-WindowsFeature –Name Hyper‑V, Failover-Clustering, RSAT‑Clustering, RSAT‑Hyper‑V‑Tools

If you are running Hyper-V Server, the Hyper-V role is already enabled, but there is no harm in naming a role or feature that is already installed. Adding the tools is recommended but optional since their functions can be performed remotely. You could use the IncludeManagementTools parameter to automatically install RSAT tools for indicated roles instead of specifying the tool names, although unlike the shown command, it will not install tools for roles that are already enabled.

Once the roles and features are enabled, a table will be displayed showing the outcome. If a reboot is required, this will be indicated in the Restart Needed column. If a reboot is necessary and you intend to use converged fabric, you will need to reboot before continuing. Otherwise, you may skip the creation of the virtual switch and return to that after completing the remaining configuration steps and rebooting the host.

Renaming network adapters in PowerShell is simple, and is shown as follows:

Rename-NetAdapter -Name "Ethernet 2" -NewName "Onboard 1"

You'll need to determine how Windows matches its adapters to the physical hardware. The easiest way to do this is to unplug all adapters except one or plug in all except one. The following command will show you which adapters are connected:

Get-NetAdapter | Where-Object "Status" –eq "Up" | fl Name

If you wish to see adapters that aren't plugged in, change Up to Disconnected. You can use the pipeline to automatically submit an adapter for renaming:

Get-NetAdapter | Where-Object "Status" ‑eq "Disconnected" | Rename‑NetAdapter ‑NewName "Onboard 2"

If you use the pipeline in a way that attempts to rename more than one adapter, only the first will actually get the new name. The rest will generate errors.

The next two sections will explain how to create the teams and switches that make up a converged fabric. If you prefer, there is a script that can automatically place all available physical adapters into a converged fabric for you. It is available from the TechNet gallery at http://gallery.technet.microsoft.com/scriptcenter/Create-ConvergedNetwork-2c98bc37. Converged fabric is explained in Chapter 5, Network Design, so read through that if you need more information.

Creating teams in PowerShell is a quick and simple process. You need to know which adapters you want in the team, what mode you want the team to use (Switch Independent, Static, or LACP), and the load balancing algorithm (Hyper-V ports, transport ports, IP address hash, or MAC address hash—R2 introduces Dynamic). You'll notice that there are more load balancing options available through PowerShell than there are in the GUI. The different options are covered in Chapter 5, Network Design. To create a team, use the following command:

New-NetLbfoTeam –Name "ManagementTeam" ‑TeamMembers "Onboard 1", "Onboard 2" ‑TeamNicName "Management" ‑TeamingMode SwitchIndependent ‑LoadBalancingAlgorithm TransportPorts

Remember that when you are entering parameters that have predefined options, such as TeamingMode and LoadBalancingAlgorithm, you can use TAB to cycle through their options.

The name you provide for the TeamNicName parameter will become the name for the logical adapter that represents the team. Choose a name that is short enough that it won't be burdensome to type into further PowerShell commands but which clearly indicates what function the team serves. If you do not provide this parameter, the logical adapter name will be identical to the team name.

This sample creates a team on two adapters, presumably for management, and leaves other physical adapters available for other purposes such as other teams. The examples throughout this book combine available adapters into a single team called vTeam.

Unlike the GUI role wizard, adding the Hyper-V role by PowerShell does not automatically create a virtual switch.

The following command will create an external virtual switch that can be used for both converging management operating system roles and hosting virtual adapters for virtual machines:

New-VMSwitch –Name "vSwitch" ‑AllowManagementOS $false ‑NetAdapterName "vTeam" –EnableIov $false ‑MinimumBandwidthMode Weight

The shown command creates a virtual switch and assigns it to an adapter with the name vTeam. Assigning a virtual switch to an adapter automatically makes it an external switch. You can create one external switch per adapter. That adapter can be physical or a logical adapter that represents a team. You cannot create a switch on a virtual adapter. When an adapter is assigned to a virtual switch, it can serve no other purpose. Switch types and details will be explored in Chapter 5, Network Design.

Setting the AllowManagementOS parameter to false prevents the command from automatically creating a virtual adapter. It does not block them from being added manually, as will be shown in the next section. If you omit this parameter or set it to true, a virtual adapter will be created that has the same name as the virtual switch. The IP settings that were assigned to the physical or logical adapter will be transferred to this new virtual adapter.

The only way to create virtual adapters for the management operating system is to use PowerShell. The command structure is very simple:

Add-VMNetworkAdapter –ManagementOS –SwitchName "vSwitch" –Name "Management"

The ManagementOS parameter is a toggle; if not included, the system assumes you are trying to operate on a virtual adapter assigned to a virtual machine and will prompt you to provide the VM's name. This toggle appears in all virtual adapter PowerShell commands.

Virtual adapters in the management operating system live a dual life. For PowerShell commands and operations that are related specifically to virtual adapters, they are referred to by the name that you provided in the creation command. For general network adapter commands and applications, they are called vEthernet (the name used in the command). So, the preceding command would create an adapter named vEthernet (Management).

With the requirement that cluster nodes use separate subnets for their various roles, you may choose to place them in separate VLANs as well. If you are employing virtual adapters on converged fabric for these roles, the virtual switch will need to handle the VLAN tagging for those adapters. Set VLANs on your virtual adapters with the following command:

Set-VMNetworkAdapterVlan –ManagementOS ‑VMNetworkAdapterName "Management" ‑Access ‑VlanId 10

The PowerShell command for IP address assignment is very straightforward. Only assign a gateway to the management adapter. Except for geographically distributed clusters, adapters for other cluster roles do not need, and do not benefit from, the ability to route. For those adapters, use the following:

New-NetIPAddress –InterfaceAlias "ClustComm" ‑IPAddress 192.168.30.10 ‑PrefixLength 24

The PrefixLength parameter refers to the subnet mask. This is given in CIDR notation; if you are unfamiliar with CIDR, consult with a networking expert or resource.

For the management adapter, which does need to be able to route, there is only one additional parameter, shown in the following code:

New-NetIPAddress –InterfaceAlias "vEthernet (Management)" ‑IPAddress 192.168.10.10 ‑PrefixLength 24 ‑DefaultGateway 192.168.10.1

There are a number of PowerShell commands that include the noun NetRoute for manipulation of gateway addresses. This topic is beyond the scope of this book.

In order to resolve the names of other computers and to register its own name, your system will need to know the addresses of DNS servers in your domain. Assign these addresses only to your management adapter:

Set-DNSClientServerAddress ‑InterfaceAlias "vEthernet (Management)" ‑ServerAddresses 192.168.1.20, 192.168.1.21

You do not want the other adapters to register their addresses with a DNS server as this can cause problems for other systems that try to communicate with the management operating system. Run the following command on those adapters:

Set-DnsClient ‑InterfaceAlias "vEthernet (LiveMigration)" ‑RegisterThisConnectionsAddress $false

The final major configuration change to be made during initial setup is to join the management operating system to your domain. This is a process that requires two PowerShell commands. The first sets up a PowerShell variable that holds the credentials that are used to join the domain. It is possible to completely script this. In this example, you will use a command that generates a pop-up box where you can type in the account information to join the domain. Remember to enter your credentials in DOMAIN\Account or account@domain format:

$JoinCredential = Get-Credential
Add-Computer –ComputerName . ‑Credential $JoinCredential ‑DomainName "Techstra.local"