Nano Server is a new headless installation option in Windows Server 2016. Nano Server is similar to Windows Server in the server core mode, but without logon capabilities and the support of only 64-bit applications, tools, and agent. It provides a small OS footprint, a quick restart, and a far fewer updates. Since there is no GUI and no logon capabilities on Nano Server, the management is made remotely using PowerShell, WinRM, WMI or MMC. To run Nano Server in production, you need the Software Assurance. Nano Server (shortlink http://bit.ly/2acV3Q2) supports a lot of features such as Hyper-V, Failover Cluster, storage, and so on.

However, the servicing model provided with Nano Server requires a lot of build upgrade in a year. Nano Server follows the same servicing model as Windows 10 in enterprise called Current Branch for Business (CBB). CBB should be updated at least twice a year and it will be applied to Nano Server. These updates must be activated manually but Microsoft supports only the current branch and its immediate predecessor.

Because of the CBB servicing model, I do not recommend that you use Nano Server in production for Hyper-V and storage features. These features require efficiency and stability and need to be operational as long as possible. This is the exact opposite of what is provided by the CBB servicing model.

To create an unattended.xml file, you can either start from scratch with a simple text editor or use a GUI. To leverage the second option, follow these steps:

Start by adding the most basic components by expanding the Components tree under the Windows Image section in the left-hand corner of the tool. Let's now add language and locale information, through following steps:

In Windows Server 2012 R2, the Standard and the Datacenter editions have exactly the same features. The main difference between the Standard and Datacenter editions is the virtualization rights. Each Windows Server Standard edition allows you to run two guest Operating System Environments (OSEs) with Windows Server editions, and a Datacenter edition allows you to run an unlimited number of Windows Server VMs on this particular licensed Hyper-V host. There is only one technical difference between the two editions-on a Datacenter edition, all Windows Server guest VMs will be automatically activated when provided with a corresponding key during setup. There is no need for a MAK or KMS-based OS activation anymore.

With Windows Server 2016, some features are not present in the Standard edition compared to the Datacenter edition. The mainly missing features in the Standard edition are related to Storage (as Storage Spaces Direct), networking stack, and Shield VMs. As of Windows Server 2012 R2, the Datacenter edition allows you to run unlimited guest OSEs (or Hyper-V containers) while the Standard edition allows you to run two of them.

If you want to leverage Automatic Virtual Machine Activation (AVMA), storage features, and unlimited number of Windows Server VMs, install a Datacenter edition on the host. It is easy to upgrade a Standard edition to a Datacenter edition later, but there is no option to downgrade.

If you are not sure which edition you are using, open a PowerShell window with administrative privileges and run the following command:

get-windowsedition -online

To find out which editions are available for upgrade, run the following command:

Get-WindowsEdition -online -target

Finally, to upgrade to the target edition, run the following command:

dism.exe /online /Set-Edition:ServerDatacenterCor /AcceptEula
    /ProductKey:   <ProductKey>

Upgrade from the Standard edition to the Datacenter edition

While it's suitable to install a Datacenter edition on a Hyper-V host, you should never do this inside a virtual machine, except if you need specific features only available in the Datacenter edition. For example, if you want to make a virtual Storage Spaces Direct lab, you need the Datacenter edition to deploy this feature. In most environment, the Datacenter edition is deployed because it enables you to run unlimited guest OSes while the Standard edition enables you to run just two guest OSes. The next step in building our unattended installation is to set up the installation target and the edition. Navigate to the ImageInstall string under the Microsoft-Windows-Setup node and add the following code:

<ImageInstall><OSImage><InstallFrom><MetaData wcm:action="add"><Key>/Image/Name</Key><Value>Windows Server 2016 Technical Preview 5 SERVERSTANDARD</Value></MetaData></InstallFrom><InstallTo><DiskID>0</DiskID><PartitionID>2</PartitionID></InstallTo></OSImage></ImageInstall>

If you have chosen the UEFI-based setup, choose PartitionID 4 according to your disk setup. This will make sure that you install the Standard edition of Windows Server 2016 to the correct partition.

As the last step in Pass1, we will fill out the UserData tree under the Microsoft-Windows-Setup node and edit the following code:

<UserData><ProductKey><WillShowUI>OnError</WillShowUI></ProductKey><AcceptEula>true</AcceptEula><FullName>YourName</FullName><Organization>YourOrg</Organization></UserData>

Fill in Name and Org Data with anything you like; however, these fields are mandatory. The product key field is optional. If you intend to use a 180-day trial version of Windows Server or are leveraging KMS Server activation capabilities, do not enter a product key. If you are using MAK-based OS activations, enter your product key. You can also install a MAK product key at a later time by opening a PowerShell window with administrative privileges and running the following command:

slmgr -upk #(this uninstalls the current product key)
slmgr -ipk <key> #(including dashes)

After adding the basic parameters, it's now time to add some comfort to our Zero-Touch installation.

In Windows System Image Manager, add amd64_Microsoft-Windows-Shell-Setup_neutral to Pass4 and Pass7.

Edit the XML file to set your time zone settings (run tzutil /l in a Shell to get a list of all the valid time zones) and your local administrator password. Don't worry about entering a password into Windows System Image Manager; it will encrypt the password while saving the file. The following code shows how to set the regional and user information:

<settings pass="specialize"><component language="neutral" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-Shell-Setup"><TimeZone>W. Europe Standard Time</TimeZone></component></settings><settings pass="oobeSystem"><component language="neutral" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-Shell-Setup"><UserAccounts><AdministratorPassword><Value>UABAAHMAcwB3ADAAcgBkAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAUABhAHMAcwB3AG8AcgBkAA==</Value><PlainText>false</PlainText></AdministratorPassword></UserAccounts></component></settings>

To allow a rapid deployment of hosts, I have not entered a computer name at this stage, so the setup will generate a random computer name for each node installed. If you want to enter a computer name, add the following code to your XML-specialized section:

<ComputerName>Hyper-V01</ComputerName>

Another optional feature was selected right at the beginning of our XML creation-the GUI. By selecting the Windows Server Standard edition and not the Standard Core edition, we have included the complete GUI of Windows Server in our setup. Unlike Windows Server 2012 R2 version with Hyper-V, the GUI is now a feature that can't be activated or deactivated at a later stage. Note that the GUI is not available on the free Hyper-V Server 2016. The full GUI installation process offers the same great user experience we know from many versions of Windows Server and Windows Client operating systems, but Server Core is the installation method recommended by Microsoft for Windows Server 2016 and Hyper-V. The Core installation option offers a reduced attack surface with less patching efforts and fewer reboots. It even comes with a smaller resource footprint than its Full GUI equivalent. However, offering only a PowerShell Window as the single point of local administration discouraged many system administrators in the past, so Core setups aren't found often. Don't forget that all administrative APIs are active on a Core Server, so you can connect with your MMC consoles from other servers or clients without the need to use the PowerShell modules. Unfortunately, in Windows Server 2016 you can't switch from GUI installation to Core installation or vice versa.

The Minshell is also no longer available. In Windows Server 2012 R2, Minshell was a deployment option similar to the Core installation option but with Remote Server Administration Tools (RSAT).

GUI or Core installation

The basic operating system setup will now already be based on a Zero-Touch installation, but we want to achieve more than this and will include some additional options.

Add the amd64_Microsoft-Windows-TerminalServices-LocalSessionManager component to Pass4 and configure it to enable Remote Desktop Access to the server:

<?xml version="1.0" encoding="UTF-8"?>
<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-TerminalServices-LocalSessionManager">
  <fDenyTSConnections>false</fDenyTSConnections>
</component>

To reach the Server via RDP, via its designated IP address, we will also set the basic network settings. Keep in mind that based on your converged network setup for Hyper-V, these might be overwritten at a later step (Chapter 5, Network Best Practices).

Add the amd64_Microsoft-Windows-TCPIP component to Pass4 and configure a static IP Address-in this case, based on the name of the interface. This is also possible using the MAC address. Configure the network as shown in the following code:

<?xml version="1.0" encoding="UTF-8"?>
<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-TCPIP">
  <Interfaces>
    <Interface wcm:action="add">
      <Ipv4Settings>
        <DhcpEnabled>false</DhcpEnabled>
        <Metric>10</Metric>
        <RouterDiscoveryEnabled>true</RouterDiscoveryEnabled>
      </Ipv4Settings>
      <UnicastIpAddresses>
        <IpAddress wcm:action="add" wcm:keyValue="1">192.168.1.41/24</IpAddress>
      </UnicastIpAddresses>
      <Identifier>Local Area Connection</Identifier>
    </Interface>
  </Interfaces>
</component>

Whether Hyper-V hosts should be added to an Active Directory domain is a topic that is often discussed. Having seen a lot of Hyper-V environments, either domain-joined or workgroup-joined, my answer to this is a strong yes. Windows Server 2016 Servers can boot up even clusters when domain-joined without an Active Directory domain controller available, so this chicken-or-egg problem from earlier Hyper-V versions is not a problem anymore. Hyper-V will run without an Active Directory domain; however, very basic capabilities such as live migration won't be available on workgroup environments. Huge Hyper-V installations or high-security companies even leverage their own management domain to place their Hyper-V hosts into an Active Directory domain.

There is little security consideration standing against a huge management benefit, through credential management, group policies, and so on, so you should domain-join all Hyper-V hosts to your existing Active Directory domain. If your Hyper-V hosts will be placed in high-security environments, join them to a dedicated management domain (within a separated Active Directory forest) and not to your production domain.

Add the amd64_Microsoft-Windows-UnattendedJoin component to Pass4 and configure it to join an existing Active Directory domain:

<?xml version="1.0" encoding="UTF-8"?>
<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="amd64" name="Microsoft-Windows-UnattendedJoin">
  <Identification>
    <Credentials>
      <Domain>int.homecloud.net</Domain>
      <Password>Hannover96</Password>
      <Username>joindomain</Username>
    </Credentials>
    <JoinDomain>int.homecloud.net</JoinDomain>
    <MachineObjectOU>OU=Hyper-
    V,DC=int,DC=homecloud,DC=net</MachineObjectOU>
  </Identification>
</component>

A typical configuration that is seen in this step is the disabling of the Windows Firewall. In my opinion, this is a bad practice. The Windows Firewall is a great layer of security and should be configured to your needs, but not disabled. For a central Firewall configuration, we'll use Group Policy settings, so we don't need to include any configuration in our unattended.xml.

After our operating system is prepared to host Hyper-V, it's time to activate the Hyper-V components. Add the following product packages and their roles and features to your unattended.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<servicing>
  <package action="configure">
    <assemblyIdentity language="" publicKeyToken="31bf3856ad364e35"
    processorArchitecture="amd64" name="Microsoft-Windows-
    ServerStandardEdition" version="6.3.9600.16384" />
    <selection name="Microsoft-Hyper-V-Common-Drivers-Package"
    state="true" />
    <selection name="Microsoft-Hyper-V-Guest-Integration-Drivers-
    Package" state="true" />
    <selection name="Microsoft-Hyper-V-Server-Drivers-Package"
    state="true" />
    <selection name="Microsoft-Hyper-V-ServerEdition-Package"
    state="true" />
  </package>
  <package action="configure">
    <assemblyIdentity language="" publicKeyToken="31bf3856ad364e35"
    processorArchitecture="amd64" name="Microsoft-Windows-ServerCore-
    Package" version="6.3.9600.16384" />
    <selection name="Microsoft-Hyper-V" state="true" />
    <selection name="Microsoft-Hyper-V-Offline" state="true" />
    <selection name="Microsoft-Hyper-V-Online" state="true" />
    <selection name="VmHostAgent" state="true" />
    <selection name="AdminUI" state="true" />
    <selection name="ServerManager-Core-RSAT" state="true" />
    <selection name="ServerManager-Core-RSAT-Feature-Tools"
    state="true" />
    <selection name="ServerManager-Core-RSAT-Role-Tools" state="true"
    />
  </package>
</servicing>

After adding these Hyper-V components, the creation of our unattended.xml file is completed. You can download the complete sample XML file from http://bit.ly/1xBIQb2. Place the file in the root folder on the USB drive and boot the Server system from your installation media. You will now experience a fully Zero-Touch Hyper-V installation. In Chapter 2, Deploying Highly Available Hyper-V Clusters, you will learn how to advance this even further into a Zero-Touch cluster installation.

Unattended.XML file for automatic Hyper-V setup

Be sure to remove the USB drive with the unattended setup file prior to moving the host to production. A host reboot could otherwise force a reinstallation, including a wipe of all hard drives, due to the trigger of another unattended installation.

Run Windows Update to make sure that you have installed all the available updates. Are there any Windows updates you should not install on Hyper-V hosts? Yes, drivers should not be installed over a Windows Update unless support tells you to do so. However, besides this, install every available Windows Update in all of your Hyper-V hosts.

The Hyper-V role is already enabled, and we are ready to create VMs. To ensure network connectivity and safe operations of our VMs, we will configure some additional parameters after the installation.

First of all, we need some basic network connectivity for our VMs. If you have a second NIC available in your host, run the following command in an elevated PowerShell session:

New-VMSwitch -Name SW-1G -NetAdapterName "Local Area Connection 2"

If you have only one NIC, run the following command:

New-VMSwitch -Name SW-1G-NetAdapterName "Local Area Connection" -
    AllowManagementOS $true

When the virtual switch is created, you can manage it from Hyper-V manager:

Virtual switch settings from Hyper-V manager

Now, your virtual machines can use an external Hyper-V switch named external to communicate over the network.

Ever wondered about the many errors your RDP-mapped printer can create on a Hyper-V host? I could not believe this for a long time, but recently, I have seen a Hyper-V Server with the blue screen due to improper printing drivers. Do you need to print from a Hyper-V host? Absolutely not! So, make sure that you disable RDP Printer Mapping through a Group Policy (or Local Policy).

Navigate to Computer Configuration | Policies | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Printer Redirection | Do not allow client printer redirection and select Enable in a Group Policy.

Disable RDP printer mapping

Hyper-V uses some default paths to store virtual machine configuration and its hard disks. I find this very interesting, but it is definitely not suitable for a production environment. Make sure that you change the default paths, if possible to a nonsystem drive, by running the following commands in an elevated PowerShell window:

Set-VMHOST -computername localhost -virtualharddiskpath 'D:\VMs'
Set-VMHOST -computername localhost -virtualmachinepath 'D:\VMs'

I have not seen any issues in placing VM configuration files and virtual hard disks into the same folder structure. You have everything your VM configuration depends on in one place.

A Hyper-V host is a Hyper-V host and nothing else. Move all the other services into virtual machines that run on the Hyper-V host.

Moreover, also keep the following points in mind:

Another great topic for discussion is whether you should install an antivirus client on a Hyper-V host or not. Many companies have compliance rules stating that on every Server or every Windows machine, an AV client needs to be installed. If there is a rule like this in place, follow it and install an AV agent on your Hyper-V hosts. Make sure that you also implement the long list of files, which contain all the Hyper-V configuration files and virtual machine data, you have to exclude from your scans.

I have seen antivirus engines on Hyper-V hosts doing bad things such as breaking a virtual hard disk, deleting an essential system file, or just producing a very intense amount of storage IOs. Excluding all relevant files and folders regarding Hyper-V and its VMs, there is nothing left worth scanning on a Hyper-V host. If you are not bound by a compliance policy, I highly recommend that you do not install antivirus products on Hyper-V.

There are some approaches for Hyper-V-aware antivirus products; however, I have not seen one flawless working solution as of today, so you should protect your VMs from malware from inside the VM by installing your AV agents into the virtual machines.

One of the most frequent configuration tips around Hyper-V hosts is to manually configure the pagefile. The values described are sometimes quite creative.

After doing many tests with Hyper-V hosts with all different kinds of RAM configurations and deep technology-oriented exchanges with Microsoft Product Teams, including the Hyper-V Product Team itself, on how pagefile management work in Windows Server 2016, there is only one recommendation I have today-leave it alone.

The Windows pagefile is, by default, managed by Windows. If you have followed all other best practices described up to this point, and most importantly, you did not install other services on the Hyper-V host itself (management OS), you are all set. There is no way you can reach the same or even a better efficiency in pagefile management by manually altering this automatic configuration. I have not seen a single Hyper-V installation on Windows Server 2016 as of now that had problems with automatic pagefile management.

Again, this only affects the Hyper-V host and not the pagefile configuration of the virtual machines.

There are some more valuable post-installation tasks for performance management in Chapter 7, Hyper-V Performance Tuning. You can manage the pagefile as shown in the following screenshot:

Pagefile configuration

The most important factor in whether you need a HA environment is your business requirements. You need to find out how often and how long an IT-related production service can be interrupted, unplanned, or planned, without causing a serious problem to your business. Those requirements are defined in a central IT strategy of a business as well as in process definitions that are IT-driven. They include service-level agreements of critical business services run in the various departments of your company. If those definitions do not exist or are unavailable, talk to the process owners to determine the level of availability needed. HA is structured in different classes and measured by the total uptime in a defined timespan, which is 99.999 percent in a year. Every nine in this figure adds a huge amount of complexity and money needed to ensure this availability, so take the time to find out the real availability needed by your services and resist the temptation to plan running every service on multiredundant, geo-spread cluster systems, as it may not fit the budget.

Be sure to plan for additional capacity in an HA environment, so that you can lose hardware components without the need to sacrifice application performance.

The hardware used in a Failover Cluster environment needs to be validated against the Windows Server Catalog, as we did in Chapter 1, Accelerating Hyper-V Deployment. Microsoft will only support Hyper-V clusters when all components are certified for Windows Server 2016.

The servers used to run our HA virtual machines should ideally consist of identical hardware models with identical components. It is possible, and supported, to run servers in the same cluster with different hardware components, that is, with different sizes of RAM; however, due to a higher level of complexity, this is not the best practice.

Special planning considerations are needed to address the CPU requirements of a cluster. To ensure maximum compatibility, all CPUs in a cluster should be exactly the same model. While it's possible, from a technical point of view, to mix even CPUs from Intel and AMD in the same cluster though to a different architecture, you will lose core cluster capabilities such as live migration.

Choosing a single vendor for your CPUs is not enough. Even when using different CPU models, your cluster nodes may be using a different set of CPU instruction set extensions. With different instructions sets, live migrations won't work either. There is a compatibility mode that disables most of the instruction set on all CPUs on all cluster nodes; however, this leaves you with a negative impact on performance and should be avoided. A better approach to this problem would be to create another cluster from the legacy CPUs running smaller or nonproduction workloads without affecting your high-performance production workloads.

If you want to extend your cluster after some time, you will find yourself with the problem of not having exactly the same hardware available for purchase. Choose the current revision of the model or product line you are already using in your cluster and manually compare the CPU instruction sets at http://ark.intel.com/ and http://products.amd.com/. Choose the current CPU model that best fits the original CPU features of your cluster, and have this design validated by your hardware partner.

Ensure that your servers are equipped with compatible CPUs, the same amount of RAM, and the same network cards and storage controllers.

Mixing different vendors of network cards in a single server is fine and the best practice for availability, but make sure that all your Hyper-V hosts are using an identical hardware setup. A network adapter should only be used exclusively for LAN traffic or storage traffic. Do not mix these two types of communication in any basic scenario. There are some more advanced scenarios involving converged networking that can enable mixed traffic, but in most cases, this is a not good idea. A Hyper-V Failover Cluster requires multiple layers of communication between its nodes and storage systems. Hyper-V networking and storage options have changed dramatically through the different releases of Hyper-V. With Windows Server 2016, network design options are endless; refer to Chapter 5, Network Best Practices, for details. In this chapter, we will work with a typically seen basic set of network designs. We have at least six NICs available in our servers with a bandwidth of 1 GB/s. If you have more than five interface cards available per server, use Switch Embedded Teaming to ensure the availability of the network or even use converged networking (both features are also introduced in Chapter 5, Network Best Practices). Converged networking will also be your choice if you have fewer than five network adapters available. To ease the explanation, let's think about a host with the following six network adapters:

There is no need for a dedicated heartbeat network as in the older revisions of Windows Server with Hyper-V. All cluster networks will automatically be used for sending heartbeat signals throughout the other cluster members.

If you don't have 1 GB/s interfaces available, or if you use 10 GbE adapters, the best practice is to implement the converged networking solution described in Chapter 5, Network Best Practices.

In many environments, you will have several physical adapters or virtual adapters. For better manageability, I recommend you to rename the network adapters. In projects where I am involved, I always rename them with their purposes and the VLAN numbers. The following is an example:

With this naming convention, I can identify quickly the network interface and the VLAN ID.

All cluster nodes must have access to the virtual machines residing on a centrally shared storage medium. This could be a classic setup with a SAN, a NAS, or a more modern concept with Windows Scale-Out File Servers hosting virtual machine files, SMB3 file shares, or a hyperconverged model. Refer to Chapter 4, Storage Best Practices, for more information on finding the right storage solution for you. In this chapter, we will use a NetApp SAN system capable of providing a classic SAN approach with LUNs mapped to our hosts as well as utilizing SMB3 file shares, but any other Windows Server 2016 validated SAN will also fulfill the requirements.

In our first setup, we will utilize Cluster Shared Volumes (CSVs) to store several virtual machines on the same storage volume. It's not good these days to create a single volume per virtual machine due to the massive management overhead. It's a good rule of thumb to create one CSV per cluster node; in larger environments with more than eight hosts, a CSV per two to four cluster nodes is required. To utilize CSVs, follow these steps:

In this example, I added the MPIO feature to two Hyper-V hosts with the computer names Pyhyv01 and Pyhyv02.

SANs are typically equipped with two storage controllers for redundancy reasons. Make sure to disperse your workloads over both controllers for optimal availability and performance.

Once the LUN is available in the Hyper-V host, I recommend you to rename the volume and the CSV (in failover clustering manager) with the same name that you have provided in the storage device. This configuration eases the identification of the storage from the Hyper-V hosts and storage device perspective.

If you leverage file servers providing SMB3 shares, the preceding steps do not apply to you. Perform the following steps instead:

For more details on storage design and configuration, refer to Chapter 4, Storage Best Practices.

In Chapter 1, Accelerating Hyper-V Deployment, you installed your first Hyper-V host. To create a Failover Cluster, you need to install a second Hyper-V host. Use the same unattended file but change the IP address and the hostname. Join both Hyper-V hosts to your Active Directory domain if you have not done this yet. Hyper-V can be clustered without leveraging Active Directory, but lacks several key components, such as live migration, and shouldn't be done on purpose. The availability to successfully boot up a domain-joined Hyper-V cluster without the need to have an Active Directory domain controller present during boot time is the major benefit from the Active Directory independency of Failover Clusters.

Ensure that you create a Hyper-V virtual switch as shown earlier with the same name on both hosts to ensure cluster compatibility, and that both nodes are installed with all updates.

If you have System Center 2016 in place, use the System Center Virtual Machine Manager to create a Hyper-V cluster (refer to Chapter 8, Management with System Center and Azure); otherwise, continue with this chapter.

The quorum is a very important part of a cluster. The quorum helps to maintain the data integrity and avoids split-brain situations. If the network connections between the cluster nodes fail, a cluster node in an even-node setup would have no information if it is part of the isolated area through the outage and has to shut down all cluster services. If it is in the remaining part of the network, it would have to take over cluster services being offline due to the outage. For a successful vote determining which node or nodes are to take over the production service, a total of more than 50 percent of all cluster nodes will need to communicate. If, like in our situation with a two-node cluster, not more than 50 percent of the nodes are available, the node shuts down all its cluster services. In our scenario, both nodes stop all services and our cluster is completely offline to protect us from a split-brain situation. A quorum is another instance of getting to vote and ensuring that a majority of cluster resources are available to do a successful vote. In our configuration, the smallest storage volume got assigned as a quorum automatically. That's why we created a 1 GB LUN earlier. Using this LUN as a quorum ensures that there is a majority of votes available in an event that partitions an even-node cluster, such as a network outage.

In Windows Server 2012, Microsoft brought in Dynamic quorum, which enables assigning votes to a node dynamically to avoid losing the majority of votes and so that the cluster can run with one node (known as the last-man standing). Dynamic quorum works great when the failures are sequential and not simultaneous. So, for a stretched cluster scenario, if you lose a room, the failure is simultaneous and the dynamic quorum does not have the time to recalculate the majority of votes; this is why the witness should be placed in a third room.

The dynamic quorum has been enhanced in Windows Server 2012 R2. Now, the dynamic witness is implemented. This feature calculates whether the quorum witness has a vote. There are two cases, which are as follows:

So, since Windows Server 2012 R2, Microsoft recommends you always implement a witness in a cluster and let the dynamic quorum decide for you. The dynamic quorum has been enabled by default since Windows Server 2012.

A witness can either be a logical disk, a file share, or, since Windows Server 2016, a cloud witness. There are several reasons why you should prefer a disk witness over a file share witness if possible; for instance, the disk-based witness will host a complete copy of the cluster database whereas the file share witness won't. The cloud witness can also be a good option in the case of a stretched cluster between two rooms. A cloud witness brings you an external location for the witness at a low cost.

With the recent version of Hyper-V, you won't have to think about when to choose a quorum and how to configure it. You just specify a disk witness, if available, or a file share; otherwise, Failover Clustering automatically configures the necessary settings, regardless of the number of nodes. If you are currently using a two-node cluster and plan to add more cluster nodes later, you won't have to change the quorum model later. There are options to change the vote counts of the various resources, and the best practice is not to change them in typical cluster configurations. Quorum changes can occur online, and we can achieve this through PowerShell:

Set-ClusterQuorum -NodeAndDiskMajority "Cluster Disk
    2"

The preceding line represents Cluster Disk 2 as the label of the cluster resource. If you are using a file share witness, use the following option:

Set-ClusterQuorum -NodeAndFileShareMajority
    \\File01\Share01

To finish, if you want to use a cloud witness, use the following PowerShell cmdlet:

Set-ClusterQuorum -CloudWitness
    -AccountName StorageAccountName>
    -AccessKey <AccessKey>

Cluster Quorum Wizard

Live migration describes the ability to move running virtual machines between Hyper-V hosts. Since Windows Server 2012, this capability is not an exclusive cluster feature anymore, but most of the time they are utilized inside a cluster. You can use live migrations between standalone hosts or between different clusters as well; a shared-nothing live migration will occur, moving not just the RAM of the virtual machine but all of its virtual hard disks, which may consume a lot of network bandwidth and time. Typically, shared-nothing live migrations are used in migration processes and not in day-to-day work.

A live migration of virtual machines occurs every time a planned failover is executed on a Hyper-V cluster. The RAM of the virtual machine is synchronized between the nodes; the handles for the virtual machine configuration and its virtual hard disks are then failed-over to the new host. It's one of the most widely used features in Hyper-V, but often configured incorrectly.

An important aspect of the live migration process is the machine-based authentication. CredSSP is the default authentication protocol in Windows Server 2016. It is easy to use, but it's not the most secure solution and not recommended for production systems. If only one system gets compromised in the chain of delegation, all systems used in the CredSSP environment are compromised as well. Besides that, if you are using CredSSP for live migrations, you will have to log on to the source host first to initiate the migration process due to the one-hop limitation of CredSSP.

If your Hyper-V hosts are part of the same Active Directory domain—and in most cases they will be—you can use the Kerberos protocol for live migration authentication, which offers more security and gets around the limitations of CredSSP. Furthermore, it lets you define granular limits where the account credentials can be used. Use PowerShell to set constraint delegations on a system with Active Directory Management tools installed for all Hyper-V hosts involved, with the following script:

$Host = "pyhyv01"
$Domain = "int.homecloud.net"
Get-ADComputer pyhyv01 | Set-ADObject -Add @{"msDS-AllowedToDelegateTo"="Microsoft Virtual System Migration Service/$Host.$Domain", "cifs/$Host.$Domain","Microsoft Virtual System Migration Service/$Host", "cifs/$Host"}

Be sure to reboot the hosts afterwards so that this configuration can become active.

However, this will just allow pyhyv01 to delegate its credentials to pyhyv02. You have to do this vice versa on your two-node cluster. For bigger clusters, there is a script that enables all combinations for all your Hyper-V hosts (put them in a single OU, the best practice for many reasons) at http://bit.ly/1hC0S9W.

After we have prepared our Active Directory for Kerberos constraint delegation, we will activate incoming and outgoing live migrations for our Hyper-V hosts:

Enable-VMMigration -Computername pyhyv01, pyhyv02
Set-VMHost -Computername pyhyv01, pyhyv02
    -VirtualMachineMigrationAuthenticationType Kerberos

Live migrations are enabled using compression by default. RAM will be compressed to a ZIP-like archive before transmission and extracted on the target host. This is a great setting if you are using 1 GB/s NICs for live migration as it uses spare CPU cycles to compress live migrations to speed up the transfer. If you are using 10 GB/s network connections, switch live migrations to SMB3 for even better performance. Also, we increase the limit for continuous live migrations from two (great for 1 GB/s) to four simultaneous live migrations:

Set-VMHost -Computername pyhyv01, pyhyv02
    -MaximumVirtualMachineMigrations 4
    -MaximumStorageMigrations 4
    -VirtualMachineMigrationPerformanceOption SMBTransport

You can also configure these settings through the GUI of every cluster node, as shown here:

Live Migration options

Use the following command and later switch back to the defaults, if needed:

Set-VMHost -Computername pyhyv01, pyhyv02
    -MaximumVirtualMachineMigrations 2
    -MaximumStorageMigrations 2
    -VirtualMachineMigrationPerformanceOption Compression

In the GUI, the preceding command will reflect the changes, as shown here:

Advanced live migration options

The last setting for preparing live migrations is to choose the network for live migration. By default, all available networks are enabled for live migration. We don't change that. If our live migration network is unavailable and we quickly need to free up a host, we will use other available networks as well; however, by specifying a lower priority (the default is greater than 5.000) to our live migration network, we ensure it is preferred for live migrations:

Set-VMMigrationNework 192.168.10.* -Priority 4.000
(Get-ClusterNetwork -Name "Live-Migration").Role = 1

Live migration settings

We also set the basic configuration for the other cluster networks, as follows:

(Get-ClusterNetwork -Name "Management ").Role = 3
Set-VMMigrationNework 192.168.10.* -Priority 4.000
(Get-ClusterNetwork -Name "Cluster").Role = 1
(Get-ClusterNetwork -Name "Cluster").Metric = 3.000
(Get-ClusterNetwork -Name "Storage").Role = 0

The final network configuration should now look like the following screenshot:

Cluster network configuration

After that configuration, we are ready to initiate our first live migration. To do this, simply execute the following on our first host:

Move-VM "VM01" Pyhyv02

If you want to live migrate all virtual machines from one host to another, use the following cmdlet:

Suspend-ClusterNode -Name Pyhyv01 -Target Pyhyv02 -
    Drain

We are now finished with the configuration of our host cluster. For more advanced monitoring and tuning configurations for Failover Clusters, refer to Chapter 7, Hyper-V Performance Tuning.

You are now ready to test your cluster configuration before putting it into production. Power off a running cluster node hosting virtual machines by removing the power cables and see what's happening to your cluster. Do not use the Shutdown command or the buttons on the server as this would not be a real-life test.

Prior to Windows Server 2016, it was not easy to start a VM in the chosen order because it was based on priority (low, medium, and high) and/or an automatic startup delay in second.

Since Windows Server 2016, we can start a VM or a group of VMs in the chosen order by implementing dependencies between them. A group can hold a single VM or multiple VMs. This is why I recommend you always create a group even if a single VM belongs to a group. If later you want to add a VM to a step that does not involve a group in the VM start ordering plan, you have to remove the dependencies, create a group, add the VMs to the group, and again create dependencies. Instead, if you have created only groups, you just have to add the VM to a group.

The following example will create three groups called SQLServers, VMMServers, and OMGServers. The VMMServers and OMGServers groups will be dependent on the SQLServers group. To create the groups, just run the following PowerShell cmdlet:

New-ClusterGroupSet -Name SQLServers
New-ClusterGroupSet -Name VMMServers
New-ClusterGroupSet -Name OMGServers

The following PowerShell cmdlet configure the groups to be ready when the group has reached an online state. This means that the VMs in the dependent group will not start until the dependent group is online:

Set-ClusterGroupSet -Name SQLServers -StartupSetting Online
Set-ClusterGroupSet -Name VMMServers -StartupSetting Online
Set-ClusterGroupSet -Name OMGServers -StartupSetting Online

Now, create the dependencies between SQLServers and VMMServers, then between SQLServers and OMGServers:

Add-ClusterGroupSetDependency -Name VMMServers -
    ProviderSet SQLServers
Add-ClusterGroupSetDependency -Name OMGServers -
    ProviderSet SQLServers

Finally, add the related VMs to the groups:

Add-ClusterGroupToSet -Name VMVMM01 -Group VMMServers
Add-ClusterGroupToSet -Name VMVMM02 -Group VMMServers
Add-ClusterGroupToSet -Name VMSQL01 -Group SQLServers
Add-ClusterGroupToSet -Name VMSQL02 -Group SQLServers
Add-ClusterGroupToSet -Name VMOMG01 -Group OMGServers

Node fairness is an enhancement of the Failover Clustering feature in Windows Server 2016. It enables balancing virtual machines across the cluster node. It is enabled by default. If you manage your cluster from System Center Virtual Machine Manager, this feature is disabled for the benefit of dynamic optimization:

Node fairness configuration

You can configure the aggressiveness and the behavior of the automatic balancing using PowerShell. Before using cmdlet to configure these settings, it is important to understand each value. For aggressiveness, you can refer to the following table:

For the automatic balancer behavior, you can refer to these values:

To change the default value of these settings, you can run the following PowerShell cmdlet:

(Get-Cluster).AutoBalancerLevel = 3
(Get-Cluster).AutoBalancerMode = 1

There are no best practices for these settings. It depends on your application and whether you want the system to manage VM balancing. However, I recommend you to avoid being too aggressive because every 30 minutes the system can choose to migrate the VM.

Since you can move running workloads between cluster nodes without affecting production application performance, we will now add Cluster-Aware Updating (CAU), allowing our Hyper-V cluster to install updates by itself. This is a must-have configuration to ensure low maintenance operations for your Hyper-V clusters. CAU will automatically download and install updates to all cluster nodes utilizing live migrations.

In this way, we can update our cluster any time of the day without the need for service downtime. Execute the following cmdlet on one of the cluster nodes:

Add-CauClusterRole -ClusterName Cluster-Hyv01 -Force -
    CauPluginName
    Microsoft.WindowsUpdatePlugin -MaxRetriesPerNode 3 -
    CauPluginArguments @{
    'IncludeRecommendedUpdates' = 'True' } -StartDate
    "5/6/2014 3:00:00 AM" -
    DaysOfWeek 4 -WeeksOfMonth @(3) -verbose

Cluster-Aware Updating Console

You can even utilize an existing WSUS-Server as updating clusters has never been easier. Additional guidance is available for CAU in the Altaro blog at http://bit.ly/Vl7y24.

After creating a Hyper-V Failover Cluster on the host level, it is now time to create a guest cluster. A guest cluster is also a Failover Cluster and works the same way as our host cluster; however, its hosting applications are on top of operating systems instead of virtual machine workloads. A guest cluster is used in conjunction with a host cluster to ensure an even higher availability. Do not create guest clusters unless you are already using a host cluster; it won't increase availability to your services in a hardware failure scenario. However, they are great for planned failovers for maintenance purposes on one node.

The basic concepts and cluster creation are identical to the host cluster, that is running, the Cluster Validation Wizard successfully in order to receive support. However, with two running VMs hosting the same service, that is, a production ERP application, you should avoid running these two VMs on the same physical node on your Hyper-V cluster. You can achieve this using anti-affinity rules that ensure the VMs are placed on different hosts. This is possible via System Center Virtual Machine Manager (refer to Chapter 7, Hyper-V Performance Tuning) or with PowerShell. It is not possible with Failover Cluster Manager GUI. We will continue with the PowerShell approach for now. To create a new anti-affinity rule, execute the following commands:

(Get-ClusterGroup ERP-VM1).AntiAffinityClassNames =
    "GuestClusterERP1"
(Get-ClusterGroup ERP-VM2).AntiAffinityClassNames =
    "GuestClusterERP1"

These VMs won't be placed on the same host if possible. Check your current anti-affinity rules affecting a virtual machine by executing the following command:

Get-ClusterGroup VM1 | fl anti*

Since we are already operating in a virtual world, our network setup for our guest cluster is simplified. We just need the following three types of networks instead of five:

These networks need to be configured on the guest cluster additionally to any host cluster networks.

The best practice in a guest-cluster environment is to change the default failover-triggering heartbeat times to allow the execution of live migrations without any cluster activities. To change this from 10 seconds (the default value and suitable for physical clusters) to 25 seconds (TCP time-outs for live migrations are typically up to 20 seconds), execute the following PowerShell cmdlet:

(Get-Cluster).CrossSubnetThreshold = 25
(Get-Cluster).SameSubnetThreshold = 25

While our network setup benefits from the virtual world, the storage design is more complicated through an added layer of complexity. Just like our host cluster, the guest cluster needs shared storage between the two virtual machines, leaving us with the following storage options:

The last two storage options are explained further in Chapter 4, Storage Best Practices. We will use a VHD Set file to create our Failover Cluster:

You should choose a VHDS when using SMB3 storage since you are not connecting any LUNs to your Hyper-V clusters directly.

Adding a shared drive to VM

To enable Hyper-V Replica for your existing virtual machines, we follow a five-step process as shown here:

Set-VMReplicationServer -AllowedAuthenticationType kerberos -
        -ReplicationEnabled 1

Set-VMReplicationServer -AllowedAuthenticationType kerberos -`
        ReplicationEnabled 1
        -ComputerName "Pyhyv01", "Pyhyv02" 
        -DefaultStorageLocation 
    "C:\ClusterStorage\Volume1\Hyper-V Replica"

Set-VMReplicationServer -ReplicationEnabled 1 
        -AllowedAuthenticationType Certificate 
        -CertificateAuthenticationPort 8000 
        -CertificateThumbprint
    "0442C676C8726ADDD1CE029AFC20EB158490AFC8"

Add-ClusterServerRole -Name Replica-Broker -StaticAddress 192.168.1.5
Add-ClusterResource -Name "Virtual Machine Replication Broker" 
        -Type "Virtual Machine Replication Broker" 
        -Group Replica-Broker
Add-ClusterResourceDependency "Virtual Machine Replication Broker" Replica-
    Broker
Start-ClusterGroup Replica-Broker

get-clusternode | ForEach-Object  {Invoke-command -computername $_.name -
    scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTP
    Listener (TCP-In)"}}

get-clusternode | ForEach-Object  {Invoke-command -computername $_.name -
    scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTPS
    Listener (TCP-In)"}}

Set-VMReplicationServer -AllowedAuthenticationType kerberos -
    ReplicationEnabled 1 -ComputerName "Pyhyv01", "Pyhyv02" -
    DefaultStorageLocation "C:\ClusterStorage\Volume1\Hyper-V Replica"-
    ReplicationAllowedFromAnyServer 0

New-VMReplicationAuthorizationEntry -AllowedPrimaryServer
    Pyhyv01.int.homecloud.net
   -ReplicaStorageLocation C:\ClusterStorage\Volume1\
   -TrustGroup EYGroup01 
   -ComputerName Pyhyv02.int.homecloud.net

Preparing additional hosts

Repeat the steps for additional hosts, if you are using a more standalone Hyper-V server. Make sure you use consistent trust groups/security tags.

The GUI should reflect your changes as shown in the following screenshot:

Hyper-V replica configuration

Set-VMReplication -VMName VM01 
        -ReplicaServerName pyhyv02.int.homecloud.net ` 
        -ReplicaServerPort 80

Start-VMInitialReplication -VMName VM01

Start-VMInitialReplication -VMName VM01 -CompressionEnabled 1

-InitialReplicationStartTime 5/1/2014 7:00 AM

Set-VMReplication -VMName VM01 `
    -ReplicaServerName Pyhyv02.int.homecloud.net `

    -RecoveryHistory 24

-ReplicationFrequencySec 30

-VSSSnapshotFrequencyHour 4

Set-VMReplication -VMName VM01 -ReplicaServerName Pyhyv02.int.homecloud.net -ReplicaServerPort 80 
    -RecoveryHistory 24 -ReplicationFrequencySec 30 -VSSSnapshotFrequencyHour 4
Start-VMInitialReplication -VMName VM01 -CompressionEnabled 1 -InitialReplicationStartTime 5/1/2014
    7:00 AM

$HVSource = "Pyhyv01"
$HVReplica = "Pyhyv02"
$Port = 80
$HVdisabld = get-vm -ComputerName $HVSource | where {$_.replicationstate -eq
    'disabled' }
foreach ($VM in $HVdisabld) {
enable-VMReplication $VM $Replica $Port $Auth
Set-VMReplication -VMName $VM.name  -ReplicaServerName $HVReplica -
    ReplicaServerPort $Port -AuthenticationType kerberos -CompressionEnabled $true
    -RecoveryHistory 0 -computername $HVSource
Start-VMInitialReplication $VM.name  -ComputerName $HVSource

Monitoring Hyper-V Replica

Use Measure-VMReplication | format-list * to get details of the current replication processes. Use System Center Operations Manager for a complete health monitoring of Hyper-V Replica, as follows:

Monitor the state of Hyper-V Replica

Hyper-V Replica testing and failover

There are multiple options to test whether your replica is working. Execute a planned failover for switching one VM without data loss to the replica node. Be aware, this involves a short downtime of the VM:

Stop-VM -VMName VM1 -ComputerName Pyhyv01
Start-VMFailover -VMName VM01 -ComputerName Pyhyv01 
    -Prepare

The preceding command stops the original VMs and prepares both hosts for a planned failover. Execute the following command to force a planned failover:

Start-VMFailover -VMName VM01 -ComputerName Pyhyv02 
    -as Test

If your disaster takes place, just remove -as Test to start the real failover, and reverse the replication with the following:

Set-VMReplication -VMName  VM01 -ComputerName Pyhyv02  
    -Reverse

The question I get asked most often is how to automate this failover process. I strongly recommend that you do only manual failovers to avoid split-brain situations, where the same VM is powered on accidentally on both sites. However, for scripting, this in an on-premise situation. For more details, refer to https://blogs.technet.microsoft.com/keithmayer/2012/10/05/automated-disaster-recovery-testing-and-failover-with-hyper-v-replica-and-powershell-3-0-for-free/  or use the Azure Site Recovery service covered later in this chapter.

Another great way to test your replica is to do a test failover. This creates a copy of selected virtual machines in an isolated environment without affecting the production service. This way, you can test the replicated VM without any time constraints. Refer to https://blogs.technet.microsoft.com/virtualization/2012/07/25/types-of-failover-operations-in-hyper-v-replica-part-i-test-failover/ for more information on different failover types.

In a testing scenario or at a disaster site, it may be necessary to alter the IP configuration of the replicated virtual machines due to other subnets being used at that site:

Set-VMNetworkAdapterFailoverConfiguration VM01'
-IPv4Address 192.168.1.1 
-IPv4SubnetMask 255.255.255.0 
-IPv4DefaultGateway 192.168.1.254

To change the vSwitch of the VM for a test failover, use the following:

Set-VMNetworkAdapter ‚VM01' 
-TestReplicaSwitchName 'vSwitchTest01'

Have a look at the GUI representation of these options in the following screenshot:

Failover TCP/IP address of the replicated VM

After configuring these options, you are all set for widespread disaster recovery with Hyper-V Replica. You can even configure your replica VM to extend another replication to a third site, for instance, a partner datacenter.

Before you now start to mirror all your virtual machines at a cost, keep in mind that your workload needs to be able to handle the failover mechanisms of Hyper-V Replica. Hyper-V Replica requires all applications running inside replicated VMs to be able to handle an unplanned power-off of the VM, because this is exactly what happens in an unplanned failover scenario. Most applications have no problem with this, including the current versions of Windows Server Domain Controllers hosting Active Directory and Microsoft SQL Servers. Other applications such as Microsoft's Lync or Exchange Server are currently not supported in conjunction with Hyper-V Replica. Both applications however do provide great application-specific HA and DR mechanisms that should be leveraged instead.

Microsoft Azure provides a solution to back up your workloads to an external site. Instead of using tape disks in a library for long-term backups, you can use the cloud. A best practice for backups is the 3-2-1 rule, which is a follows:

Microsoft Azure Backup helps us to follow this best practice easily. When using this feature, you make a short-term backup on a local disk and a long-term backup in Azure. In this way you have two copies of the data in your datacenter and one in the Cloud. Thanks to Microsoft Azure, you have the different storage device and the extra site.

As for Azure Site Recovery, you need to create a backup and site recovery vault. If you do not have System Center Data Protection Manager (DPM), I recommend you use Azure Server Backup. This software is the same as DPM except that you can't back up to tape disks. Azure Server Backup is free and can be downloaded from the Azure Portal:

Azure Backup from Azure Portal

Once you have created the backup and site recovery vault, you can follow these steps to back up Hyper-V VM:

As discussed earlier, Storage Spaces Direct direct can be deployed in the disaggregated model. This means that you implement some file servers with their own storage devices. Then Storage Spaces Direct is used to aggregate storage devices such as HDD or SDD and then create some cluster shared volume to store virtual machines. Because of the use of Storage Spaces Direct, you don't need shared JBOD devices, but you can connect one JBOD per node or use internal storage devices connected by using SATA, SAS, or PCI Express ports.

Once the storage solution is implemented, you deploy SOFS in order that Hyper-V nodes can access storage by using the SMB3 protocol.

Disaggregated model

You should implement this kind of a solution when you want to independently control the scalability of the storage and computer planes. Adding a node with compute and storage hardware is more expensive than just adding a compute node or a storage node. This solution should be implemented for financial reasons and not for functionality.

Compared to the hyperconverged model, you lose flexibility. You need to be accurate when adding compute nodes to not collapse the storage. In the disaggregated model, the overall performance is divided across Hyper-V nodes. So, when you add a compute node, verify that your storage solution can support this new node in terms of performance and capacity.

To implement this storage solution, just follow these few steps:

Now your file server cluster is ready to store the VHDX virtual machine. When creating a VM from hypervisor, just specify the share path instead of the local storage.

Unlike the disaggregated model, the storage devices are placed inside the Hyper-V node themselves. This means that, when you add a node in the cluster, you add compute and storage resources. This solution is great for flexibility, scalability, and automation. The hyperconverged model should be implemented when you want to deploy a private Cloud in your datacenter. Thanks to the flexibility and the simplicity, you can add nodes on demand as almost every Cloud provider.

However, sometimes you want to add storage without adding compute and vice versa to save money. If you want to decorrelate the storage and compute, you should go to the disaggregated model.

Hyperconverged model

As you can see, Hyper-V and storage are installed in the same nodes. If you have a fast network, more than 10 GB/s, you can converge all networks (we will discuss network convergence in Chapter 5, Network Best Practices).

The storage devices located in each node are aggregated in a storage pool. This is possible, thanks to the Storage Spaces Direct feature.

Each node acts as a hypervisor and a storage node. So, be careful about the CPUs and the memory for each node. Microsoft recommends at least a dual-socket server with Intel Xeon E5 family v3 or v4 with a minimum of 128 GB of memory.

This solution is very simple to deploy:

At this point, you have a cluster shared volume ready to store the virtual machines. This solution is easier to deploy than the disaggregated model because you don't need the SOFS cluster role.

Multiple mixes of storage devices are supported by Microsoft to implement Storage Spaces Direct. You can mix NVMe SSD with SATA SSD or SATA SSD with SATA HDD and even mix NVMe SSD with SATA SSD and SATA HDD (we will discuss about this special configuration in the Multi-Resilient virtual disks section).

Storage Spaces Direct needs performance and capacity storage devices. The most preferred performance devices, for example SSD over HDD, will be set as caching devices. The others will be used for capacity and to store virtual machines. Microsoft supports the following configurations. Depending on the storage configuration, the caching behavior changes. This is because HDD devices need a read caching while SSD are fast enough and need only write caching. The specific case of three device storage configuration will be discussed in the next section. The following table introduces each supported storage configuration in Storage Spaces Direct and the related caching behavior:

The capacity devices are associated with the caching devices in the round-robin manner. If a caching device fails, the others are bound to capacity devices automatically. Because of the use of the round-robin algorithm, Microsoft also recommends that the number of capacity devices should be a multiple of the number of caching devices (for example, two caching devices for 10 capacity devices). Microsoft recommends installing at least two caching devices and four capacity devices in each server.

From four nodes in the Storage Spaces Direct cluster, you are able to create a Multi-Resilient virtual disk. This means that you implement the caching tier with NVMe devices and the capacity tier with SSD and HDD devices. The capacity tier can be composed of a mix of storage devices type because Microsoft brings the Multi-Resilient virtual disks.

Thanks to this feature, you can create a virtual disk with a mirroring tier and a parity tier. The mirroring tier is hosted by SSD and the parity tier is hosted by HDD. Thanks to the ReFS, the data will be always written in the mirroring tier. When the mirroring tier is full, the ReFS rotates the data which is less frequently used (called also cold data) from the mirroring tier to the capacity tier. If a data located in the capacity tier must be updated, the ReFS invalidates the data in the capacity tier and writes a new one in the mirroring tier. This ReFS capability is called ReFS real-time tiering.

A 3-tiers storage spaces Configuration

Thanks to this feature, you can optimize performance because the data is always written in the mirroring tier with fast devices such as SSD. On the other hand, you maximize the storage capacity by using HDD in a parity resiliency. If you implement a four-nodes cluster and you need high-end performance, I recommend this kind of solution.

To create Multi-Resilient virtual disks in an existing storage pool, you have to follow these steps:

The external vSwitch is bound to a physical network card in your Hyper-V host or on its abstraction layers, such as a logical teaming interface. VMs connected to this switch are able to communicate with network devices outside the Hyper-V hosts, that is, clients accessing VMs.

In Chapter 1, Accelerating Hyper-V Deployment, we already used PowerShell to create an external vSwitch:

New-VMSwitch -Name external -NetAdapterName "Local Area Connection 2"

For internal and private vSwitches, which I am going to introduce, the NetAdapterName parameter isn't available, since no external adapter is used. You also used the AllowManagementOS $true parameter earlier, which allows the same physical network adapter to be used for a virtual switch as well as for connecting to your Hyper-V hosts. This shared setup should only be used when you do not have enough physical adapters available and are not using converged networking, a concept I will introduce later in this chapter. Otherwise this is not a preferred configuration from a performance point of view.

The internal vSwitch is used for communication between virtual machines on the same host as well as communication to the Hyper-V host itself. It does not allow for external communication. This is used for isolated lab environments that involve the Hyper-V host, for example, accessing different VMs from the Hyper-V host.

To create an internal vSwitch, use the following cmdlet run from an elevated shell:

New-VMSwitch -Name internal `
             -SwitchType internal `
             -Notes 'Internal VMs only'

The private vSwitch allows for communication between Hyper-V virtual machines on the same host. It does not allow for external communication or communication with the host itself. This is mainly used for guest cluster networking as described in Chapter 2, Deploying Highly Available Hyper-V Clusters, as well as for lab purposes.

To create a private vSwitch, use the following cmdlet run from an elevated shell:

New-VMSwitch -Name private -SwitchType Private

Hyper-V networking is capable of using VLANs; however, they are not configured on a vSwitch level, but on a virtual interface level. The VLAN ID checkbox in the Virtual Switch Manager is only intended for setting a host OS VLAN when using the AllowManagementOS parameter.

Hyper-V offers two types of network adapters: the legacy network adapter and the default synthetic network adapter. The legacy adapter was primarily used for PXE boot capabilities. However, with only 100 MB of network bandwidth, it should be avoided. On generation 2 VMs, the legacy network adapter is no longer available and a PXE Boot is possible with the default network adapter there.

A network adapter is always connected to a vSwitch, which was described earlier in this chapter. After connecting the vmNIC to a vSwitch, we can now add this particular NIC to a specific VLAN. All network traffic to and from this VM will go through this VLAN (tagged). Instead of adding 15 different Ethernet cables to your Hyper-V host when using 15 different networks for your systems, it is a great option to enable VLAN trunking and communicate with just 1-2 physical NICs.

To add a single VLAN to our vNIC external via PowerShell, use the following cmdlet:

Set-VMNetworkAdapterVlan -VMName VM01 `
                         -VMNetworkAdapterName "External" `
                         -Access `
                         -VlanId 10

Set-VMNetworkAdapterVlan -VMName VM01 `
                         -Trunk `
                         -AllowedVlanIdList 1-100 `
                         -NativeVlanId 10

There are also additional capabilities for Hyper-V and VLANs, such as using VLAN isolation modes and promiscuous modes for more advanced scenarios with dedicated isolation and sharing requirements between VLANs (http://bit.ly/1mDy6GH).

It's best practice to stick to just one VLAN per NIC until you cannot fulfill your requirements with it. If you need to use trunking or other special scenarios, it is highly recommended that you use SCVMM for VLAN Management. Refer to Chapter 8, Management with System Center and Azure, for more details.

After enabling VLANs on our vNICs, we share a single or a few physical connections between these VLANs. To make sure our backup network is not using all the available bandwidth and impacting the production VMs, we use bandwidth management for our virtual interfaces, also known as QoS. QoS allows us to meet the service requirements of a service or an application by measuring the network bandwidth, detecting bandwidth limits, and prioritizing-or throttling-network traffic via policies. Hyper-V gives us the possibility to manage two QoS settings for networking:

These settings are provided on absolute bandwidth and are inflexible to hardware changes. It's best practice to set a minimum bandwidth, but don't restrict the maximum bandwidth. To set bandwidth limits leveraging this approach, use the following PowerShell cmdlet:

Set-VMNetworkAdapter -VMName VM1 -MinimumBandwidth 1000000

The absolute bandwidth is provided in bits per second and will be rounded to a byte. The settings will be reflected in the GUI:

Hyper-V virtual interface properties

In this example, I've also set the maximum bandwidth to 200 Mbps.

However, there is a far better approach using relative weights instead of absolute values. These values are not reflected in the GUI, so PowerShell is our friend again. To enable the use of weights, we first enable the vSwitch for relative weight and then set a default value to our created vSwitch.

Create a vSwitch with the DefaultFlowMinimumBandwidthWeight parameter as follows:

New-VMSwitch -Name external `

       -NetAdapterName "Local Area Connection 2" `

       -DefaultFlowMinimumBandwidthWeight

Set the external VMSwitch, DefaultFlowMinimumBandwidthWeight as 50. This weight will be assigned to all the adapters on the vSwitch without a specific weight. Set a higher weight (up to 100) for more important services, and less weight for less important services.

On a typical Hyper-V cluster, the following networks are available on each Hyper-V node, and I have attached my best practice bandwidth QoS configuration:

These networks and their weights are best placed on a NIC Team for redundancy.

When using SMB3 storage communication or live migration, it is recommended that you install RDMA network adapters for best performance. Since Windows Server 2016, you can converge SMB traffic with other traffic using SET as seen earlier. You can add each network adapter in the same subnet, and Windows Server 2016 will automatically configure these networks in the failover cluster.

Windows Server will also automatically spread the workload between the NICs using SMB multichannel. RDMA enables high-performance networking while using very little CPU load. SMB Direct will be automatically enabled when RDMA-capable NICs are detected on the host.

There are three types of RDMA-aware network architectures available. They are as follows:

All three types of architecture have the ability to provide a great performance for SMB storage communication and Live Migration. It is not necessary, in my experience, to use RDMA capabilities if you are not using 10 GB Ethernet or greater bandwidths for VM networking.

The solution presented in the following diagram is based on a NAS or a SAN and iSCSI protocol for storage traffic.

To implement this solution, the following hardware are required:

This solution is the cheapest solution involving a shared hardware storage system. This is because you can use the classical Ethernet switches and Ethernet NICs in Hyper-V nodes. However, it is not the most efficient solution because of the iSCSI protocol. In the next section, we will discuss the configuration of this solution from the operating system, networking, and storage perspectives.

Hyper-V Cluster connected to a NAS or a SAN with iSCSI

The following solution is nearly the same as iSCSI, except that the FC protocol is used between Hyper-V nodes and the SAN. To implement this solution, you need the following hardware:

This solution delivers more storage performance than iSCSI NAS/SAN because it provides high-end performance. This solution is also more expansive because of HBA, FC switches, and optical fibres.

This solution also requires the storage team to configure the zoning, the masking, the LUN, and so on.

Hyper-V cluster connected to a SAN using FC protocol

To implement these solutions, we will leverage network convergence (discussed in Chapter 5, Network Best Practices) for management (Active Directory, remote session, administration, and so on), cluster heartbeat, live migration, and VM networks. Only the storage traffic will be handled on dedicated hardware (Ethernet NIC for iSCSI and HBA for FC). The following is an example of IP addressing plan and associated VLAN:

The management network should be the native VLAN to ease the deployment of Hyper-V across the network using, for example, Virtual Machine Manager. We will discuss about Virtual Machine Manager in Chapter 8, Management with System Center and Azure.

In case of iSCSI, there are two storage networks, because each server has two NICs dedicated to storage and each controller in the storage system also has two network adapters. Each server as well as each NAS/SAN controller will use one IP in both storage networks. Most of the time, jumbo frame reduces CPU cycles and increases performance when it is used for storage. Before implementing it, make sure that your switches support this feature. You should perform a test with this feature enabled to validate proper functioning with jumbo frame.

To finish, LACP or other network teaming protocols will be not configured from the switches perspectives. Instead, it is Windows Server 2016 that will manage high availability as MPIO for storage and Switch Embedded Teaming for network convergence. Each switch port will be configured to support VLAN in the access mode for the storage port and in the trunk mode for other traffics.

If your SAN/NAS supports Offloaded Data Transfer (ODX), I recommend that you enable this feature to increase storage performance.

Regarding storage configuration, you should configure it to have at least two levels of performance. For example, you can create a LUN hosted in a RAID 10 and another located in a RAID 5. In this way, a highly intensive application, such as a database, can be stored in a RAID 10 and a less intensive VHDX in a RAID 5. A virtual machine composed of several VHDXs can spread its virtual hard disks across multiple LUN. For example, the operating system VHDX can be hosted in a RAID 5 while the VHDX which handles database can be hosted in a RAID 10. This avoids the consumption of all the RAID 10 storage space just for the operating system or for a low intensive application.

If a LUN must be bound to a virtual machine, avoid using pass through disks. If the LUN is intended to be shared across several VMs for guest clustering, prefer using the VHD Set (mentioned in Chapter 2, Deploying Highly Available Hyper-V Clusters). If the LUN is intended for any other usages, as backup volume for example, you can accomplish the implementation in two different ways depending on the underlying storage solution:

Hyper-V virtual SAN configuration

Both solutions require the same features to work with a iSCSI NAS or a FC SAN. Each node requires these features:

If you are using iSCSI NAS, don't forget to enable the service called Microsoft iSCSI Initiator Service in the automatic startup type to establish the connection to the NAS/SAN when the server starts.

Configure the Microsoft iSCSI Initiator Service to start automatically

If you are implementing either iSCSI NAS or FC SAN, you need to deploy a Switch Embedded Teaming with the dedicated NICs. Then, create and configure virtual network adapters as discussed in Chapter 5, Network Best Practices, for clustering, live migration, management, and VM networks.

Once the network is configured and the nodes are reachable, you can configure the storage. The storage configuration is different depending on the underlying storage system.

iSCSI configuration

The storage system will deliver four iSCSI targets (two per controller). From the Hyper-V perspective, two iSCSI initiators exist per node. Regarding this configuration, four iSCSI paths will be created (two per storage NIC) in the iSCSI initiator.

Each NIC should be connected to each storage controller. In case a storage controller is down, two iSCSI paths will still work. In case a network adapter is down, the other also will be connected with two iSCSI paths. With this design, you ensure a high availability of the storage connection.

Once the iSCSI initiator is configured, you have to enable MPIO and add support for iSCSI devices.

MPIO configuration

If you don't enable this setting, you will see several instances of each LUN. In this example, you will see four instances of each LUN-one per iSCSI path. To spread the storage workload across all iSCSI paths, MPIO adds a storage device driver. When MPIO is enabled, just one instance of the disk is shown and all the iSCSI paths are used simultaneously to increase the bandwidth and the availability.

Before implementing the cluster, I highly recommend that you try to disconnect some devices to try the high availability of the solution.

When LUN are mounted in each Hyper-V nodes, you can implement the cluster as mentioned in Chapter 2, Deploying Highly Available Hyper-V Clusters.

Before introducing each model available with Storage Spaces Direct, let's talk about network. Both solutions require the same network topology. The only difference is the location of the storage-in dedicated nodes or in the compute nodes. However, with both solutions you need the same network addressing plan. You require a management network (nodes deployment, Active Directory, remote session, administration, and so on), a live migration network, a cluster heartbeat network, a storage network, and all the VM networks. Instead of creating several storage networks, as we have done in iSCSI solution, with Microsoft Software-Defined Storage you can include all traffics in a single storage network. This is possible, thanks to the new Windows Server 2016 feature called Simplified SMB Multichannel (http://bit.ly/2bCcHir).

The following is an example of an IP network addressing plan:

Network topology

The management network should be the native VLAN to ease the deployment of Hyper-V across the network using, for example, Virtual Machine Manager. We will discuss about Virtual Machine Manager in Chapter 8, Management with System Center and Azure.

In either the storage or compute node, SET will be implemented to be able to make a fully converged network. Some virtual network adapters in the management OS require RDMA. Moreover, we need a high speed network adapter (at least 10 GB/s), so we have to leverage vRSS in the root partition for highest performance. This is why SET is required.

To ease the implementation of a fully converged network, I recommend that you implement the RDMA over the Converged Ethernet (RoCE) solution. In the version 2 of RoCE, the traffic can now be routable.

When you have created the virtual network adapters dedicated to storage and live migration, don't forget to enable RDMA:

Enable-NetAdapterRdma -Name Storage01

Because we will leverage SET, the switches will be not configured to use LACP for network high availability. The network high availability will be handled by the operating system.

As mentioned earlier, the network is same for both the Storage Spaces Direct deployment models. Let's introduce both models to help you to choose the design which fits your needs.

The disaggregated model shown in the following diagram requires two clusters-one for compute and one for storage. This solution is based on Windows Server 2016 technologies and Ethernet for the network.

The storage cluster is composed of three nodes at least. However, a four-node cluster brings you more features, such as multi-resilient virtual disks. This cluster can be extended to 16 nodes.

From the compute perspective, you need at least two nodes; however, I recommend three nodes to not consume half of the resources for the high availability. This cluster can be extended to 64 nodes.

Disaggregated model

To implement this solution, you need the following hardware:

Regarding licensing cost, the disaggregated model is more expensive than the hyperconverged model. You need Windows Server licenses for the storage and compute nodes. However, if you want to dissociate the storage and compute nodes, this is the solution to go with. If you know that you will add more Hyper-V nodes than storage, the hardware cost could be less than that of the hyperconverged model. Nevertheless, you need to handle the scalability of each pane.

The second design available when using Storage Spaces Direct is the hyperconverged model. The main difference, compared with the disaggregated model, is that storage is no longer handled by a dedicated storage node. In the hyperconverged model, the storage devices are located in the compute node. The storage devices can be connected internally or externally with a SAS connected JBOD enclosure. Disks can be SATA disks, SAS disks, or NVMe disks.

For this kind of solution, you need at least two nodes. Some features such as multi-resilient virtual disks and erasure coding are only available from four nodes. This cluster can be extended to 16 nodes.

Hyperconverged model

The main advantage of this solution is the flexibility and the scalability. Each time you add a node, you simultaneously add compute and storage resources. If you use high-speed network adapters (40 GB/s for example), you can install only two NICs in each node. This means that you have only three network cables connected to each node-one for baseboard management controller (BMC) and two for network adapters. This configuration eases also the network configuration and the cabling management.

Some hardware vendors sell a four-node solution in the same 2U chassis. This is a good solution for scalability, but be careful about the number of disks per node. Usually, you can connect a limited number of disks for each node due to the small form factor. If you want to connect a larger number of disks, prefer using the classical rack servers.

HP hyperconverged system

This solution is the cheapest from the software license perspective. You need only one Windows Server 2016 Datacenter license per node. In the disaggregated model, you need more licenses because there are more nodes deployed. If we compare with the hardware SAN system, usually you have extra licenses for the SAN itself and for the Fibre Channel Switches.

From the hardware cost perspective, this solution is more expensive than the disaggregated model in some case. For example, if you want to just add more computer resources, in the hyperconverged model you also have to buy storage resources. The hyperconverged model is usually less expensive than a hardware storage system also (compared to the same capacity and performance).

To deploy a hyperconverged solution, you need the following hardware:

This solution is also easy to deploy. Each node requires these features:

Once you have installed these features, you have to deploy a SET, as described in Chapter 5, Network Best Practices. With this solution, you need at least five virtual network adapters:

Once you have created SET and configured each virtual network adapters, don't forget to configure DCB, as described in Chapter 5, Network Best Practices.

Then you can create the cluster and implement Storage Spaces Direct, as described in Chapter 4, Storage Best Practices.

Let's have a look at the most important performance counters for Hyper-V; you can easily access them from perfmon.exe.

The following basic counters are important at the host level until otherwise noted, but most of them can be used at the VM level as well.

Windows Server with Hyper-V is optimized for performance as well as for green IT in the default configuration. Achieving both the targets at the same time is a trade-off. It is a trade-off for using nearly the best performance when needed while saving as much power as possible. Hyper-V supports a lot of power-saving options, such as CPU core parking or changing processor speeds, but not all of them. Standby mode and hibernation are not possible on a Hyper-V host. I recommend a green-IT approach. About two-thirds of all the costs of a server, in its typical life span, are generated from operating costs such as those for the cooling and the power of the system, and only one-third falls back on the initial costs of the server hardware itself. So, saving power is a very important factor when running IT infrastructures.

I have seen Hyper-V losing some benchmarks against other virtualization products, and on rare occasions, I have experienced performance trade-offs due to this green-IT-oriented behavior. By extracting the last few performance points of Hyper-V, but not caring about saving energy, it is possible to change this default behavior positioned on the power options of Hyper-V hosts.

A Windows Server installation, either at a physical or virtual level, will use the balanced power scheme by default. After switching this performance plan to high performance, I have seen better performance and lower latency on Hyper-V hosts with up to 10 percent difference. At the guest OS level (where a change in the power options does not have an effect), I have seen SQL databases perform up to 20 percent better when the underlying host uses the high-performance power plan.

I recommend that you use the following best practices:

POWERCFG.EXE /S SCHEME_MIN

Don't get confused; SCHEME_MIN does not refer to minimum performance but to minimum power saving. It has the CPU turbo frequencies always enabled, and it disables core parking.

After that, the GUI will represent the setting, as shown in the following screenshot:

Power options

To revert to the balanced power scheme, use POWERCFG.EXE /S SCHEME_BALANCED.

Whatever power plan you use, make sure that you use high-efficiency power supplies and fans of variable speed in your servers to save as much energy and money as possible.

There are several options available to get more performance out of your Hyper-V hosts, starting with hardware features and going over hypervisor and driver configurations up to application tuning and usage scenarios. Let's start with the hardware options by selecting high-performance hardware for our Hyper-V host.

Adding more CPUs and cores as well as selecting processors with Hyper-V threading benefits the VM ratio that our host can handle. Choosing CPUs with bigger caches improve the overall Hyper-V performance. As of early 2016, Intel offers CPUs with 55 MB smart cache, but they are nearly 7,000 USD far away from being as cheap as Intel's mainstream CPUs for virtualization.

Using CPUs with Second Level Address Translation (SLAT) is not required for server operating systems (for client operating systems, it is) but is highly recommended. SLAT is also required for VDI workloads. Adding SLAT options such as Extended Page Tables (EPT) or Nested Page Tables (NPT) increases the overall Hyper-V performance. To take it further, choose CPUs with a higher frequency. Intel's Xeon E7v3 CPUs deliver up to 3.2 GHz frequency with the option to auto-increase up to 3.5 GHz per core. A core with doubled frequency typically provides better performance over two cores with a single frequency. Multiple cores do not provide a perfect scaling; they provide lesser scaling if hyper-threading is enabled because hyper-threading relies on sharing resources of the same physical core.

There are only two supported CPU vendors for Hyper-V hosts as of today-Intel and AMD. I have tested both and was unable to detect a performance benefit for either one, so choose the vendor of your choice/price point. In my experience, AMD offers a little more performance per euro/dollar, while most of my Hyper-V customers use a standardized Intel setup for all workloads. Just make sure not to mix both vendors in your Hyper-V deployment, and you will be fine.

In terms of memory, you have already learned that a pagefile does not require any special configuration. Also, the amount of RAM needed by the Hyper-V host is determined and configured automatically, so you can focus on the needs of the virtual machines on the RAM configuration. In a hyperconverged scenario, be careful of the RAM that will be used for virtual machines and for storage, especially when you implement a lot of storage cache. In this scenario, for each 1 TB of cache, 10 GB of RAM will be used.

Do not use traditional PCI slots on your servers anymore; PCIe offers greatly enhanced performance. Make sure that you use PCIe v3.0 x8 and higher slots for 10-gigabit Ethernet adapters on the server's mainboard to not limit performance at this physical level.

If you have enough adapter slots available on your server system, use multiple NICs with fewer slots instead of single NICs with many ports for optimal performance and redundancy.

Network-hardware-tuning options

Choosing the right network hardware for your Hyper-V hosts can boost up your overall VM performance. There are several hardware features available for supporting the Hyper-V host. You have already read about SMB Direct with RDMA-capable network cards, but there are many more offload capabilities.

Receive Side Scaling (RSS)

RSS is an NIC-driver technology that enables the efficient distribution of a network that receives processing across multiple CPUs in multiprocessor systems. This basically means that whenever you are not using RSS, all the CPU requests to control Hyper-V networking are delivered to the first CPU core. Even if you have four physical CPUs with 12 cores each and with hyper-threading enabled, only the very first core receives these requests. If you use network bandwidths faster than 4 GB/s, there is a high possibility that you will receive a performance hit when not using RSS. So, make sure that it's available on your NIC, and on your NIC-driver and is activated. If this is the case, these network requests (interrupts) will be spread among all the available CPU cores.

RSS is only available on the physical host, but not inside virtual machines. Windows Server 2012 R2 offers a solution for this-Dynamic Virtual Machine Queue (D-VMQ). With D-VMQ enabled on our hosts, we can use RSS on our virtual machines.

To see if your adapters are ready for D-VMQ, check via PowerShell:

Get-NetAdapterVmq -Name NICName

Enable vRSS in one VM via PowerShell:

Enable-NetAdapterRSS -Name NICName

In Windows Server 2012 R2, vRSS didn't work on virtual NICs attached to the virtual switch on the host management partition. Thanks to SET described in Chapter 5, Network Best Practices, we can now leverage vRSS in the management partition. However, several features are not available when using SET such as Single root I/O virtualization (SR-IOV). So you have to choose which one is the best for you. To use vRSS in your VMs, it's necessary to use D-VMQ at the host level.

The following screenshot shows the Hyper-V guest with vRSS:

vRSS information in a Hyper-V guest OS

Single Root IO Virtualization

SR-IOV is another great capability in Hyper-V networking. It allows for a PCIe device, such as an NIC, to be presented to multiple devices, such as virtual machines. Think of it as PCIe virtualization. This only works when it is supported at a physical level (network card), on the server system (BIOS), as well as on Hyper-V. SR-IOV offers more performance than VMQ because it uses Direct memory access (DMA) for direct communication between the physical NIC and the virtual machine. All the other aspects of Hyper-V networking are bypassed so that there is no involvement of NIC Teaming, virtual switches, and other technologies on top of it. This allows for extremely low latency and will be a great option when Hyper-V network virtualization causes CPU impacts through RSS without DMQ, otherwise. However, this also means that if you use NIC Teaming, these NICs cannot be used for SR-IOV, and there is no vSwitch in between that allows for Quality of Service or other management. SR-IOV is compatible with live migration and other Hyper-V features that do not involve network virtualization.

In my experience, SR-IOV is a great choice when handling low-latency, high-bandwidth VMs (for example, VoIP communication) and should be used when the traditional networking model, without SR-IOV, does not deliver enough networking performance. However, it should not be your default option because of the decreased management capabilities.

There is a great blog series about SR-IOV by Microsoft's John Howard available at http://bit.ly/1uvyagL.

Other offload capabilities

Checksum calculation on your NICs can offload the calculation and validation of the TCP and UDP checksums as well as the IPv4 and IPv6 adapters. This feature should be available and activated on all used network adapters with Hyper-V.

When using network traffic encryption with IPSec, you should use the IPSec offload; otherwise, you will see a 20-30 percent performance hit on your Hyper-V CPUs. However, you should use IPSec only when the security standards of your company tell you to, unless you leave them disabled.

Jumbo frames are another great option to boost network traffic; however, they need end-to-end configuration to work properly. On the physical NICs of the Hyper-V host, configure jumbo frames according to the packet size. The recommendation for most Intel NICs, for example, is an MTU of 9014 bytes. While jumbo frames don't need any configuration on the Hyper-V vSwitch, they need to be configured on the physical switch port as well as on the guest OS NIC. After configuration, you can test your configuration easily using the ping command with huge packet sizes:

ping -f -l 8500 192.168.1.10

It's best practice to enable jumbo frames if they are supported by all parts of the chain. It is also compatible with most of the Hyper-V networking features such as RSS, and I highly recommend that you enable it when using ISCSI storage as well.

There are other offloading features, such as Receive-Segment Coalescing (RSC), that reduce the number of IP headers; however, they do not bring any more notable performance benefits to Hyper-V VMs and are therefore not explained further. Moreover, this offloading feature is not supported in Switch Embedded Teaming.

For additional details on these features or other advanced Hyper-V network-related performance tunings, visit the network section of Windows Server Performance Tuning Guidelines found at http://bit.ly/1rNpTkR.

Using IPv6 with Hyper-V

Another common question is about the use of the modern IP protocol, IPv6. It is enabled by default on Windows Server 2016 with Hyper-V, and you better leave it this way. The entire Windows development is done and tested with IPv6 enabled. There can be unforeseen problems occurring after disabling IPv6.

However, if your network standard dictates that you disable IPv6, it can be done on the Hyper-V host as well on the VMs. If you decide to disable IPv6, do it only in the registry. We will add the corresponding registry key via PowerShell:

New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -
    Name "DisabledComponents" -Value 0xffffffff -PropertyType "DWord"

Then, reboot the system. Don't use any other method to disable IPv6, such as unchecking the checkbox in the TCP IP properties of the network card; I've seen problems occurring after that.

I have seen many customers disabling IPv6 via the registry, and some of them had issues with other roles such as Windows Server RRAS. However, I have not seen a single customer experiencing problems with the Hyper-V role with a registry-disabled IPv6. So, you are fine until now with this configuration, but it's still not recommended by Microsoft.

In the earlier chapters, you got an overview of the great storage options possible with Hyper-V. Let's now focus on some additional performance tuning for storage. You have seen how dynamically expanding hard disks are a great option for flexibility, especially in combination with thin provisioning, which is supported by Hyper-V on a software-based and hardware-based level. Hyper-V has some special features for the other way around, then data gets deleted. It is important to let the storage subsystem know that the blocks occupied previously are now ready for reuse. If this did not happen, the physical storage system would consider itself full of data, while on a logical level, it would be half empty. In a worst-case situation, you will be unable to write to a nonfull drive. Windows Server with Hyper-V uses standardized Trim and Unmap functions.

They are enabled by default and don't need any configuration, but you should make sure that your used storage is capable of working with the Trim/Unmap functions to maximize storage efficiency. Only Hyper-V-SCSI, an enlightened IDE, and virtual FC controllers allow the unmap command from the guest to reach the host virtual-storage stack. On the virtual hard disks, only virtual disks formatted as VHDX support unmap commands from the guest. This is another reason to use VHDX files. If you are working with generation 1 VMs, make sure that you use a small IDE-attached system partition and a VHDX file on a SCSI controller for data and applications.

Windows Server with Hyper-V enables a lot of background jobs to consolidate and optimize storage, such as deduplication and defrag jobs. To ensure that these jobs work flawlessly, make sure that you keep at least 10 percent of free space on all drives, including cluster-shared volumes.

Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem `
               -Name "FilterSupportedFeaturesMode" `
               -Value 1

There are some additional options to tune the performance of Hyper-V and its VMs; these options are listed in this section.

Microsoft's Remote Desktop Protocol (RDP) is currently available in Version 8.1 or later and offers great capabilities, including RemoteFX. A little-known fact is that the RDP native client is available for a broad range of platforms, including Windows 7, Windows 8, Windows 8.1, Windows RT, Windows Phone, and also Android and Apple iOS.

RemoteFX offers some great features around RDP connections, and almost all of them can be used without special graphic adapters. RemoteFX is enabled by default and offers features such as multitouch, adaptive graphics, and WAN optimization. The new RDP client also offers features such as automatic network detection and RDP over UDP.

RemoteFX is able to detect content by default and load it by priority. The text is loaded first, then the images are loaded, and at last, the videos and ad banners are loaded onto the screen. With these capabilities, RDP is not only more efficient, but the performance felt by the user is also significantly improved.

RemoteFX features can be configured via Group Policy as follows:

There are some other group policies available, but the default settings for them are, most of the time, just fine.

Another way to speed up RDP performance is by adding a powerful GPU to the server. High-end graphic adapters, formerly known only in gaming PCs and CAD workstations, are now available for VDI clients and RDSH VMs.

RemoteFX has been enhanced in Windows Server 2016. Now RemoteFX supports Gen 2 VM, 4K resolution, OpenGL and OpenCL API and Microsoft has improved performance.

You need to choose a GPO that supports DirectX 11.0 or higher and uses a WDDM 1.2 driver or higher. Make sure that you check the Windows Server Catalog again for RemoteFX GPUs. I have had a good experience with NVIDIA GRID adapters in terms of performance and compatibility. Also, make sure that your Hyper-V host server hardware is capable of running high-end GPUs. The typical server GPU offers only very limited performance and is only using a few of MBs of RAM. RemoteFX GPUs offer great performance and come with gigabytes of graphics RAM. When you want to do more in your VDI VMs or RDSH sessions, then just view the web pages and edit the office files; an RFX GPU might be the right option. It is suitable for running full HD videos or editing CAD models inside a virtual machine. With Hyper-V on Windows Server 2016, you can even share a GPU between numerous virtual machines. To add a GPU to a virtual machine, use the following PowerShell cmdlet:

Add-VMRemoteFx3dVideoAdapter -VMName VM01

To specify the resolution you want to use inside the VM, use the following PowerShell cmdlet:

SET-VMRemoteFx3dVideoAdapter -VMName VM01 -MaximumResolution 1920x1200

When using RemoteFX adapters with VDI VMs, it's best practice to calculate the increased memory usage. A Windows 10 VMs should then be deployed with the possibility to use up to 4 GB of RAM. In a nonRemoteFX vGPU scenario, 2 GB of RAM is enough in most scenarios. VDI clients with Windows 10 work well with dynamic memory and two CPU cores, so this should be the default setup. I often see VDI workloads deployed with differencing disks. This isn't optimal from a performance point of view, and additionally, this is a management nightmare as VMM cannot work with differencing disks. It's a far better option to use dynamic VHDX files and to activate the Windows integrated deduplication, which you learned in Chapter 4, Storage Best Practices.

Other than that, virtual machines that run a VDI workload are just another bunch of Hyper-V VMs.

The first common mistake I see in Hyper-V deployment is the underestimation of the design phase. A lot of projects where I was involved didn't start by studying the existing environment. How can you know the required numbers of CPUs, memory, and storage without inspecting the current infrastructure? If you do not check out the existing environment, your new Hyper-V infrastructure might not match the requirements or could be too large (and so too expensive) with regard to your needs. Before buying hardware, run a Microsoft Assessment and Planning toolkit to calculate the required number of cores, memories, and storage capacity. Once it is calculated, you can add more resources to handle future additional VMs.

For example, currently, you have an infrastructure with 500 VMs which consumes each 2vCPU, 8 GB of RAM and 60 GB of storage. Assume that we want a consolidation rate of 4:1. To calculate the number of the required resources, we can use the following formula:

Now we have the required number to support the current workloads. But what about the future workloads that will come in the next three years? To calculate for future workloads, I assume that the infrastructure will handle 25% more VMs. Let's take the calculator again:

For the compute and memory resources, we need the 320 Cores and the 5 TB of memory in case a node fails in the cluster. For this design, I choose the Intel x2660v4 which has 14 cores. Because each server has two CPUs, each of them has 28 Cores. So I need 348 cores to support one node failure. To calculate the number of servers, you can use this formula:

Now that we have the number of servers, we can calculate how much memory we have to implement in each server:

This formula takes into consideration a node failure. The beginning of the formula calculates the required RAM amount per server. Then this value is added to the total amount of RAM and divided by the number of nodes. Because it is not possible to implement 414 GB of RAM in a real server, the preceding value must be rounded off to 512 GB (16 * 32 GB of RAM). With Intel Xeon v4 family, the number of memory sticks should be a multiple of four (Quad Channel) for best performance.

Therefore, to implement this example, you need 13 servers composed of two Intel Xeon 2660v4 and 16 * 32 GB of RAM.

I have seen some designs where a member of a teaming belonged to the same network adapter. Some network adapters can have two or even four controllers. This means that you can plug as much cable as the controller. However, even if you add all network controllers to the same team, this is not ensuring a high availability in case of a hardware issue. If there is a problem on the network adapter PCB or in the PCI-E bus, all adapters related to this one are disconnected.

This is why, in the production server, I recommend that you buy at least two different network adapters. If you need two 40 GB NICs, buy two single controller network adapters and team them. This statement is true for all network adapters and all HBA to connect to the SAN.

Another mistake I see concerns the NIC Teaming of different network adapters model. I recommend to not do this because of instability with this kind of configuration. Team together only same network adapters (same model and same firmware).

To finish, avoid creating several virtual switches and prefer leveraging network convergence. Let's think about a DMZ and a LAN network. A single virtual switch can easily handle both networks if you configure the physical switch in the trunk mode. On the other hand, if you create several virtual switches, you require several NICs and the management is less flexible.

In some environments, I have seen the network adapters dedicated for iSCSI in a teaming. There is no advantage to using this configuration over MPIO. MPIO handles the network high availability and spreads the iSCSI workloads across all iSCSI NICs. So, don't use NIC Teaming for this usage.

Regarding HBA FC, I have seen some customers who mix Hyper-V storage traffic and NPIV usage. It is not an issue, but I do not recommend mixing the storage traffic and the NPIV on a single HBA to connect LUN to VM.

During the lifecycle of the Hyper-V infrastructure, a lot of people may work on the Hyper-V OS. Sometimes they can have an issue and install a tool in a node of the cluster. Sometimes, because of lack of time, some updates are installed on one node and not on the others. Each node of the cluster not being the same is a mistake.

First, avoid installing a tool to a server. Prefer a portable tool (such as SysInternal) to troubleshoot issues. If you install an agent on a server, this agent should be deployed in each node.

Next, each node in a cluster should be at the same update level. This means that each node must have the same applied updates. By following these best practices, your cluster will be more reliable. This statement doesn't concern only Microsoft updates but also firmware and drivers. Microsoft updates can be managed through WSUS, SCCM, or SCVMM.

To avoid the installation of extra tools and to limit the number of updates to apply, I recommend that you install your Hyper-V nodes in core mode installation. Some software prevents the use of core mode installation. In such cases, you do not have the choice to deploy the nodes in full mode. But, if nothing prevents the core mode installation, prefer this mode. Whatever you choose, do not mix different installation modes in the same cluster.

System Center Virtual Machine Manager (SCVMM) is not another hypervisor besides Hyper-V. VMM simply adds a management functionality to virtualization hosts. It works best with Hyper-V, but is also capable of managing day-to-day operational tasks for VMware vSphere through vCenter and Citrix XenServer hosts.

You can create your own virtual machine templates with VMM for fast deployment of new virtual machines with basic content and configuration. VMM takes the approach of predefined templates to a new level, by service templates. A service template not only consists of a virtual machine and a preinstalled operating system, but also offers much more, starting from the integration of software components such as databases and applications over storage to load-balanced network connections. All you need to do is define a central service template that offers dynamic expanding or shrinking of the VM environment, purely based on current performance requirements. Applications consisting of database servers, application servers, and frontend servers are ideal candidates for service templates.

There are several service templates available for download at TechNet Gallery (http://bit.ly/VYK8jh), one is shown in the following screenshot:

The VMM service template

SCVMM also provides full management of Fabric. Thanks to SCVMM, you can manage the Hyper-V configuration from a single pane (network, storage, Hyper-V role, and so on), manage the storage, either with a SAN (with SMI-S) or with Storage Spaces, create Hyper-V and Storage cluster, make a bare-metal provisioning of Hyper-V and storage node, and so on. SCVMM is not just a new GUI on top of the Failover Clustering manager, but a tool to manage all your Hyper-V infrastructure environment.

SCVMM can be deployed in high availability in a classical Failover Cluster. To install SCVMM in this way, you need to install and configure the Failover Clustering feature on both servers without a shared disk (except for quorum witness). Then install SCVMM, and while using the wizard, you will be asked to deploy the tool in high availability.

When you run SCVMM for the first time, I recommend that you disable the Create logical networks automatically option to avoid the creation of the object related to the virtual switches that you have deployed in the Hyper-V nodes. You can find this option in Settings | General | Network settings.

Then you should create a host group to sort the Hyper-V nodes. When I deploy SCVMM, I always try to create a first host group level, which represents the location (Lyon, Paris, New York, and so on) and a second level, which represents the Hyper-V nodes usage (hosting, NVGRE Gateway, fabric servers, and so on). It is not necessary to create a lot of levels as it will complicate the management of SCVMM. Creating host groups allow delegated and granular management.

Next, you should configure the networking in Fabric. If you fully manage the network in SCVMM, this can help you to provision Hyper-V, storage nodes, and VMs. The SCVMM network functionality contains a great feature called the IP Address Pool (IP Pool). The IP Pool enables you to create a pool of IP addresses that can be used when you deploy Hyper-V or storage nodes and VMs.

The IP address is assigned statically in the virtual network adapter and a reservation is applied on this IP address:

Network configuration in SCVMM

Moreover, you can configure Switch Embedded Teaming and virtual network adapter from SCVMM. When the network is configured, you are able to configure the Hyper-V nodes network adapters from SCVMM.

Once the network is configured, you can connect your storage system to SCVMM to create LUN and SMB share and have of about free spaces. Then the CSV can be sorted in storage classifications. These classifications enable you to provision a VM in a storage location belonging to the chosen storage classification. It eases the automation of VM deployment:

Storage management from SCVMM

SCVMM is also able to be connected to a WSUS Server (it can be the same as SCCM while WSUS is configured by SCCM). If you connect a WSUS server, you can create an update baseline and associate it to a host group and/or fabric servers. The compliance is checked and if the server is not compliant, you can remediate from SCVMM. The remediation will install the update on the server.

Then you should install a file server that will be used as a VMM library. DFS is not supported in the VMM library, but you can leverage a file server in a cluster failover. This file server will contain an ISO file, unattended xml file, or sysprep'd VHDX. This configuration is described at http://bit.ly/1uhyrzD. For example, I often deploy VM using the following unattended XML file:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-International-Core"
        processorArchitecture="x86"
        publicKeyToken="31bf3856ad364e35" language="neutral"
        versionScope="nonSxS"
        xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <InputLocale>fr-FR;en-US</InputLocale>
            <UserLocale>en-US</UserLocale>
            <UILanguageFallback>en-US</UILanguageFallback>
            <SystemLocale>en-US</SystemLocale>
            <UILanguage>en-US</UILanguage>
        </component>
    </settings>
    <settings pass="generalize">
        <component name="Microsoft-Windows-PnpSysprep"
        processorArchitecture="amd64"
        publicKeyToken="31bf3856ad364e35" language="neutral"
        versionScope="nonSxS"
        xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
           <PersistAllDeviceInstalls>true
           </PersistAllDeviceInstalls>
        </component>
    </settings>
</unattend>

This answer file configures the keyboard layout of the virtual machine and does not check new hardware at VM deployment.

You can also connect Windows Deployment Services (WDS) which will be used to provision Hyper-V and/or storage node. Then the physical computer profiles will be leveraged. To provision a node from SCVMM you have to do the following:

You can also add a post install PowerShell script in the physical computer profile. When I am involved in a Hyper-V project, I spend a lot of time on configuring this profile and scripts to provision Hyper-V automatically. PowerShell scripts are often the driver installation, the agent deployment (SCCM, SCOM, backup, and so on), and some custom configurations. For further information about provisioning Hyper-V with this method, refer to http://bit.ly/2beBdI9.

SCVMM also offers the capability to create Hyper-V cluster and Storage Spaces configuration. For further information, refer to http://bit.ly/2bmeG8k.

Once these configurations have been made, you can install the SCVMM agent in each Hyper-V node that you have already deployed to manage them from SCVMM.

If you plan to manage your Hyper-V infrastructure from SCVMM, I highly recommend that you configure just two Hyper-V nodes and deploy all the basic VMs to run SCVMM (Domain Controller, SQL Server, and VMM). Once the configuration of SCVMM is finished, you will have to migrate the network of the Hyper-V nodes and VMs from standalone managed (standard switches) to SCVMM managed (logical switches). This migration involves some network outage.

A new feature of SCVMM 2016 is the capability to upgrade a Windows Server 2012 R2 cluster to Windows Server 2016 by leveraging the Rolling Cluster Upgrade (we will discuss this feature in Chapter 9, Migration to Hyper-V 2016). This feature leverages the bare-metal provisioning feature to upgrade a cluster in Windows Server 2012 R2 to Windows Server 2016 without recreating a new cluster for the migration.

I wrote a white paper a long time ago about the Implement a highly available Private Cloud to host Virtual Machines. This is a step-by-step guide which also explains the configuration of SCVMM. You can download it at http://bit.ly/2bmfs5c.

To learn more about VMM, refer to System Center 2012 R2 Virtual Machine Manager Cookbook, by Edvaldo Alessandro Cardoso, published by Packt Publishing, at http://bit.ly/1vBjf4i.

System Center Operations Manager (SCOM) is an end-to-end monitoring tool offering a great transparency to your infrastructure. While many monitoring solutions are available in the market, there are none as sophisticated as SCOM. While other solutions monitor a given set of up to 30 parameters per host, such as checking for free space on drives, pinging systems, and checking whether a specific Windows service is running, SCOM offers far more value.

With hundreds and thousands of preconfigured rulesets monitoring your environment, delivered in management packs, OM not only detects the exact location and source of the problem but also delivers great guidance on how to work around an incident or apply a permanent solution without the need to leave the SCOM console.

These management packs are free to download for all Microsoft products and are ready to use. You don't need to put more time into configuration than into other monitoring solutions that do not offer this granularity. This great concept of an SCOM allows you to avoid many problems before there is an impact on production systems, such as receiving notifications via an instant messenger or e-mail, or creating automatic recovery tasks in the event of an error.

You can receive all relevant performance information about your systems, including Hyper-V hosts and VMs. You can also monitor the network devices and switches connected to your Hyper-V environment as well as the application-level performance of web applications such as the self-service portal. With SCOM, you can forward the collected information to your trouble-stricken system, that is, System Center Service Manager, and close the ticket when the problem gets resolved. With this great level of detail, SCOM is even capable of calculating future performance requirements based on your usage in the past.

For advanced scenarios, Microsoft's partner Veeam offers a commercial Hyper-V management pack allowing you to go even further into the Hyper-V stack from a monitoring perspective. The SCOM screen looks as follows:

System center operations manager

Here are the main steps to get SCOM up and running:

Microsoft's Service Manager (SM) is often described as the Microsoft version of a helpdesk tool. However, SCSM offers a lot more than that and is a fully capable IT service management tool. With SCSM, you can document incidents and problems, plan the next software release, and start document planned changes. An SCSM is the most central component where all the data comes together. Through integrated connectors, the collected data from all other System Center components are centralized in a complete Configuration Management Database (CMDB) that allows you to pull more value out of this data. Its SharePoint-based self-service portal allows for end user communication and a web-based creation of incidents and service requests. An SCSM comes with a set of built-in best practice processes for core ITIL components. ITIL and MOF are a set of best practice descriptions on IT service management processes.

By orchestrating this knowledge across the various System Center components, an SCSM helps IT staff to continuously adapt to new requirements while lowering costs and reducing time to resolution. This is the reason why an SCSM is a great tool for aligning your IT to your business needs. You can use Service-Level Agreements to proof this value with SCSM functionalities.

You can also leverage the great data resource pool to create transparent reporting for optimization, or use a chargeback or showback-based reporting for virtual machine resources. The following screenshot shows the SCSM screen:

System center service manager

You can use SLA dashboards with SCSM to demonstrate the great performance of IT on the company's Intranet portal or use huge Excel spreadsheets for optimization.

SCSM offers even further value through various partner extensions from companies such as Cireson, Opslogix, and Provance, including full asset management solutions.

The main steps to get your SCSM (installation described at http://bit.ly/1qhhQg6) up and running are as follows:

For additional information on SCSM, visit the book at http://bit.ly/1owrQwD.

Many existing solutions come with integrated workflow solutions. Think of Microsoft Exchange Server automatically sending an out of office notification or of Microsoft SQL Server executing maintenance plans. All these workflow solutions are contained in the product they are part of.

System Center Orchestrator (SCOR) is a great addition to Hyper-V and SCSM. Orchestrator provides a workflow management solution for the datacenter. Orchestrator lets you automate the creation, monitoring, and deployment of resources in your environment through workflows known as runbooks. With System SCOR, it is, for instance, possible to span runbooks originating from SCSM to Hyper-V involving, for instance, Microsoft Azure, Microsoft Exchange, and Oracle databases. This greatly simplifies performing daily operations because now you can automate every reoccurring technical process.

Starting with user creation in different systems over VM deployment with automatic backup and restore, up to a fully scripted disaster recovery failover solution, SCOR is capable of building and executing these workflows as follows:

System center orchestrator

Many best practice runbooks around Hyper-V are already built, involving great solutions for automated Hyper-V Replica failover or the creation of machines on Hyper-V with several dependencies. If you have done anything twice in IT, SCOR is the right component to use.

The main steps to get your SCOR installation (described at http://bit.ly/1nh9yQv) up and running are as follows:

For additional information on orchestrator, you can refer to Microsoft System Center 2012 Orchestrator Cookbook, by Samuel Erskine (MCT), published by Packt Publishing, at http://bit.ly/1B8tMUY.

Microsoft's DPM is the bigger version of Windows Server backup (wbadmin) and is itself a complete backup and recovery solution. You can back up Hyper-V clusters on the host level without the need to install backup agents on every virtual machine. You can take consistent backups of running Hyper-V VMs or powered-off virtual machines replicated through Hyper-V Replica. To support the backup of deduplicated volumes, SCDPM is a great backup tool for saving space. SCDPM is also capable of protecting Hyper-V VMs by backing up the replica and not the primary VM. For host-level backups, an SCDPM agent is installed on the Hyper-V host and will protect the entire VM running on that Hyper-V host. For guest-level backup, an SCDPM agent is installed within the VM operating system and is used to protect the workload present within that VM.

SCDPM does not create backups on a classic multirotation principle with frequently occurring full backups. SCDPM uses a more modern approach, creating a single full backup, followed by incremental forever backups every 15 minutes. This removes the classic load-heavy backup window in the middle of the night leading to hours of data loss in a restore. Having recovery available points every 15 minutes offers great point-in-time recovery options, while it's only backing up changed blocks, without the need to rebackup and save the same data over and over again.

It is possible to replicate created backups to another SCDPM server, to a tape device, or to Microsoft Azure. This replaces the need for manual tape rotation and secured offsite transport. The data is stored and transmitted with full encryption.

SCDPM can back up and restore all typical Microsoft workloads in the physical and virtual world, such as Windows Server with Hyper-V:

Remember that Linux VMs running on Hyper-V are also supported Microsoft workloads. In fact, it's easier to run a consistent backup of a Linux system running on Hyper-V than on a physical level. Microsoft has included a Volume Shadow Copy Service (VSS) for the Linux driver in the Hyper-V integration components for leveraging this capability. SCDPM can protect your Hyper-V environment using SMB shares as well, but this requires the installation of the SCDPM agent on all servers using the SMB remote storage.

SCDPM is supported to perform an Item-Level Recovery (ILR) of a VM, even if the SCDPM server itself is running as a VM. SCDPM is able to perform an ILR by indexing the VHDs/VHDXs associated with the VM. The SCDPM screen is shown here:

System center data protection manager

After the installation of SCDPM (described at http://bit.ly/1sTugJj), follow these steps for a basic configuration:

For additional information on SCDPM, you can refer to the book at http://bit.ly/1rHWKKd.

There are other System Center components available, such as Configuration Manager and Endpoint Protection. These tools are mostly client-focused and will not be covered in this book; however, they can be utilized for server management as well. Keep in mind that System Center is available for a 180-day trial period, so try it out today.

Installing System Center with its various components is a complex and time-consuming task. Microsoft's Rob Willis created the PowerShell Deployment Toolkit (PDT), which allows the unattended installation of all System Center components within 2 hours instead of spending days manually installing everything. The following are the features of PDT:

PDT is a great way to create a lab environment quickly for evaluation, but even production setups can be installed through PDT. PDT utilizes XML files for configuration. The required customization of these XML files can be a tricky job. To simplify this process, I have created the PDT GUI together with my coworker, Kamil Kosek.

PDT GUI offers a user interface to edit the XML files necessary for PDT and adds some management improvements for the various PDT components.

PDT and PDT GUI can be downloaded from http://aka.ms/PDTGUI and are available for free.

As presented in Chapter 3, Backup and Disaster Recovery, Azure Site Recovery (ASR) is a solution which enables you to protect your VMs in Microsoft Azure. ASR is also able to protect VMs between two on-premises datacenters by orchestrating the restart of VMs when the failover occurs. The protection in Microsoft Azure is more cost effective, therefore, the focus will be on this solution.

ASR can be part of a business continuity and disaster recovery strategy. ASR can be used either through SCVMM or not, and it is also able to protect physical servers. ASR enables you to replicate the VMs or the physical servers to Microsoft Azure to restart them in Microsoft Azure in the case of disaster:

Infrastructure preparation in azure site recovery

The restart of the servers is orchestrated by a recovery plan configured via the Azure Portal. The recovery plan can include a manual task, Microsoft Automation workflow, and a start task. These tasks are sorted in groups to choose the order of execution.

A big advantage of ASR is the opportunity to run a test of failover. In this way, you are able to try your failover in case of disaster and start the VM in azure in a sandbox. When you run a test of failover, the workloads located in the on-premises datacenter are still running.

When you configure ASR, you can map an on-premises network with a Microsoft Azure network. In this way, when a VM failovers to Microsoft Azure, the network is already set.

If you want to implement ASR, be careful about the link between Microsoft Azure and your datacenter. ASR supports site-to-site VPN and ExpressRoute. When you have a large number of workloads to replicate, I recommend that you look for ExpressRoute (for further information, check http://bit.ly/1OdQylf).

To use ASR to replicate workloads in Microsoft Azure, you have to follow these main steps:

Similar to ASR, Azure Backup is a component of Microsoft Azure Recovery Services. This feature enables you to back up a physical server or VMs both on-premises and in Microsoft Azure. Instead of storing your long-term backup in tapes, you can leverage Microsoft Azure. To deploy Azure Backup, you have the following three options:

The first option enables you to back up a Windows Server 2008 R2 at least by installing a simple agent. This back up solution can back up files and folders.

You can also leverage SCDPM to store your long-term back up in Microsoft Azure. You just have to install the Azure Backup agent and register the Azure subscription in the SCDPM console. Then, when you configure a protection, you can choose to back up to Microsoft Azure (online protection).

The third solution involves Azure Backup Server. This tool is equivalent to SCDPM except that you can't back up on a tape:

Configure online protection

Either with SCDPM or Azure Backup Server, you can back up Exchange, SharePoint, Windows Server, SQL Server database, and Microsoft Dynamics.

Log Analytics is a tool that can collect, combine, and correlate data. Then the data can be arranged in a chart for a global overview of your infrastructure. Log Analytics provides a log engine to search information and to create complex requests.

Some solution packs are available through a gallery. A solution pack is a set of rules, visualization, and logic, which provide metrics about a service (such as SQL Server, capacity planning, security, and so on).

Log Analytics can gather information from an agent installed on the servers (either through a gateway or not). Log Analytics can also be connected to SCOM, which will act as a gateway. When you use SCOM, you don't need a further agent-the SCOM agent will be leveraged.

When the servers are connected, data is sent to the Log Analytics workspace to handle it. Then the solution packs deal with data with the log engine to show you information.

For Hyper-V usage, there is a great solution pack called capacity planning. If you have SCVMM and SCOM connected, you can send data to get information about capacity planning:

Capacity planning in log analytics

As you can see in the preceding screenshot, Log Analytics gives you information about resource utilization and makes a projection. It is a great tool to have a readable capacity planning.

Log Analytics is also available on mobile devices such as Apple iOS, Google Android, or Windows Mobile. Thanks to the application, you can have the dashboard on your mobile phone.

When you manage a lot of servers and services, you certainly use PowerShell and/or System Center Orchestrator to automate some tasks. The automation of tasks avoids repeated actions, reduces human errors, and increases the reliability of your IT. Azure Automation enables you to automate tasks in the Cloud or in an on-premises datacenter. Similar to Orchestrator, Azure Automation is based on runbook which can be edited graphically or with the PowerShell command line.

Microsoft has recently added a gallery where you can download runbooks written by the community. For example, you can download runbook to start or stop virtual machines, create a VM, and so on:

A graphical runbook in azure automation

You can use Azure Automation with ASR to automate some tasks when a failover occurs between your datacenter and Microsoft Azure. For example, you may want to run a diagnostic test during the failover to verify that the service is online before starting other virtual machines.

If you choose to do a clean installation, you do not necessarily have to export the virtual machines first; just make sure all VMs are powered off and are stored on a different partition from your Hyper-V host OS. If you are using a SAN, disconnect all LUNs before the installation and reconnect them afterwards to ensure their integrity through the installation process. To install the new operating system on the host, just follow the procedures described in Chapter 1, Accelerating Hyper-V Deployment. After completing the procedure, just reconnect the LUNs and set the disk online via diskpart or in Disk Management at Control Panel | Computer Management.

If you are using local disks, make sure not to reformat the partition with your virtual machines on it. You should export VM to another location and import them back after reformatting; more efforts are required but it is safer. Set the partition online and then reimport the virtual machines. Before you start the reimport process, make sure all dependencies of your virtual machines are available, especially vSwitches.

To import a single Hyper-V VM, use the following PowerShell cmdlet:

    Import-VM -Path 'D:\VMs\VM01\Virtual Machines\2D5EECDA-8ECC-4FFC-ACEE-

    66DAB72C8754.xml'

To import all virtual machines from a specific folder, use this command:

    Get-ChildItem d:\VMs -Recurse -Filter "Virtual Machines" | %{Get-ChildItem

    $_.FullName -Filter *.xml} | %{import-vm $_.FullName -Register}

After that, all VMs are registered and ready for use on your new Hyper-V hosts. Make sure to update the Hyper-V integration services of all virtual machines before going back into production. If you still have virtual disks in the old .vhd format, it's now time to convert them to .vhdx files. Use this PowerShell cmdlet on powered-off VMs or standalone vDisks to convert a single .vhd file:

Convert-VHD -Path d:\VMs\testvhd.vhd -DestinationPath d:\VMs\testvhdx.vhdx

If you want to convert the disks of all your VMs, fellow MVPs, Aidan Finn and Didier van Hoye, have provided a great end-to-end solution to achieve this. This can be found at http://bit.ly/1omOagi.

If you want to use another physical system running a newer version of Hyper-V, you have multiple possible options. They are as follows:

Export-VM -Name VM -Path D:\

Get-VM | Export-VM -Path D:\

One of the great improvements in Windows Server 2012 R2 is the ability to move the running virtual machines between hosts that run a different version of Hyper-V in a defined environment. Cross-version live migration simplifies the migration process from Windows Server 2012 to Windows Server 2012 R2 for Hyper-V hosts. In the same way, you can use Shared-nothing live migration to move a VM and its storage to another standalone Hyper-V host. While the VM is running, you can now execute a Shared-nothing live migration cross-version. This only works from Windows Server 2012 to its successor Windows Server 2012 R2/2016 and not in any other combination. It also works on clusters. While moving all the storage of the VMs takes a long time, this is the recommended migration option if you want to reduce downtime; there is none, at least at the migration process. You still need to reboot the virtual machines after upgrading the integration services of the guest VMs.

If you are using SMB3 fileshares as storage for your virtual machines, you don't even need to transfer the virtual disks with it, and a cross-version live migration does not take longer than a live migration between the cluster nodes.

Make sure that the source and destination Hyper-V hosts are in the same Active Directory domain or in a trusted domain. This can even be hosted in a different forest. In the case of remote domains, make sure the name resolution is working both ways. Configure vSwitches on the destination hosts to map the source hosts' networks; only then can a successful live migration occur.

Cross-version live migration works the same way as the Shared-nothing live migration you already learned. You can trigger it via PowerShell, Hyper-V Manager, Failover Cluster Manager, or System Center Virtual Machine Manager.

You have already seen the System Center VMM in earlier chapters for fabric and cloud management. SCVMM can also be used for a limited set of Virtual to Virtual (V2V) conversions of its VMs. SCVMM V2V functions don't have any recent updates and are prone to errors. SCVMM should not be the first tool of your choice, take a look at MVMC combined with MAT to get equal functionality from a better working tool.

The earlier versions of SCVMM allowed online or offline conversions of VMs; the current version, 2016, allows only offline conversions of VMs. Select a powered-off VM on a VMware host or from the SCVMM library share to start the conversion. The VM conversion will convert VMware-hosted virtual machines through vCenter and ensure that the entire configuration, such as memory, virtual processor, and other machine configurations, is also migrated from the initial source. The tool also adds virtual NICs to the deployed virtual machine on Hyper-V.

The VMware tools must be uninstalled before the conversion because you won't be able to remove the VMware tools when the VM is not running on a VMware host. SCVMM 2016 supports ESXi hosts running 4.1 and 5.1 but not the latest ESX Version 5.5. SCVMM conversions are great to automate through their integrated PowerShell support and it's very easy to install upgraded Hyper-V integration services as part of the setup or by adding any kind of automation through PowerShell or System Center Orchestrator. Besides manually removing VMware tools, using SCVMM is an end-to-end solution in the migration process. You can find some PowerShell examples for SCVMM-powered V2V conversion scripts at http://bit.ly/Y4bGp8.

I no longer recommend the use of this tool because Microsoft now spends no time on it.

Microsoft released its first version of the free solution accelerator Microsoft Virtual Machine Converter (MVMC) in 2013, and it should be available in Version 3.1 by the release of this book. MVMC provides a small and easy option to migrate selected virtual machines to Hyper-V. It takes a very similar approach to the conversion as SCVMM does. The conversion happens at a host level and offers a fully integrated end-to-end solution. MVMC supports all recent versions of VMware vSphere. It will even uninstall the VMware tools and install the Hyper-V integration services. MVMC 2.0 works with all supported Hyper-V guest operating systems, including Linux.

MVMC comes with a full GUI wizard as well as a fully scriptable command-line interface (CLI). Besides being a free tool, it is fully supported by Microsoft in the event you experience any problems during the migration process. MVMC should be the first tool of your choice if you do not know which tool to use. Like most other conversion tools, it does the actual conversion on the MVMC server itself and requires its disk space to host the original VMware virtual disk as well as the converted Hyper-V disk. MVMC even offers an add-on for VMware virtual center servers to start conversions directly from the vSphere console.

The current release of MV is freely available at its official download site at http://bit.ly/1HbRIg7.

Download MVMC to the conversion system and start the click-through setup. After finishing the download, start the MVMC with the GUI by executing Mvmc.Gui.exe. The wizard guides you through some choices.

MVMC is not only capable of migrating to Hyper-V but also allows you to move virtual machines to Microsoft Azure. Follow these few steps to convert a VMware VM:

There is some additional guidance available at http://bit.ly/1vBqj0U.

This is a great and easy way to migrate a single virtual machine. Repeat the steps for every other virtual machine you have, or use some automation.

If you have a number of virtual machines to convert, the Microsoft Automation Toolkit (MAT) is a great choice. It adds a layer of automation above MVMC and can be downloaded from http://bit.ly/XyLgeG.

MAT is a collection of PowerShell scripts that automate conversions using the MVMC. It's backended by the current versions of a SQL Server (SQL Express will work). You can use it to convert several machines at once on a single server or across many servers. The automation options of MAT can be extended to a fully customized end-to-end solution. However, even in a fully automated environment, the conversion will take a lot of time. All virtual disks must be converted in a V2V conversion by all common tools. This takes time on a single virtual disk and a lot of time on multiple virtual disks. The time directly correlates to the size of the virtual disks as well.

Some additional guidance on MAT can be found at http://bit.ly/1B8tSf5.

There is one solution available to speed up the conversion process, which we will discuss in the next section.

If you think of MAT as an add-on for MVMC, then MAT powered by Project Shift is another add-on on top of that. Project Shift enables hardware-accelerated conversions of virtual disks. It converts virtual disks located on a NetApp storage controller between formats at amazing speeds. It can convert between several formats, but the most interesting is the VMDK to VHD conversion. For example, I was able to convert a 40 GB VMDK to a VHDX using the following PowerShell cmdlet:

ConvertTo-NaVhd

This conversion took about 6 seconds. As of today, this only works on the NetApp storage controller because the NetApp controller simply repoints the data from the VMDK into a Hyper-V VHD, writing the appropriate metadata as it progresses. The resulting file is a VHD or VHDX file that takes up practically no extra space on disk and is finished in seconds. While NetApp Shift is available on a NetApp filer, it does not allow for whole VM conversions. This is why Microsoft combined it with MAT to build-again-an end-to-end conversion experience.

MAT powered by Project Shift scales extremely well and is the first choice of tool for a migration for hundreds of virtual machines. It is so successful that I have seen customers running other storage systems borrowing the NetApp filer to leverage these hardware-assisted conversions. Some additional guidance can be found at http://bit.ly/1tRiMcc.

There are a bunch of other tools available in the market for V2V conversions. The 5nine V2V easy converter and the StarWind V2V converter offer a very similar experience to that of the MVMC + MAT solution accelerators but can add particular value needed in advanced migration scenarios.

There is one tool in particular that can add real value to the shown conversion scenarios. The Double-take Move by Vision Solution offers a lot more out-of-the-box automation options, such as integration with System Center Orchestrator and Service Manager, and it comes with superior capabilities, such as replicating running VMware VMs to Hyper-V. However, it comes with a price—literally. It is not free and requires a license per migrated virtual machine. Use Double-take Move if money is not your most valuable resource and you are looking for a fully automated conversion experience.

All mentioned tools are focused on moving from VMware to Hyper-V. What if you have virtual machines running on Citrix XenServer?

Citrix offers a free tool called XenConvert, which is available at http://bit.ly/WXrnhd, and it allows for the conversion of XenServer VMs into the OVF format. The OVF format is just a container format hosting the XenServer VM configuration and its virtual hard drive in a VHD format. This conversion can be done with the following steps:

Some additional guidance can be found at http://marcusdaniels.net/quick-and-easy-xenserver-to-hyper-v-conversion/.

If you have virtual machines running on any other Hypervisor than vSphere or Citrix, treat the VM the same way you would treat physical server systems.