Stackvora.tech

Configure Live Migration Without Failover Clustering

Hyper-V Live Migration allows virtual machines (VMs) to move between physical hosts without any perceived downtime, a critical capability for host…

Hyper-V Live Migration allows virtual machines (VMs) to move between physical hosts without any perceived downtime, a critical capability for host maintenance, resource balancing, and disaster recovery preparedness. While Windows Server Failover Clustering (WSFC) is the traditional and most robust method for orchestrating Live Migration, it introduces complexity, overhead, and licensing costs that may not be suitable for all environments. This article details the configuration of Hyper-V Live Migration between standalone Hyper-V hosts using Kerberos authentication, providing a robust solution without the full overhead of WSFC.

This approach is particularly useful for smaller deployments, test environments, or scenarios where high availability is managed at an application layer rather than directly by the hypervisor. We will focus on Windows Server 2016/2019/2022 Hyper-V hosts, as the Kerberos configuration steps are largely consistent across these versions.

Prerequisites and Initial Setup

Before configuring Live Migration, ensure the following prerequisites are met on both source and destination Hyper-V hosts:

  • Hardware Virtualization: Both hosts must have Intel VT-x/EPT or AMD-V/RVI enabled in their BIOS/UEFI.
  • Network Connectivity: High-bandwidth (10 GbE or higher recommended), low-latency network connectivity between hosts. A dedicated Live Migration network is ideal to avoid contention. Ensure IP addresses are static and DNS resolution works correctly between hosts.
  • Shared Storage: While not strictly required for the migration process itself (VM state is moved over the network), shared storage (e.g., SMB 3.0 shares, iSCSI, Fibre Channel) is necessary for the VM's VHDX files to be accessible from both source and destination hosts if you want to avoid storage migration during Live Migration. If shared storage is not used, Live Migration will incur storage migration overhead.
  • Domain Membership: Both Hyper-V hosts must be members of the same Active Directory domain. This is crucial for Kerberos authentication.
  • Administrator Privileges: You need domain administrator credentials or delegated permissions to configure Active Directory for Kerberos constrained delegation.
  • Hyper-V Role: The Hyper-V role must be installed on both servers.

Enabling Live Migration via GUI

The simplest way to initiate Live Migration configuration is through the Hyper-V Manager GUI:

  1. On each Hyper-V host, open Hyper-V Manager.
  2. Right-click the host name and select Hyper-V Settings...
  3. In the left pane, select Live Migrations.
  4. Check Enable incoming and outgoing live migrations.
  5. Under Simultaneous live migrations, set a reasonable number (e.g., 2-4). This determines how many VMs can be migrated concurrently.
  6. Under Incoming live migration settings, select Use Kerberos.
  7. (Optional but Recommended) Under Advanced Features -> Migration settings, specify a dedicated network for Live Migration. This is crucial for performance. Select "Use these IP addresses for Live Migration" and add the IP addresses of the dedicated Live Migration network adapters on both hosts.
  8. Click Apply and OK.

Enabling Live Migration via PowerShell

For automation or headless servers, PowerShell is the preferred method:

# On both Hyper-V hosts (e.g., HVHOST01 and HVHOST02)
# Enable Live Migration
Enable-VMMigration

# Set authentication type to Kerberos
Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos

# (Optional) Configure simultaneous migrations (e.g., 4 concurrent)
Set-VMHost -MaximumVirtualMachineMigrations 4

# (Optional) Specify dedicated network for Live Migration (replace with your IPs)
# Example: 192.168.10.101 on HVHOST01, 192.168.10.102 on HVHOST02 for the migration network
Set-VMHost -VirtualMachineMigrationServiceIPAddress "192.168.10.101" # On HVHOST01
Set-VMHost -VirtualMachineMigrationServiceIPAddress "192.168.10.102" # On HVHOST02

Verify settings using: Get-VMHost | Select-Object VirtualMachineMigration*, MaximumVirtualMachineMigrations

Configuring Kerberos Constrained Delegation

Kerberos authentication for Live Migration without WSFC requires Constrained Delegation. Specifically, the source host needs to be able to delegate its credentials to the destination host for the Microsoft Virtual System Migration Service (VMMS) and CIFS (Common Internet File System) services. This ensures that when a migration is initiated from Host A, Host B can authenticate and access the necessary resources on Host A, and vice-versa.

This configuration must be performed from a Domain Controller or a management workstation with Active Directory Users and Computers (ADUC) and appropriate permissions.

Step-by-Step Delegation Configuration

Let's assume our Hyper-V hosts are HVHOST01 and HVHOST02, and our domain is stackvora.tech.

  1. Open Active Directory Users and Computers (dsa.msc).
  2. Navigate to the Computers container (or the OU where your Hyper-V hosts reside).
  3. Right-click on the source host's computer object (e.g., HVHOST01) and select Properties.
  4. Go to the Delegation tab.
  5. Select Trust this computer for delegation to specified services only.
  6. Choose Use Kerberos only.
  7. Click Add...
  8. In the "Add Services" dialog, click Users or Computers... and type the destination host's computer object name (e.g., HVHOST02). Click Check Names, then OK.
  9. From the list of available services, select the following Service Principal Names (SPNs):
    • cifs
    • Microsoft Virtual System Migration Service

    Click OK.

  10. Repeat steps 7-9, but this time add HVHOST01's computer object and select cifs and Microsoft Virtual System Migration Service. This ensures HVHOST01 can delegate to itself for certain operations if needed, but more importantly, it covers the reverse delegation needed for HVHOST02.
  11. Click Apply and OK.

