Failover Clustering and Network Load Balancing Team Blog
The Windows Server 2012 Cluster Migration Wizard is a powerful and time-saving tool that copies cluster roles from a source cluster to a target cluster. Although the Cluster Migration Wizard can move almost any clustered workload to Windows Server 2012, we get many questions about migrating highly available virtual machines (HA VMs). There are two ways that you will be able to move HA VMs to a Windows Server 2012 Failover Cluster:
In this blog I will focus on using the Cluster Migration Wizard to move HA VMs. Depending on what operating system version you are running today, there are some considerations:
Migrate Clustered VMs
Migrate Clustered VMs from Windows Server 2008 R2 SP1 to Window Server 2012
Move Clustered VMs from Windows Server 2008 SP2 to Windows Server 2012
Windows Server 2012 Failover Clustering Cluster Migration Wizard
System Center Virtual Machine Manager 2012 (SCVMM 2012)
Note: Live Migration of virtual machines (VMs) from Windows Server 2008 R2 to Windows Server 2012 is not supported. As a result, migrating VMs to Windows Server 2012 can be fast, but it is not a zero-downtime event - a brief maintenance window is required to cut over to the new cluster roles. Fortunately, cluster migration can be tested with no impact to a running cluster, so that issues can be identified prior to actual migration.
The Windows Server 2012 Cluster Migration Wizard will move VMs from the following Windows Server OS versions:
Source Cluster Node OS
Target Cluster Node OS
Windows Server 2008 SP2
Windows Server 2012
Windows Server 2008 R2 SP1
Note: The Windows Server 2012 Cluster Migration Wizard requires that the latest service packs be installed on the source clusters. Windows Server 2008 clusters are required to be upgraded to Service Pack 2 prior to migration. Windows Server 2008 R2 clusters are required to be upgraded to Service Pack 1 prior to migration.
The following steps are required to prepare a new (target) cluster for the Cluster Migration Wizard – it may typically take approximately two hours to prepare a new Windows Server 2012 cluster with a small number of nodes. Here is an overview of the process:
i. The source VMs should be shut down and turned off.
ii. The source cluster CSV volumes that have been migrated should be off-lined.
iii. The storage that is common to both clusters (LUNS) should be masked (hidden) from the source cluster, to prevent accidental usage by both clusters.
iv. The storage that is common to both clusters (LUNS) should be presented to the new cluster.
v. The CSV volumes on the target cluster should be on-lined.
vi. The VMs on the target cluster should be on-lined.
vii. VMs are migrated and ready for use!
Note: If one VM on a CSV disk is selected for migration, the Cluster Migration Wizard will require all VMs (and auto-select them for you) on that CSV to be migrated too.
A. Let’s assume that we’ve completed the planning steps 1-3 above, and that we have a Highly Available VM running on a Windows Server 2008 R2 cluster – the source cluster - notice that the VM is running, and that it depends on a CSV disk resource:
B. On the Windows Server 2012 cluster – the target cluster - from the Failover Cluster Manger, select a cluster and then use the More Actions | Migrate Roles… menu to launch the Cluster Migration Wizard:
C. The Cluster Migration Wizard (Migrate a Cluster Wizard) will appear – press Next:
D. Specify the name of the source cluster – press Next:
E. The source cluster (Windows Server 2008 R2) will be scanned, and the resources that can be moved will be identified – here I have selected the VM called “VHD_CSV”:
F. After pressing Next, we see that the Migration Wizard will prompt us for the Virtual Network Switch that the VM should use on the new (target) cluster – here I use the drop-down menu and select “Destination Lab Private”:
G. Pressing View Report will display the Pre-Migration Report – this will show you the Cluster Migration Wizard’s analysis of the cluster roles that can be migrated. Note that the Cluster Group and Available Storage are never migrated:
H. When you are ready to migrate the resources, press Next:
I. After migrating resources, the Post-Migration Report is displayed in the dialog:
J. By pressing View Report, the full report will be displayed in the default browser:
K. Note that there are two new resources on the target cluster – identical to the source cluster. Under Roles, you will see the VHD_CSV VM – note that it is Off. Migrated VMs are always initially set to off on the Target clusters, this allows you to pre-stage the new cluster, but to control when to make the cut over:
L. Under Storage then Disks, you will see the VHD_CSV-disk Physical Disk resource that was copied to the target cluster:
M. Now that the target cluster has been pre-staged, use the following steps during a maintenance window to cut over to the new Windows Server 2012 cluster:
1. Shutdown all VMs on the source Windows Server 2008 R2 cluster that have been migrated.
2. Configure the storage:
a. Unmask the common shared storage (LUNs) so that they are not presented to the Windows Server 2008 R2source cluster
Note: Data could become corrupt if they are presented to multiple clusters at the same time.
b. Mask the common shared storage (LUNs) to the Windows Server 2012 target cluster.
3. Start all VMs on the target Windows Server 2012 cluster.
In Windows Server 2012, the Cluster Migration Wizard is a powerful tool that provides agility and flexibility to customers using highly available VMs on Failover Clusters.
To learn how to use the Cluster Migration Wizard to move roles other than Hyper-V virtual machines, see the following step-by-step guide.
Clustering & High-Availability
The migration method works great and can also be done between different forests so long as there is a forest trust setup and the domain administrator account being used during the migration is added to the local Administrators group on each of the hosts from the other domain
Seems there's an inconsistency here. You say that you unmask and mask the storage from the old cluster to the new cluster, but the screenshot shows that it is on-line on 2012 prior to the unmask/mask step. So do you have to present the storage to the 2012 cluster prior to running the wizard then just unmask from the old cluster after you shutdown and offline it on the old cluster?
Second, can you do this in stages where you migrate say one CSV at a time? What happens to the VMs and CSV resources after you cut them over to the new cluster? Do they just show as failed and you can Delete them?
One other comment/question: Don't you need to delete all snapshots on the 2008/R2 VMs and make sure they're shutdown cleanly (no Saved State) prior to the migration? That seems like a prereq for import of the VMs on 2012. Thanks!
I saw the inconsistency too. As well as the screen shot, the top part of the article (step 6) says to mask it from source then unmask on target (when doing the actual cutover), but at the screenshot directions, the writing says to unmask from source (step M2). The screen shot of the CSVs being "online" on the target is also throwing me off. Shouldn't they be offline at that stage?
I'm at step M currently. To get to there, all I did was setup a new 2012 cluster and ran the wizard. I didn't even point the new cluster to my LUNS yet. The migration wizard completed successfully. All VMS and CSVs show up on my 2012 cluster, and all are offline as I'd expect (contrary to the screenshot).
To finish the migration I will
Offline all storage
remove source server from LUN mappings on my SAN
Add target 2012 servers to LUN mappings
online storage on 2012 cluster
Have I read the article right, and the above steps will work?
Hi, I just finished this procedure so thought I would put my order of doing things on the SAN.
1) I ran the migration wizard with the Lun ONLY connected to the old cluster (Win 2008 R2 hv)
2) Once the migration wizard completes the Volume will appear under Disks as offline.
3) At this point remove the Lun from the old cluster (win 2008 R2 hv)
4) Assign the Lun to the new cluster (win 2012 hv)
5) Bring the Disk Online in the cluster manager, disks section)
6) Boot your VM's back up.
Worked perfectly for me, hope this helps.
This blog works fine if you have only VM's created using the Failover Cluster Manager.
But when you create VM's using SCVMM 2008 R2 (and possibly 2008 too) it's useless.
In our (company) situation, all VM's are created in SCVMM using a template.
The migration wizard runs succesfully, but upon starting the VM (and after switching the CSV's between clusters of course) it will not start due to problems with the Configuration File which seem to be related to AzMan.
The error is a event ID 1069.
SCVMM2012 may be a way, but that would mean (as far as I can figure out, due to the lack of information on this) that I would need to create new CSV's for the target cluster and wait way too long to migrate the VM's.
We have 40 of them of which two have between 2.5 and almost 3TByte worth of VHD's.
It would be very nice to have the wizard understand a VM is created using SCVMM 2008 R2 and either report that saying it's not working on the 2012 cluster, or correct it for the 2012 cluster.
The way it works not, it doesn't.
Due to the lack of an edit button: "The way it works now, it doesn't"
Thank you so much for sharing such an use full steps...
it is a great article, but I need some help for the following:
I have 2 clusters (Cluster1, Cluster2) both 2008 R2, and I have a stand alone hyper-v with 2008 R2.
now I need to build one new cluster using the 5 nodes (cluster1 nodes+cluster2 nodes+ the stand alone server) with Windows 2012, please note that I have new SAN storage.
I will do the following:
1. evict one node from each cluster.
2. build new cluster with windows 2012 using the new SAN.
now my questions:
1. when evicting nodes from the old cluster do I need stop presenting the old LUN on windows 2012?
2. when using the cluster Migration Wizard do I need to make the old LUN off-lined?
3. does all tasks should be done using maintenance windows?
@Samer F. Mustafa,
Thanks for your question - first, please note that there is a great support community on the High Availability (Clustering) TechNet forum - definitely the best place for community questions because a far greater number of people can reply to questions: social.technet.microsoft.com/.../home
Regarding your migration scenario, the Cluster Migration Wizard assumes that storage will be "reused" between the old (source) and new (target) clusters. Another way to say this: we assume that the physical storage for your VMs is not going to change.
In your case, you would like to use a new SAN, which is not storage "reuse", it is "new storage" :-(
There are still some approaches that might work for you:
A. Build the new WS.2012 (WS.2012 R2) cluster as you planned, but connect both the OLD SAN and the NEW SAN to the cluster if you have adequate number of HBA cards. First, use the Cluster Migration Wizard (as described in this blog article) to migrate the VMs from WS.2008 R2 to WS.2012 (or WS.2012 R2). Remember that this will require VM downtime (approximately 5-10 minutes, depending on VM shutdown and start speed). Remember also that you MUST NEVER run the VMs on both old (source) cluster and new (target) cluster because of the danger of data corruption. AFTER you have verified that the VMs are healthy and running on the new WS.2012 (or WS.2012 R2) cluster, you can use the "Move Virtual Machine Storage" wizard to move the source of the storage from the OLD SAN to the NEW SAN. (Please see this blog entry: blogs.msdn.com/.../10298203.aspx.) Note that this operation does not require any further VM downtime HOWEVER NOTE that it can be extremely expensive in terms of network bandwidth, and so it may not be a feasible / viable option for your environment. I strongly advise that you test this approach before committing to it. Some customers who have extra network bandwith report that they are happy with this feature.
B. You can also attempt to use Hyper-V export on the WS.2008 R2 host, followed by Hyper-V import on the WS.2012 (or WS.2012 R2) host. My understanding is that this technique should work for most VMs, but there may be some VM configurations that will not be supported... Please check that this technique will work in your environment.
Windows Server Failover Clustering Team.