Use live migration without Failover Clustering to move a virtual machine

Applies To: Windows Server 2016

This article shows you how to move a virtual machine by doing a live migration without using Failover Clustering. A live migration moves running virtual machines between Hyper-V hosts without any noticeable downtime.

To be able to do this, you’ll need:

A user account that’s a member of the local Hyper-V Administrators group or the Administrators group on both the source and destination computers.

The Hyper-V role in Windows Server 2016 or Windows Server 2012 R2 installed on the source and destination servers and set up for live migrations. You can do a live migration between hosts running Windows Server 2016 and Windows Server 2012 R2 if the virtual machine is at least version 5.

The Hyper-V management tools installed on a computer running Windows Server 2016 or Windows 10, unless the tools are installed on the source or destination server and you’ll run them from there.

Use Hyper-V Manager to move a running virtual machine

Open Hyper-V Manager. (From Server Manager, click Tools >>Hyper-V Manager.)

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.)

From the Virtual Machines pane, right-click the virtual machine and then click Move. This opens the Move Wizard.

Use the wizard pages to choose the type of move, destination server, and options.

On the Summary page, review your choices and then click Finish.

Use Windows PowerShell to move a running virtual machine

The following example uses the Move-VM cmdlet to move a virtual machine named LMTest to a destination server named TestServer02 and moves the virtual hard disks and other file, such checkpoints and Smart Paging files, to the D:\LMTest directory on the destination server.

Troubleshooting

Failed to establish a connection

If you haven’t set up constrained delegation, you must sign in to source server before you can move a virtual machine. If you don’t do this, the authentication attempt fails, an error occurs, and this message is displayed:

«Virtual machine migration operation failed at migration Source. Failed to establish a connection with host computer name: No credentials are available in the security package 0x8009030E.»

To fix this problem, sign in to the source server and try the move again. To avoid having to sign in to a source server before doing a live migration, set up constrained delegation. You’ll need domain administrator credentials to set up constrained delegation. For instructions, see Set up hosts for live migration.

Failed because the host hardware isn’t compatible

If a virtual machine doesn’t have processor compatibility turned on and has one or more snapshots, the move fails if the hosts have different processor versions. An error occurs and this message is displayed:

The virtual machine cannot be moved to the destination computer. The hardware on the destination computer is not compatible with the hardware requirements of this virtual machine.

To fix this problem, shut down the virtual machine and turn on the processor compatibility setting.

From Hyper-V Manager, in the Virtual Machines pane, right-click the virtual machine and click Settings.

In the navigation pane, expand Processors and click Compatibility.

Check Migrate to a computer with a different processor version.

Click OK.

To use Windows PowerShell, use the Set-VMProcessor cmdlet:

VMware Workstation 3.2

Moving an Older Virtual Machine

Moving an Older Virtual Machine

If you have created a virtual machine using VMware Workstation 3.0 or 2.x, or another VMware product, and you want to move it to a different computer or to another directory on your host, you need to perform the following tasks.

Note: These instructions assume that you are using a virtual disk — stored in a set of .vmdk files on your host computer.

It is always safest to make backup copies of all the files in your virtual machine’s folder (directory) before you start a process like this.

Preparing Your Virtual Machine for the Move

Preparing Your Virtual Machine for the Move

Be sure you know whether the virtual disk is set up as an IDE disk or a SCSI disk. You can check this in the Configuration Editor (Settings >Configuration Editor).

Also, note the size of the virtual disk you are moving. You need this information when you prepare the new host machine, as described in the next section.

Shut down the guest operating system. If the virtual machine is suspended, resume it, then shut down the guest operating system.

Note: Do not move a suspended virtual machine from one host to another.

If your virtual machine is using disks in undoable mode, it is best to commit or discard the changes when the guest operating system shuts down. If you cannot commit or discard the changes to your disk, read Considerations for Moving Disks in Undoable Mode.

If you have a network connection between the original host machine and the new host, you are finished with the preparations on the original host. Otherwise, you need to have a way of moving the virtual disk (.vmdk) files from the virtual machine’s directory to the new host. You could move them to a shared network directory, for example, or burn them to CD-ROMs if they are not too large.

Note: If your disks are using undoable mode and you have not committed or discarded your changes, you must also move the redo-log (.REDO) file to the new host computer.

Preparing the New Host Machine

Preparing the New Host Machine

Make sure VMware Workstation is installed and working correctly on the new host computer.

Run the New Virtual Machine Wizard (on Windows hosts) or Configuration Wizard (on Linux Hosts) and select the appropriate guest operating system for the virtual machine you’re moving.

Choose a virtual disk for your hard drive and use a drive size that matches the size of the virtual disk you plan to move.

Select all appropriate network, floppy and CD-ROM settings. Do not make any changes with the Configuration Editor at this point.

Save your settings and close VMware Workstation.

In the folder (directory) just created for the new virtual machine, delete the brand new .vmdk files that were just created.

Locate the virtual disk files you are moving and copy them into the new virtual machine directory.

Note: If your virtual machine is using disks in undoable mode and you did not commit or discard your changes before the move, you must also move the redo-log (.REDO) file to the new host computer.

Start VMware Workstation again and open the new virtual machine you just created. Go to Settings >Configuration Editor.

Be sure the virtual machine is configured to use the virtual disk files you moved from the original host. You need to confirm that the new disk’s settings — IDE or SCSI and the file name for the first .vmdk file — match those that were used on the original host machine.

Windows host: The device listing for the hard drive shows whether it is SCSI or IDE. If that setting does not match the virtual disk you are migrating, select the hard disk and click Remove. Then click Add and use the Add Hardware Wizard to add an IDE or SCSI disk as appropriate. To specify IDE or SCSI, when you reach the Disk File screen in the wizard, click the Advanced button.

