Unable to migrate or clone the Virtual machine <VMName> because the version of the virtualization software does not match the virtual machine’s virtualization software on source (<ip_addr>). To be migrated or cloned, the virtual machine must be stopped and should not contain any saved data.
As the error message indicates, the virtualization software on the source host does not match the virtualization software on the destination: One is Windows Server 2008 R2 and the other one is Windows Server 2012. However, this error does not show up for ALL virtual machines.
Migration of VMs from Windows Server 2008R2 to Windows Server 2012 is not supported for the following configurations:
1. Running VMs (live VMs) cannot be migrated from Windows Server 2008R2 to Windows Server 2012.
2. VMs with State information cannot be migrated from Windows Server 2008R2 to Windows Server 2012.
What does this mean? VMs store state information in 2 ways:
1. If a VM is running, and the user selects to “Save State” the VM, then the state of the memory and disks of the VM are stored, and the VM is powered off.
2. If a VM is running and the user selects to create a Checkpoint/Snapshot of the VM, in this case as well the state of the memory and disks are stored.
How do we proceed?
Note: This issue has already been fixed in Update Rollup 1 for System Center 2012 Service Pack 1 which can be found here:
KB2785682 - Description of Update Rollup 1 for System Center 2012 Service Pack 1 ( http://support.microsoft.com/kb/2785682 )
The update can also be downloaded from Windows Update.
This update provides the user with a warning, indicating that all state information will be deleted automatically when migrating the VM and proceeds with the migration.
How do we proceed - Workaround?
If for some reason, you cannot or do not want to install the Update Rollup 1, the following workaround can be done:
Running VMs : This is a relatively easy fix. If the VM is powered off or shut down then a migration is possible if the VM does not have state information.
VMs with State information : For VMs that contain state information, just powering off the VM does not necessarily allow the VM to be migrated from Windows Server 2008 R2 to Windows Server 2012. For complex VMs that have multiple checkpoints, it is likely that one or more of the checkpoints/snapshots in the chain contains state information. The only way for a user to be able to migrate this VM from a Windows Server 2008 R2 to a Windows Server 2012 host within VMM 2012 SP1 is to go into the VM and delete the checkpoints one by one. It is not possible to know from just looking at the check point if it has State information. A user would have to apply the checkpoint and validate if the VM is restored in running state to be able to figure out whether the checkpoint has state information.
WORKAROUND: VMM provides more information on the VMs snapshots than Hyper-V. To view the checkpoints on a VM in VMM, select the VM and click the “Manage Checkpoints” button on the toolbar. The UI will show the following screen:
Note that each checkpoint has a small icon at the side of its name: This icon will help determine which checkpoints need to be deleted (Checkpoints with State information):
|
ICON |
Details |
|
|
Stopped Icon: Indicates that the current checkpoint was created without any State information |
|
|
Running Icon : Indicates that the current checkpoint has state information. This is the problem checkpoint. |
|
|
Indicates the currently active Checkpoint |
From this view the user has 2 options:
1. Directly remove all the checkpoints that have state information. This is relatively simple and the user would just need to remove all checkpoints with the “Running” Icon.
2. Preserve the Checkpoint information but delete the state information on the checkpoint. This is a more cumbersome process and would entail the following:
a. Restore the checkpoint in question.
b. Stop the VM
c. Take a new checkpoint.
d. Delete the original Checkpoint
This would need to be done for each checkpoint on the VM that has a “Running”
This issue is applies regardless of the ‘Availability’ property of the VM, meaning that HAVMs and non-HAVMs would be treated alike. Since the VM is first exported from the source and then imported into the destination, the HA property is not considered.
This workaround should work the same way for the following scenarios as well:
-
Windows Server 2008 R2 Standalone -> Windows Server 2012 Standalone
-
Windows Server 2008 R2 Standalone-> Windows Server 2012 Cluster (Promote the VM to HA in the process)
-
Windows Server 2008 R2 Cluster -> Windows Server 2012 Cluster (HA VM retained when migrating)
-
Windows Server 2008 R2 Cluster -> Windows Server 2012 Standalone(VM demoted from HA to nonHA during migration)
Donovan Vanhaltren | SDET | Microsoft Corporation
Get the latest System Center news on Facebook and Twitter :
System Center All Up:
http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog:
http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog:
http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog:
http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog:
http://blogs.technet.com/momteam/
System Center – Service Manager Team blog:
http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog:
http://blogs.technet.com/scvmm
Windows Intune:
http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog:
http://blogs.technet.com/sus/
The AD RMS blog:
http://blogs.technet.com/b/rmssupp/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Forefront Endpoint Protection blog :
http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog :
http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog:
http://blogs.technet.com/b/isablog/
The Forefront UAG blog:
http://blogs.technet.com/b/edgeaccessblog/