Crucially, you must repeat the entire process for the second host (HVHOST02), configuring it to delegate to HVHOST01 for the same two services (cifs and Microsoft Virtual System Migration Service). This creates a bidirectional trust.

Verifying SPNs (Optional)

You can verify that the necessary SPNs are registered for your Hyper-V hosts using setspn.exe. This doesn't configure them but confirms their existence, which is required for Kerberos to function.

# On a domain-joined machine with Active Directory management tools
# Verify SPNs for HVHOST01
setspn -L HVHOST01

# Expected output should include entries like:
# HOST/HVHOST01
# HOST/HVHOST01.stackvora.tech
# Microsoft Virtual System Migration Service/HVHOST01
# Microsoft Virtual System Migration Service/HVHOST01.stackvora.tech
# RestrictedKrbHost/HVHOST01
# RestrictedKrbHost/HVHOST01.stackvora.tech
# cifs/HVHOST01
# cifs/HVHOST01.stackvora.tech

If the Microsoft Virtual System Migration Service SPN is missing, it usually indicates a problem with the Hyper-V role installation or service registration. A reboot of the Hyper-V host or restarting the VMMS service might resolve it.

Testing Live Migration

Once Kerberos constrained delegation is configured on both hosts, it's time to test the Live Migration. Create a test VM on one of the hosts (e.g., HVHOST01) with minimal resources.

Via Hyper-V Manager

  1. On HVHOST01, open Hyper-V Manager.
  2. Right-click on the running test VM.
  3. Select Move...
  4. In the "Move Wizard", click Next.
  5. Choose Move the virtual machine.
  6. Enter the destination host's name (e.g., HVHOST02) and click Next.
  7. On the "Choose Move Type" page, select Move the virtual machine's data to a single location (if using shared storage) or Move the virtual machine's data to different locations (if migrating storage as well). For simple Live Migration with shared storage, "Move only the virtual machine" is usually faster.
  8. Specify the destination path for the VM configuration and virtual hard disks.
  9. Review the summary and click Finish.

Via PowerShell

# From HVHOST01 (source) to HVHOST02 (destination)
# Ensure the VM is running
Move-VM -Name "TestVM01" -DestinationHost "HVHOST02" -IncludeDataPaths -VHDStoragePath "D:\Hyper-V\Virtual Hard Disks" -VMStoragePath "D:\Hyper-V\Virtual Machines" -Force

The -IncludeDataPaths, -VHDStoragePath, and -VMStoragePath parameters are crucial if you are not using shared storage and want to perform a storage migration alongside the VM migration. If you are using shared storage, you can often omit these, and the VM's configuration will be updated to point to the existing shared storage location on the destination host.

During the migration, observe the VM's status in Hyper-V Manager. The status should change to "Moving" and then disappear from the source host's list, reappearing on the destination host, all without interruption.

Common Pitfalls and Troubleshooting

  • Kerberos Delegation Mismatch: The most common issue is incorrect constrained delegation. Double-check that both cifs and Microsoft Virtual System Migration Service are specified, and that the delegation is configured bidirectionally (Host A delegates to Host B, and Host B delegates to Host A).
  • DNS Resolution Issues: Ensure both forward and reverse DNS resolution works for all Hyper-V hosts. Incorrect DNS can break Kerberos. Use nslookup and ping -a to verify.
  • Firewall Rules: Ensure Windows Firewall or any network firewalls are not blocking necessary ports. For Live Migration, TCP port 6600 is used. For SMB 3.0 (if using shared SMB storage for VMs), TCP ports 445 and 5445 are relevant.
  • Missing SPNs: If setspn -L <hostname> does not show the Microsoft Virtual System Migration Service SPN, restart the "Hyper-V Virtual Machine Management" service (VMMS) on the affected host. If it still doesn't appear, reinstalling the Hyper-V role might be necessary.
  • Network Performance: If migrations are slow or fail with timeouts, check network adapter settings, driver versions, and ensure the dedicated Live Migration network (if configured) is actually being used. Look for dropped packets or high latency.
  • Host Time Synchronization: Kerberos is highly sensitive to time differences. Ensure all domain controllers and Hyper-V hosts are synchronized to a reliable NTP source and their clocks are within 5 minutes of each other.
  • Event Logs: Always check the Hyper-V-VMMS, System, and Security event logs on both source and destination hosts for detailed error messages during migration attempts. Kerberos errors often appear in the Security log (Event ID 4625 for failed logins).
  • PowerShell Execution Policy: If scripts fail, ensure PowerShell execution policy allows them (e.g., Set-ExecutionPolicy RemoteSigned).

Back to the knowledge base · Ask the AI assistant