Be sure the filename and path for the virtual disk match the actual filename and location for the first .vmdk file used by the virtual machine you are moving.

Linux host: Click the + signs to expand the SCSI Devices and IDE Drives categories. Be sure that the virtual machine’s settings match those of the virtual disk you are migrating. If you need to remove a virtual disk from the configuration, select that disk in the list on the left, then click Remove in the panel on the right. To add a virtual disk, select the appropriate disk from the list on the left (for a boot disk, use either SCSI 0:0 or the IDE disk labeled P-M) and click Install.

Be sure the filename and path for the virtual disk match the actual filename and location for the first .vmdk file used by the virtual machine you are moving.

Considerations for Moving Disks in Undoable Mode

Considerations for Moving Disks in Undoable Mode

Once you commit or discard changes made to a disk in undoable mode, you can move your disk between Linux and Windows host operating systems. You can also move your disk to different locations on your computer and to other computers with the same host operating system.

However, if you cannot or do not want to commit or discard the changes made to your undoable disk, note the following:

• You can always move a disk in undoable mode between host operating systems of the same general type (for example, between two Microsoft Windows systems, or between two Linux systems). Depending upon how the disk was first set up, you may have to place the disk and its redo log in a folder (directory) that has a path name identical to that of the current folder (directory).
• You may be able to move the disk in undoable mode between Windows and Linux host systems, and move the disk to a different folder (directory) on your current system, if there is no path name information in the virtual machine’s configuration file. This is true for virtual machines created under VMware Workstation 3.1 or higher; however, virtual machines created with older versions of Workstation or any other VMware product contain full path names.

Follow these steps to check the configuration and see whether or not you can move your undoable disk without committing or discarding changes:

Start VMware Workstation.

If you are moving a disk in undoable mode from one computer to another computer, start VMware Workstation on the computer that currently has your disk.

Open the configuration file for the virtual machine that uses the undoable mode disk you wish to move.

In the VMware Workstation window, select File > Open and choose the configuration file of the virtual machine with the disk you want to move.

Start the Configuration Editor.

Select Settings > Configuration Editor.

Examine the entry for your virtual disk to see whether it includes a full path to the first virtual disk file. For example, on a Windows host, you might see a Disk File listing like this:

My Documents\My Virtual Machines\Windows Me\Windows Me.vmdk

Entries for SCSI disks are similar.

If your Disk File information resembles that above, with a full path to the first disk file, then as long as you have not committed or discarded changes to the undoable disk, note the following:

• You can move the disk to another computer of the same type (Windows to Windows).
• You must place the virtual machine’s other files (.vmx and .REDO on Windows, .cfg and .REDO on Linux) in the same relative location on the new computer. In other words, if the virtual machine’s files reside in
  My Documents\My Virtual Machines\Windows Me\
  on the original host computer, you must place them in that same location on the new host computer.
• You cannot move the disk to a computer of a different type (Windows to Linux or vice versa).
• You cannot move the disk to another folder (directory) on the current system.

If your Disk File information does not contain a path, it looks like this:

If your disk entry resembles the one above (just a filename with a .vmdk extension), you can move the disk and redo log anywhere you wish.

Move a Windows VM to another Azure subscription or resource group

This article walks you through how to move a Windows virtual machine (VM) between resource groups or subscriptions. Moving between subscriptions can be handy if you originally created a VM in a personal subscription and now want to move it to your company’s subscription to continue your work. You do not need to stop the VM in order to move it and it should continue to run during the move.

New resource IDs are created as part of the move. After the VM has been moved, you will need to update your tools and scripts to use the new resource IDs.

Use the Azure portal to move a VM to a different subscription

You can move a VM and its associated resources to a different subscription by using the Azure portal.

1. Go to the Azure portal to manage the resource group containing the VM to move. Search for and select Resource groups.
2. Choose the resource group containing the VM that you would like to move.
3. At the top of the page for the resource group, select Move and then select Move to another subscription. The Move resources page opens.
4. Select each of the resources to move. In most cases, you should move all of the related resources that are listed.
5. Select the Subscription where you want the VM to be moved.
6. Select an existing Resource group, or enter a name to have a new resource group created.
7. When you are done, select that you understand that new resource IDs will be created and that the new IDs will need to be used with the VM after it is moved, and then select OK.

Use the Azure portal to move a VM to another resource group

You can move a VM and its associated resources to another resource group by using the Azure portal.

1. Go to the Azure portal to manage the resource group containing the VM to move. Search for and select Resource groups.
2. Choose the resource group containing the VM that you would like to move.
3. At the top of the page for the resource group, select Move and then select Move to another resource group. The Move resources page opens.
4. Select each of the resources to move. In most cases, you should move all of the related resources that are listed.
5. Select an existing Resource group, or enter a name to have a new resource group created.
6. When you are done, select that you understand that new resource IDs will be created and that the new IDs will need to be used with the VM after it is moved, and then select OK.

Use Powershell to move a VM

To move a virtual machine to another resource group, you need to make sure that you also move all of the dependent resources. To get a list with the resource ID of each of these resources, use the Get-AzResource cmdlet.

You can use the output of the previous command to create a comma-separated list of resource IDs to Move-AzResource to move each resource to the destination.

To move the resources to different subscription, include the -DestinationSubscriptionId parameter.

When you are asked to confirm that you want to move the specified resources, enter Y to confirm.

Next steps

You can move many different types of resources between resource groups and subscriptions. For more information, see Move resources to a new resource group or subscription.