Hyper-V Best Practices - Replica, Cluster, Backup Advice

Hyper-V has proven to be a very cost effective solution for server consolidation. Evidence of this is also the fact that companies are beginning to move from VMware to the Hyper-V virtualization platform. This article will cover the Windows 2012 Hyper-V best practices, and aims to help you run your Hyper-V virtualization environment as optimum as possible.

Keeping your Hyper-V virtualization infrastructure running as smoothly as possible can be a daunting task, which is why we recommend engineers follow the best Hyper-V practices.

Different organizations have different setups and requirements: some of you might be moving from VMware to Hyper-V virtualization, while others might be upgrading from an older Hyper-V virtualization server to a newer one. Each scenario must follow the baseline or best practices,  to be able to run the virtualization infrastructure successfully – without problems.

Hyper-V Best Practice List

Best practices for Hyper-V vary considerably depending on whether you're using clustered servers. As a general rule-of-thumb the best thing you can do is try to configure your host server and your Virtual Machines in a way that avoids resource contention to the greatest extent possible.

Organizations who are considering migrating their infrastructure to Hyper-V, or are currently running on the Hyper-V virtualization platform, need to take note of the below important points that must not be overlooked:

Processor

Memory

Minimum: 512 MB.  This is the bare minimum; however a logical approach would be at least 4 Gigs of RAM per virtual server.  If one physical server is to host 4 Virtual Machines, then we would recommend at least 16GBs of Physical RAM, if not more.  SQL servers and other RAM intensive services would certainly lift the memory requirements a lot higher. You can never have enough memory.

Network Adapters

At least one network adapter is required, but two or more are always recommended. Hyper-V allows the creation of three different virtual switches: Internal Virtual Switches, Private Virtual Switches and External Virtual Switches.

Internal virtual switches are used to allow the virtual machine to connect with its host machine (the physical machine that run’s Hyper-V). Private virtual switches are used when we only want to connect virtual machines, which run on the same host, between each other.  External virtual switches are used to allow the virtual machine to connect with our LAN network and this is where physical network adapters come in hand.   
Host machines with only one network adapter will be forced to share that network adapter with all its virtual machines. This is why it’s always best practice to have at least two network adapters available. 

Additional Considerations

The settings for hardware-assisted virtualization and hardware-enforced DEP are usually available from within in the system’s BIOS; however, the names of the settings may differ from the names identified previously.
For more information about whether a specific processor model supports Hyper-V (virtualization), it is recommended to check at the manufacturer’s website.

As noted before, it is important to remember after modifying the settings for hardware-assisted virtualization or hardware-enforced DEP, you may need to turn off the power to the server and then turn it back on to ensure the new CPU settings are loaded.

Microsoft Assessment & Planning Toolkit

Microsoft Assessment and Planning Toolkit (MAP) can be used to study existing infrastructure and determine the Hyper-V requirement. For organizations who are interested in server consolidation and virtualization through technologies such as Hyper-V, MAP helps gather performance metrics and generate server consolidation recommendations that identify the candidates for server virtualization and will even suggest how the physical servers might be placed in a virtualized environment.

The diagram below shows the MAP phases involved to successfully create the necessary reports:

Figure 1. MAP Phases

Below is an overview of the Microsoft Assessment and Planning Toolkit application:

Figure 2. MAP Overview

The following points are the best practices which should be considered before deploying your Windows Server 2012 Hyper-V infrastructure:

Hyper-V Hosts (Physical Servers)

• Ensure hosts are up-to-date with recommended Microsoft updates
• Ensure hosts have the latest BIOS version, as well as other hardware devices (such as Synthetic Fiber Channel, NIC’s, Raid bios, etc.)
• Hosts must be part of a domain before you can create a Hyper-V High-Availability Cluster.
• RDP Printer Mapping should be disabled on hosts, to remove any chance of a printer driver causing instability issues on the host machine. To do this, follow the below steps: Computer Configuration –> Policies –> Administrative Templates –> Windows Components –> Remote Desktop Services –> Remote Desktop Session Host –> Printer Redirection –> Do not allow client printer redirection –> Set to "Enabled”
• Do not install any other Roles on a host besides the Hyper-V role and the Remote Desktop Services roles. Optionally, if the host will become part of a cluster, you can install Failover Cluster Manager. In the event the host connects to an iSCSI SAN and/or Fiber Channel, you can also install Multipath I/O.
• Anti-virus software should exclude Hyper-V specific files using the Hyper-V: Antivirus Exclusions for Hyper-V Hosts article available from Microsoft.
• Default path for Virtual Hard Disks (VHD/VHDX) should be set to a non-system drive, due to this can cause disk latency as well as create the potential for the host running out of disk space.
• If you are using iSCSI: In Windows Firewall with Advanced Security, enable iSCSI Service (TCP-In) for Inbound and iSCSI Service (TCP-Out) for outbound in Firewall settings on each host. This will ensure iSCSI traffic is allowed to pass from host to the SAN device and back. Not enabling these rules will prevent iSCSI communication. To set the iSCSI firewall rules via netsh, you can use the following command:

