High availability

Hyper-V Replica allows simple failover to occur between Hyper-V hosts, without the need for a cluster. To configure a simple one-way failover solution using Hyper-V Replica, configure the destination VM as a replica server, either in Hyper-V Manager or PowerShell. ^{[Set-VMReplicationServer][Set-VMReplicationServer] lab} The destination host must also have firewall ports opened corresponding to the authentication method chosen. The source VM, which is to be replicated, must have its options configured through the Enable Replication wizard. ^{[Enable-VMReplication][Enable-VMReplication]} To use Hyper-V Replica as a (two-way) failover solution, configure both VMs as replica servers.

Migrations can take place one of three methods:

• Live Migration moves only the system state and live memory contents, not data files. Live migration requires that the hosts be, if not clustered, at least part of the same (or a trusted) domain. Live Migration requires that VHD files be placed on shared storage and both hosts have appropriate permissions to access said storage. An unpopulated VM is created on the destination with the same resources as the source before transferring memory pages. Once the servers have an identical memory state, the source VM is suspended and the destination takes over. Hyper-V notifies the network switch of the change, diverting network traffic to the destination. Authentication can be made by [CredSSP][CredSSP] or Kerberos.

When a Hyper-V cluster is created, the Failover Cluster Manager launches the High Availability Wizard, which configures the VM to support Live Migration. The same thing can be done with the PowerShell cmdlet Add-ClusterVirtualMachineRole.

Additionally, using Kerberos authentication for live migration requires constrained delegation, which enables a server to act on behalf of a user for only certain defined services. This must be configured within Active Directory Users and Computers, by opening the Properties of the source Computer object, and changing the setting under the Delegation tab.

• An additional, outdated method of migration is quick migration, which was present in Windows Server prior to the introduction of live migration and persists in Windows Server 2016 for backward compatibility. A quick migration involves pausing the VM, saving its state, moving the VM to the new owner, and starting it again. A quick migration always involves a short period of VM downtime.

• Shared Nothing Live Migration requires that source and destination VMs be members of the same (or trusted) domain, and source and domain servers must be running the same processor family (Intel or AMD) and linked by an Ethernet network running a minimum of 1 Gbps. Additionally, both Hyper-V hosts must be running idential virtual switches that use the same name; otherwise the migration process will be interrupted to prompt the operator to select a switch on the destination server. The process of migrating is almost identical to a Live Migration, except that you select the "Move the Virtual Machine's Data To a Single Location" option on the Choose Move Options page of the Move Wizard.

• Storage Migration works by first creating new VHDs on the destination corresponding to those on the source server. While the source server continues to operate using local files, Hyper-V begins mirroring disk writes to the destination server and begins a single-pass copy of the source disks to the destination begins, skipping blocks that have already been copied. Once the copy has completed, the VM begins working from the destination server and the source files are deleted. For a VM that is shut off, storage migration is equivalent to simply copying files from source to destination.

Site-aware clusters have failover affinity. Node fairnes evalutes memory and CPU loads on cluster nodes over time.