Hyper-V Cluster Setup on Windows Server Machines: A Step-by-Step Guide

One of the critical requirements for virtual infrastructures, especially in large data centers, is the elimination of a single point of failure and ensuring the high availability of services and apps. In a Hyper-V environment, the Microsoft Failover Clustering technology is available to configure multiple Hyper-V hosts (or nodes) that can take over the load if one host fails.

In this step-by-step guide, learn the practical aspects of Hyper-V failover clustering configuration, including initial host and network configuration, Hyper-V role installation, and cluster creation.

NAKIVO for Hyper-V Replication

NAKIVO for Hyper-V Replication

Business continuity in any failure scenario with robust replication for Hyper-V VMs. Verify replicas in seconds and automate VM failover to minimize downtime.

Hyper-V Host Configuration

To prepare hosts for failover clustering, we should select an operating system to install on all the hosts that will be used in a particular cluster. Then we need to perform a basic configuration of the environment, including all hosts, to prepare them for Hyper-V cluster setup.

Selecting an operating system to install

In this setup, we are using two Windows Server 2016 Server Core installations to minimize moving parts and to improve security. Using the Windows Server 2016 Server Core installation eliminates a lot of unnecessary components and reduces the footprint. The increased difficulty of administration with Server Core is offset by the benefits of efficiency and security. You can also use the newer Windows Server versions, such as Windows Server 2019 for Hyper-V cluster setup.

Note: For the administration and configuration of Windows Server 2016 Server Core, we use PowerShell.  It is technically possible to use Windows Server with Desktop Experience to configure Hyper-V failover clustering.

Initial configuration of the environment

Before thinking about the Hyper-V hosts as a cluster, we must perform our initial configuration of the hosts. This involves much of the same steps of preparing any Windows server – naming, network configuration, patching, etc. Network planning, in particular, is crucial in a Windows cluster as it allows for proper cluster communication as well as communication with shared storage.

  • Naming. Both servers have been named and joined to the lab domain. Note that starting with Windows Server 2016, joining a domain is no longer a prerequisite. Server configurations are displayed in the screenshots below for the first server H1. The configurations for the second server H2 are similar.

Initial server configuration required for building a cluster

  • Updates. We need to update any prospective Hyper-V cluster nodes to the latest patch level available according to the Hyper-V clustering best practices. Installing updates on Hyper-V hosts improves the security of our system. You may need to restart Windows to complete the installation of updates.

Installing Windows updates is one of Hyper V clustering best practices

  • Consistency. As a best practice, we want all our potential cluster nodes to be configured identically except for computer names and IP addresses. This ensures that everything is standardized between the hosts, including patch levels, networks, etc.

Network Planning

Proper environment planning mitigates many risks in the future. For the lab network in this scenario, four network adapters have been configured for each host. Both lab hosts are not doing any NIC teaming for simplicity sake. However, you would want to team your adapters in production to avoid having a single point of failure in any one network.

For our lab setup, we have:

  • Management and VM traffic
  • iSCSI
  • Private Cluster Traffic
  • Live Migration

With the above networks in mind, we assign IP Addresses to each server in our desired subnet ranges. VLANs are also a consideration here, as you will most likely want to align your subnets with VLANs provisioned. This would need to be thought through in advance.

iSCSI Storage Target Setup

Hyper-V cluster storage is a crucial point for building a cluster. For iSCSI storage in a lab environment, in this example, we are using FreeNAS to create iSCSI targets and present these to our Hyper-V cluster. Of course, setting up iSCSI on vendor hardware of your choice or software iSCSI can be different depending on the vendor, so always follow the methods defined for each.

Note: FreeNAS is a universal and flexible FreeBSD-based operating system that you can install on a computer to use it as NAS. You can create a Hyper-V cluster shared storage or build a backup appliance with FreeNAS and the NAKIVO solution.

Below is a quick overview of how the storage for Hyper-V failover clustering is set up using FreeNAS. We won’t delve into all the details of how to set up FreeNAS for iSCSI. However, here are the basic settings for presenting a couple of iSCSI targets to our Hyper-V hosts.

  1. Start the iSCSI service in FreeNAS and set up your network configuration for the storage network to match what you intend to use for the Hyper-V hosts.
  2. Check the base IQN setup for the targets that we will create.