PS C:\Windows\system32> Netsh advfirewall firewall set rule group=”iSCSI Service” new enable=yes

• Periodically run performance counters against the host, to ensure optimal performance. Recommend using the Hyper-V performance counter that can be extracted from the (free) Codeplex PAL application.

Hyper-V Virtual Machines

• Ensure you are running only supported guests in your environment.
• Ensure you are using sophisticated backup software such as Altaro’s Hyper-V Backup which also includes free lifetime backup for a specific amount of VMs
• If you are converting VMware virtual machines to Hyper-V, consider using MVMC (a free, stand-alone tool offered by Microsoft) or VMM.
• Disk2vhd is a Tool which can be used to convert a Physical Machine to a Hyper-V Virtual Machine (P2V). The VHD file created can then be imported in to Hyper-V.

Hyper-V Physical NICs

• Ensure Network Adapters have the latest firmware and drivers, which often address known issues with hardware and performance.
• TCP Chimney Offload is not supported with Server 2012 software-based NIC teaming, because TCP Chimney has the entire networking stack offloaded to the NIC. If however software-based NIC teaming is not used, you can leave TCP Chimney Offload enabled. To disable TCP Chimney Offload, from an elevated command-prompt, type the following command:

PS C:\Windows\system32> netsh int tcp set global chimney=disabled

• Jumbo frames should be turned on and set for 9000 or 9014 (depending on your hardware) for CSV, iSCSI and Live Migration networks. To verify Jumbo frames have been successfully configured, run the following command from all your Hyper-V host(s) to your iSCSI SAN:

PS C:\Windows\system32> ping 10.50.2.35 –f –l 8000

This command will ping the SAN (e.g. 10.50.2.35) with an 8K packet from the host. If replies are received, Jumbo frames are properly configured. Note that in the case a network switch exists between the host and iSCSI SAN, Jumbo frames must be enabled on that as well.

 Figure 3. Jumbo Frame Ping Test

• Management NIC should be at the top (1st) in NIC Binding Order. To set the NIC binding order: Control Panel --> Network and Internet --> Network Connections. Next, select the advanced menu item, and select Advanced Settings. In the Advanced Settings window, select your management network under Connections and use the arrows on the right to move it to the top of the list.
• If using NIC teaming inside a guest VM, follow this order: Open the settings of the Virtual Machine, Under Network Adapter, select Advanced Features, in the right pane, under Network Teaming, tick the “Enable this network adapter to be part of a team in the guest operating system”. Once inside the VM, open Server Manager. In the All Servers view, enable NIC Teaming from Server:

Figure 4. Enable NIC Teaming

Hyper-V Disks

• New disks should use the VHDX format. Disks created in earlier Hyper-V iterations should be converted to VHDX, unless there is a need to move the VHD back to a 2008 Hyper-V host.
• Disk used for CSV must be partitioned with NTFS. You cannot use a disk for a CSV that is formatted with FAT, FAT32, or Resilient File System (ReFS).
• Disks should be fixed in a production environment, to increase disk throughput. Differencing and Dynamic disks are not recommended for production, due to increased disk read/write latency times (differencing/dynamic disks).
• Shared Virtual Hard Disk: Do not use a shared VHDx file for the operating system disk. Servers should have a unique VHDx (for the OS) that only they can access. Shared Virtual Hard Disks are better used as data disks and for the disk witness.
• Use caution when using snapshots. If not properly managed, snapshots can cause disk space issues, as well as additional physical I/O overhead.
• Page file on Hyper-V Host should manage by the OS and not configured manually.
• It is not supported to create a storage pool using Fiber Channel or iSCSI LUNs.

