Using Live Migration to Move Virtual Machines to a New Host

Moving a Virtual Machine (VM) from one stand-alone Microsoft Hyper-V host server to another is a common practice. It is most often associated with an upgrade cycle where the old Hyper-V server is being replaced with new hardware and an updated Operating System.

The Shared Nothing Live Migration feature is a powerful tool to complete this task. This feature is also referred to as Live Migration without Failover Clustering in Windows Server 2016. It allows an administrator to move a running VM from the old server automatically and with minimum impact to the environment. This capability was introduced in Windows Server 2012 and it provides interoperability with the later Operating Systems. This Cross-Version Migration capability enables the movement of hosted VMs from an older server, such as a Windows Server 2012 R2 host, to a newer Operating System like Windows Server 2016 or later.

The process relies on the same technology used with Hyper-V Replica to replicate the files that compose the VM (VHDX, config, memory contents, etc.) to the new server and then automate a cut-over from the old host to the new one once the transfer is complete. The replication process includes the memory contents of the running VM. Once the transfer is complete the VM commences to run on the new host with a nearly imperceptible interruption of service. This momentary transition can be observed as a single missed ping reply during the transition. End-users and applications typically cannot notice any change or interruption.

There are a few requirements based on the versions of Hyper-V in play:

  • A user account with administrative privileges on both source and destination Hyper-V servers. This account will need to be a member of the Domain Administrators group if using constrained delegation
  • A minimum of VM version 5 to enable migrations from Windows Server 2012 R2 and Windows Server 2016
  • Supported Cross-Version Migrations:
Windows Server 2012TO/FROMWindows Server 2012
Windows Server 2012TOWindows Server 2012 R2
Windows Server 2012 R2TO/FROMWindows Server 2012 R2
Windows Server 2012 R2TOWindows Server 2016
Windows Server 2016TO/FROMWindows Server 2016
  • Source and destination Hyper-V servers must be members of the same Active Directory domain, or belong to domains that trust each other

Key Considerations

The authentication method for Live Migration determines which protocol will be used to authenticate the live migration traffic. The use of Kerberos requires additional configuration of Constrained Delegation in Active Directory. This may be useful in cases where you want to enable the ability to move VM’s between hosts for an undetermined period as part of normal operations. For a simple one-time migration related to a Hyper-V host upgrade you may want to consider using the simpler Credential Security Support Provider (CredSSP) method. One limitation of the CredSSP method is that it requires that you are actively logged on to the source server.

The performance of the Hyper-V servers may be impacted by the migration process. There are options to reduce not only the load on the server, but also the time required to transfer the contents of the VM’s running memory. In most simple use cases the Compression option in conjunction with a TCP/IP connection will provide acceptable performance during the migration.

You can also manually specify which network connection the migration will use. This could be beneficial if the source and destination servers have multiple network connections so that the highest speed connection can be used, and/or the migration occurs on a network segregated from normal production network traffic.


To configure Live Migration using CredSSP:

  1. Open Hyper-V Manager. (From Server Manager, click Tools>>Hyper-V Manager.)
  2. In the navigation pane, select one of the servers. (If it isn’t listed, right-click Hyper-V Manager, click Connect to Server, type the server name, and click OK. Repeat to add more servers.)
  3. In the Actionpane, click Hyper-V Settings >>Live Migrations.
  4. In the Live Migrationspane, check Enable incoming and outgoing live migrations.
  5. Under Simultaneous live migrations, specify a different number if you don’t want to use the default of 2.
  6. Under Incoming live migrations, if you want to use specific network connections to accept live migration traffic, click Addto type the IP address information. Otherwise, click Use any available network for live migration. Click OK.
    virtual machine live migration
  7. To choose CredSSP and performance options, expand Live Migrationsand then select Advanced Features.
    • In this example we are configuring an intended one-time use to complete a migration of a VM as part of a host upgrade, under Authentication protocol, select CredSSP.
    • Under Performance options, select Compression to enable compression of the VM’s memory before using TCP/IP to transfer the running contents.
  8. Click OK.
  9. Select the other server in Hyper-V Manager and repeat the steps.
    virtual machine live migration

PowerShell can also be used to perform or script the migration. The available commands include Enable-VMMigration, Set-VMMigrationNetwork, and Set-VMHost. The following commands would be used to complete the configuration above:

PS C:> Enable-VMMigration

PS C:> Set-VMHost -VirtualMachineMigrationAuthenticationType CredSSP

Note: The default configuration includes 2 simultaneous live migrations, use any available network for live migration, and Compression.

Virtual Machine Live Migration

The process to migrate, or move, a VM to the destination server is very simple. Using the CredSSP authentication option, you will need to be logged on to the source server. Using Hyper-V Manager, the move is completed using a wizard that will ask you what type of move you will be performing. You can move either the entire VM including its disk files or move the storage associated with a specific VM to a new storage location.

  1. Open Hyper-V Manager. (From Server Manager, click Tools>>Hyper-V Manager.)
  2. In the navigation pane, select one of the servers. (If it isn’t listed, right-click Hyper-V Manager, click Connect to Server, type the server name, and click OK. Repeat to add more servers.)
  3. From the Virtual Machines pane, right-click the virtual machine and then click Move. This opens the Move Wizard.
    virtual machine live migration
  4. Use the wizard pages to choose the type of move, destination server, and options.
    virtual machine live migration
    virtual machine live migration
    virtual machine live migration
    virtual machine live migration
  5. On the Summary page, review your choices and then click Finish.

The progress of the move can be monitored in Hyper-V Manager. The time required will be dependent on factors including the size of the VM’s hard disk and memory files and the speed of the network connecting the source and destination servers. You may be prompted to connect the VM to a Virtual Switch if the names differ between the source and destination servers. The VM will be removed from the source server and will appear in the Virtual Machines pane of Hyper-V Manager on the destination server once the migration completes.

The Move-VM PowerShell command can also be used to move the VM. The following command mimics the example above:

PS C:> Move-VM VMname DestinationServer -IncludeStorage -DestinationStoragePath D:Hyper-V

Have issues with your infrastructure? We have a team full of IT experts ready to help. Let’s talk!

This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.

About the Author