Creating an iSCSI share for Hyper-V cluster storage

  1. Set up a portal in FreeNAS to listen for iSCSI traffic.

Creating an iSCSI Portal on FreeNAS

  1. Set up iSCSI target names. In our FreeNAS appliance, we are setting up:
  • a quorum volume to be used as a disk witness
  • a volume to be used for the Hyper-V cluster shared volume to house our VMs

Note: Quorum is the mechanism in a Windows cluster that is used to make sure that in the event of something going down between parts of a cluster, you always have a majority of cluster resources available for the cluster to function.

  • Starting with Windows Server 2012, every node in the cluster has a single quorum vote by default. By adding an extra vote with a file share, disk, or a new cloud storage account in Windows Server 2016, one part of the cluster should always get more than 50% of the quorum vote by claiming the share, disk, or cloud storage account vote.
  • With Windows Server 2012 R2, the recommendation changed to always configure the disk or file share witness. The vote is extended to the additional witness (file share, disk, or cloud storage account) only if there is an even number of nodes. With an odd node number, the witness does not get a vote and isn’t used.

In the screenshot below, we have created the two target names: a quorum volume to be used as a disk witness and a volume to be used for our cluster shared volume.

Configuring iSCSI targets for a witness and Hyper-V cluster shared volume

  1. Add Extents, which in the below example are mapped to the individual disks that we have physically assigned in our FreeNAS appliance.

Adding Extents in FreeNAS

  1. Associate the Target with the Extent. The targets are mapped to the storage in FreeNAS.

Associating iSCSI targets with Extents in FreeNAS

Installing the Hyper-V Role

To install the Hyper-V role service, run the following command in a PowerShell command prompt:

Install-WindowsFeature -Name Hyper-V -IncludeAllSubFeature -IncludeManagementTools -Restart

Installing a Hyper-V role is a requirement for Hyper-V cluster configuration

Setting Up Storage: Adding the iSCSI Portal Address

Before adding our iSCSI portal address, we need to configure and start the Microsoft iSCSI service as below:

  1. Set the service to automatic.

Set-Service -Name msiscsi -StartupType Automatic

  1. Start the service.

Start-Service msiscsi

  1. Use PowerShell to add the iSCSI portal address provisioned:

New-iscsitargetportal -targetportaladdress <IP address>

Configuring Hyper-V cluster storage – adding the iSCSI portal address

  1. Connect the specific iSCSI targets that, in our case, were created on our FreeNAS appliance. Below are examples of what we used in adding the FreeNAS targets to the Hyper-V hosts provisioned for the cluster.
  • Connect-IscsiTarget -nodeaddress iqn.2005-10.org.freenas.ctl:quorum -IsPersistent $true -IsMultipathEnabled $true -InitiatorPortalAddress -TargetPortalAddress
  • Connect-IscsiTarget -nodeaddress iqn.2005-10.org.freenas.ctl:hvvol1 -IsPersistent $true -IsMultipathEnabled $true -InitiatorPortalAddress -TargetPortalAddress

You can verify and see the targets that are added by running the Get-iSCSItarget command.

Verifying whether iSCSI targets have been added for Hyper-V cluster storage

Note: You can use the get-disk command to show disk information and make sure the Hyper-V cluster shared storage is online and healthy.

Checking configuration of Hyper-V cluster shared storage

Setting Up Virtual Switches

Configuring virtual switches is needed for proper Hyper-V failover cluster network configuration. We can use either PowerShell or Hyper-V Manager to set up our virtual switches for Hyper-V.

An example of the command to create a virtual switch in PowerShell:

New-VMSwitch “ExternalSwitch01” -NetAdapterName “Public” -AllowManagementOS 1

Note: Set up your virtual switch names identically between both hosts as we need to ensure that the virtual switches match, especially when performing a live migration.

Network configuration for Hyper-V failover clustering

Creating a Hyper-V Cluster

Using PowerShell, creating the cluster is a simple one-line commandlet.

  1. Before creating the cluster, run this command to validate the cluster configuration meets Hyper V clustering best practices:

Test-Cluster H1,H2

  1. Use the new-cluster commandlet to create a cluster and assign the name, the nodes, and a static IP address to the cluster.