Hyper-V Memory

• Use Dynamic Memory on all VMs (unless not supported).
• Guest OS should be configured with (minimum) recommended memory

Hyper-V Clusters

• Set preferred network for CSV communication, to ensure the correct network is used for this traffic. The lowest metric in the output generated by the PowerShell command below, will be used for CSV traffic. First, open a PowerShell command-prompt (using “Run as administrator”) Secondly, you’ll need to import the “FailoverClusters” module. Type the following at the PowerShell command-prompt:

PS C:\Windows\system32> Import-Module FailoverClusters

Next, we’ll request a listing of networks used by the host, as well as the metric assigned. This can be done by typing the following:

PS C:\Windows\system32> Get-ClusterNetwork | ft Name, Metric, AutoMetric, Role

In order to change which network interface is used for CSV traffic, use the following PowerShell command:

PS C:\Windows\system32> (Get-ClusterNetwork "CSV Network").Metric=900

This will set the network named "CSV Network" to 900

Figure 5. Get Cluster Network

• Set preferred network for Live Migration, to ensure the correct network(s) are used for this traffic following these steps: Open Failover Cluster Manager, Expand the Cluster , Next, right-click on Networks and select Live Migration Settings , Use the Up/Down buttons to list the networks in order from most preferred (at the top) to least preferred (at the bottom) , Uncheck any networks you do not want used for Live Migration traffic , Select Apply and then press OK , Once you have made this change, it will be used for all VMs in the cluster
• The Host Shutdown Time (ShutdownTimeoutInMinutes registry entry) can be increased from the default time. This setting is usually increased when additional time is needed by VMs in order to ensure they have had enough time to shut down before the host reboots.

Registry Key: HKLM\Cluster\ShutdownTimeoutInMinutes 

Enter minutes in Decimal value.

Note: Changing of this registy value requires a server reboot in order to take effect:

Figure 6. Registry Shutdown Option

• Run the Cluster Validation periodically to remediate any issues

Hyper-V Replica

• Run the Hyper-V Replica Capacity Planner. The Capacity Planner for Hyper-V Replica, allows you to plan your Hyper-V Replica deployment based on the workload, storage, network and server characteristics.
• Update inbound traffic on the firewall to allowTCP port 80 and/or port 443 traffic. (In Windows Firewall, enable “Hyper-V Replica HTTP Listener (TCP-In)” rule on each node of the cluster. Shell commands to achieve the above are:

PS C:\Windows\system32> netsh advfirewall firewall set rule group="Hyper-V Replica HTTP" new enable=yes
PS C:\Windows\system32> netsh advfirewall firewall set rule group="Hyper-V Replica HTTPS" new enable=yes

• Virtual hard disks with paging files should be excluded from replication, unless the page file is on the OS disk.
• Test failovers should be performed monthly, at a minimum, to verify that failover will succeed and that virtual machine workloads will operate as expected after failover

Hyper-V Cluster-Aware Updating

• Place all Cluster-Aware Updating (CAU) Run Profiles on a single File Share accessible to all potential CAU Update Coordinators. Run Profiles are configuration settings that can be saved as an XML file called an Updating Run Profile and reused for later Updating Runs.

Hyper-V SMB 3.0 File Shares

• An Active Directory infrastructure is required, so you can grant permissions to the computer account of the Hyper-V hosts.
• Loopback configurations (where the computer that is running Hyper-V is used as the file server for virtual machine storage) are not supported. Similarly, running the file share in VM’s that are hosted on computer nodes that will serve other VM’s is not supported.

Hyper-V Integration Services

• Ensure Integration Services (IS) have been installed on all VMs. IC's significantly improve interaction between the VM and the physical host.

Hyper-V Offloaded Data Transfer (ODX) Usage

• If your SAN supports ODX; you should strongly consider enabling ODX on your Hyper-V hosts, as well as any VMs that connect directly to SAN storage LUNs.

Be sure to run this command on every Hyper-V host that connects to the SAN, as well as any VM that connects directly to the SAN.

This concludes our Windows 2012 Hyper-V Best Practices article. We hope you’ve found the information provided useful and that it helps make your everyday administration a much easier task.