New-Cluster -Name HVCluster -node H1,H2 -staticAddress

How to create Hyper-V cluster in PowerShell

  1. When the cluster creation process is finished, you see the output displaying the cluster name in the command line.

Hyper-V cluster setup in PowerShell

Hyper-V Clustered Shared Volumes

Even though we have shared storage from an iSCSI target perspective, we need to make sure the storage that houses our VMs is set up on a Hyper-V clustered shared volume. The clustered shared volume (CSV) was introduced in Windows Server 2008 R2 to be used with the Hyper-V role so that a VM can have VHD files accessed by any node in the cluster. There is also resiliency built into CSV, including I/O fault detection allowed for alternate communication paths to be used in the event of communication failures.

Let’s take a look at creating the clustered shared volume step by step for our VMs.

  1. Rename the cluster disk resource that will be used for VM storage (optional). In our lab setup, this is Cluster Disk 1:

(Get-ClusterResource | ?{$_.Name -eq “Cluster Disk 1”}).name = “VMs”

  1. Now we can add this volume to a cluster shared volume:

Get-ClusterResource -Name “VMs”| Add-ClusterSharedVolume

Note: We can also use Failover Cluster Manager to add a disk to the CSV:

Configuring Hyper-V cluster shared storage

  1. Check the state of the cluster shared volume with the get-clustersharedvolume commandlet.

Checking a state of a Hyper V cluster shared volume in PowerShell

Note: If you have a management workstation to connect using the Failover Cluster Manager, you can look at storage with the graphical user interface (GUI) by connecting to Windows Failover Cluster. Here we can easily see the Disks available and the roles assigned to them. Below we see both the Quorum and VMs disk that is designated as a cluster shared volume.

Hyper-V cluster storage is configured

Changing Hyper-V Storage Settings

Now that we have our clustered shared volume setup, we can change our Hyper-V settings to use our Hyper-V cluster shared volume as the default location for storing our VMs.

In the Hyper-V Settings for each host, change the Virtual Hard Disks location and the Virtual Machines location to your cluster shared volume, which is C:\ClusterStorage\volume(x) on your Hyper-V hosts.

Selecting Hyper-V cluster storage to store VM data

Creating a Highly Available VM

We can now launch Failover Cluster Manager and begin to create a highly available VM.

  1. Right-click the Roles and choose to create a New Virtual Machine.

Creating a HA VM to finish the Hyper-V cluster setup

  1. Choose the Hyper-V host (one of the cluster nodes) for the virtual machine.

Selecting a cluster node to create a new Hyper-V VM

  1. Work through the New Virtual Machine Wizard prompts to provision a new virtual machine.

Entering a VM name and using Hyper-V cluster storage

  • In the Connect Virtual Hard Disk step of the wizard, ensure that the virtual machine is created on our Hyper-V clustered shared volume.

Creating a new virtual disk on the Hyper-V cluster shared volume

  • The Summary step displays the options we selected.

Finishing the VM creation in a Hyper-V Failover cluster

  1. When you click finish, the High Availability Wizard displays the summary of enabling high availability on the role and the virtual machine. As you can see, it has been successfully enabled.

Checking High Availability for Hyper-V failover clustering

  1. If you want to take a look at the high availability report, you can click the View Report button, which displays a more detailed rendering of the high availability tests.

Viewing the high availability report for Hyper-V clustering

Hyper-V Failover cluster configuration is finished and we now have a highly available VM running in the cluster. You can create more VMs in your cluster to use Hyper-V High Availability.

Hyper-V cluster setup has been finished

Final Thoughts

Hyper-V failover clustering allows you to reduce the downtime of VMs in case of failure. However, this won’t protect your VM data if you don’t have frequent Hyper-V cluster backups. As VMs can migrate between hosts in the Hyper-V failover cluster, VM backup can be a daunting task. Use NAKIVO’s solution and easily back up even those VMs that are running in the cluster.

1 Year of Free Data Protection: NAKIVO Backup & Replication

1 Year of Free Data Protection: NAKIVO Backup & Replication

Deploy in 2 minutes and protect virtual, cloud, physical and SaaS data. Backup, replication, instant recovery options.

People also read