How to Move Highly Available (Clustered) VMs to Windows Server 2012 with the Cluster Migration Wizard

How to Move Highly Available (Clustered) VMs to Windows Server 2012 with the Cluster Migration Wizard

Rate This
  • Comments 39

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:

  1.        Windows Server 2012 Cluster Migration Wizard integrated into the Failover Clustering feature
  2.        System Center Virtual Machine Manager 2012 (SCVMM 2012) with Service Pack 1 

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:

Tool

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

Yes

Yes

Yes

System Center Virtual Machine Manager 2012 (SCVMM 2012)

Yes

Yes

No

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.

Windows Server 2012 Cluster Migration Wizard Source and Target OS Versions

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

Windows Server 2012

Windows Server 2012

Windows Server 2012

 

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.

Migration for Highly Available (Clustered) Hyper-V VMs

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:

  1.        The new (target) cluster nodes need to be physically configured (network, storage) – or in the case of cluster virtualization, the virtual network and storage settings of the VMs need to be configured. Ideally, both the old (source) cluster and the new (target) cluster will see common shared storage– storage can be reused and this will allow for the smoothest migration
  2.        Windows Server 2012 needs to be installed on all of the nodes in the cluster target cluster, and the Hyper-V Server Role and Failover Clustering feature should be installed on all nodes as well.
  3.        Create the new Windows Server 2012 target cluster using the Failover Cluster Manager or the New-Cluster PowerShell cmdlet.
  4.        Launch the Cluster Migration Wizard from the Failover Cluster Manager, select the source cluster, and then select the cluster roles on the source cluster that you’d like to migrate to the new cluster.
  5.        The Pre-Migration Report will identify issues that can impact migration of the selected cluster roles. After migrating, a Post-Migration Report will identify any manual steps that are needed to bring the cluster online.
  6.        The new cluster roles are always created offline - when VMs and users are ready, the following steps should be used during a maintenance window:

                                 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.

 

Walk Through: Migrating a HA VM from Windows Server 2008 R2 to Windows Server 2012

    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.

    Summary

    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.

    Rob Hindman

    Program Manager

    Clustering & High-Availability

    Microsoft

    Leave a Comment
    • Please add 8 and 5 and type the answer here:
    • Post
    • Hi Rob, thanks for posting this info, it is def going to be helpful for us. Couple of follow up questions though:

      1. So when you perform steps A through L on the walk through section, does the source cluster still continue to operate normally and have all the same resources (HA VMs) still running? For example, we can perform steps A-L during production hours and then cut-over (step M) during a scheduled maint period?

      2. Because the source cluster and target cluster are pointing to the same storage during the migration, there is no waiting for data copying, for example with really large VHDs?

      3. If the HA VMs have guest level iSCSI connections, that will migrate over as well as long as the target cluster has access to the same underlying storage device and virtual networks correct?

      4. What if you have non HA VMs on the source cluster. Do you have to perform an export process to move those over to the new cluster? Or is there a better way?

      5. If you currently have a 2 node, Win2008R2 cluster with shared storage quorum disk, can we drain one node of all VMs, remove it from the Win2008R2 cluster, rebuild it to be a new Win2012 node, and create a new Win2012 cluster with just that one node and a quorum disk? Then, once all the VMs have been migrated off, rebuild the leftover Win2008R2 node and have it join the new Win2012 cluster?

    • 1. So when you perform steps A through L on the walk through section, does the source cluster still continue to operate normally and have all the same resources (HA VMs) still running? For example, we can perform steps A-L during production hours and then cut-over (step M) during a scheduled maint period?

      [Rob]: Yes, steps A-L can be performed without interruption to the availability of the VMs. Step M should not take much time.

      2. Because the source cluster and target cluster are pointing to the same storage during the migration, there is no waiting for data copying, for example with really large VHDs?

      [Rob]: Yes, that is exactly correct – no data is actually copied.

      3. If the HA VMs have guest level iSCSI connections, that will migrate over as well as long as the target cluster has access to the same underlying storage device and virtual networks correct?

      [Rob]: Yes, iSCSI connections to the guests should work as long as the underlying storage device and virtual networks are identical on the source and target clusters.

      4. What if you have non HA VMs on the source cluster. Do you have to perform an export process to move those over to the new cluster? Or is there a better way?

      [Rob]: For non-HA VMs, the Hyper-V export-import process should be used.

      5. If you currently have a 2 node, Win2008R2 cluster with shared storage quorum disk, can we drain one node of all VMs, remove it from the Win2008R2 cluster, rebuild it to be a new Win2012 node, and create a new Win2012 cluster with just that one node and a quorum disk? Then, once all the VMs have been migrated off, rebuild the leftover Win2008R2 node and have it join the new Win2012 cluster?

      [Rob]: Yes, this should work. The only caveat when performing these steps with a two node cluster is that you will lose the capability to failover to another node during this process – I.E., you lose high availability.

    • Awesome, thanks for the great info!

      Follow up to question #4. If the source cluster and target cluster are pointing to the same storage that holds the non HA VM, can you do the export process without copying the VHDs? IIRC, the export process has now removed the "Export config only" option.

      Or can we use this option from Win2012 "Register the virtual machine in-place” as mentioned by Didier Van Hoye here:

      workinghardinit.wordpress.com/.../upgrading-hyper-v-cluster-nodes-to-windows-server-2012-beta-part-3

    • Thanks for this post; I'll be migrating a 2-node Hyper-V Server 2008 R2 cluster with a Dell MD3220i shared storage to Windows Server 2012 in the near future.

      Your answer to Berserkers question #5 gives me confidence that I shouldn't have too many issues, as long as I bring all of the CSV's offline on the source host.

      Rather than using the Cluster Migration Wizard, would this operation be simpler to just shutdown all the guests, offline the CSV's on the source cluster, bring them into the new cluster, and then "Register in place" all of the VM's in the new cluster?

    • Thanks for the Post.

      Is there a way to migrate a cluster partially. I. e. you have a 5 nodecluster with fairly new Hardware and only get money for buying 1 additional Node (with even newer Hardware) to start you're new cluster andthen get you're old cluster nodes integrated in the new one?

    • Hi Rob,

      In Step E, when we see the resources that can be moved and have to select the VM, can we select just one of  the existing VMs?

      I ask this because when we select just one VM, all other VMs in that Cluster Shared Volume become selected.

      Thanks.

    • Will this work if the source cluster servers are Windows 2008 Hyper-V?

    • Yes, see the section titled "Windows Server 2012 Cluster Migration Wizard Source and Target OS Versions" for more information.

    • Hi Rob:

      Thanks for posting ,but I had question,that is windows server 2012 hyper-v cluster can access windows server 2008 R2(old cluster) Cluster Shared Volumes ?

    • Will the migration wizard upgrade the csv to the new version 2.0 in Server 2012?

      Thanks.

    • "Thanks for posting ,but I had question,that is windows server 2012 hyper-v cluster can access windows server 2008 R2(old cluster) Cluster Shared Volumes ?"

      Yes. As a FYI, the WSFC 2012 PowerShell cmdlets are down-level compatible so you can use the CSV cmdlets to manage your CSV volumes from your 2012 cluster.

      "Will the migration wizard upgrade the csv to the new version 2.0 in Server 2012?"

      Yes.

    • For:

      Michael Abraham

      27 Aug 2012 1:25 AM

      Thanks for the Post.

      Is there a way to migrate a cluster partially. I. e. you have a 5 nodecluster with fairly new Hardware and only get money for buying 1 additional Node (with even newer Hardware) to start you're new cluster andthen get you're old cluster nodes integrated in the new one?

      Answer:  Yes there is.  You can do this in any combination you want.

      1. evict two of the nodes from the old Cluster.  

      2. Rebuild them from scratch along with the new machine with Server 2012.  

      3. Add Hyper-V and Cluster roles and create a new Cluster to the new ones.  

      4. Run the Cluster Migration Wizard to migrate all the VMs from the old to the new.  

      5. Destroy the old Cluster.

      6. Rebuild the old nodes with Server 2012 and join them to the new Cluster.

    • This is a great article and has helped me greatly with this process. Unfortunately, I am seeing some errors that is preventing me from migrating. I have around 20 VMs on multiple CSVs. After migration, some of the VMs will start on the new cluster just fine, but some fail. The failing VMs all fail the same. Under Cluster Events, I get Event IDs 1069 and 1205. I have looked for these errors and how to mitigate them, with no luck. Anyone have any thoughts?

    • I know this isn't a 'tech support' site, but I thought I would follow up with my last comment in case someone has seen something similar.

      Related to my start failures, I am getting the following errors:

      Source: Hyper-V-VMMS

      Event ID: 16300

      Task Category: None

      Cannot load a virtual machine configuration: The system cannot find the file specified. (0x80070002). (Virtual machine ID <GUID>)

      Fun stuff. Hoping someone out there has some insight.

    • This looks pretty straight forward. Would both of the clustered VMs need to reside on the same Hyper-V host or do you have them spanned across a Hyper-V cluster. I see issues when the VMs are spanned across multiple Hyper-V hosts.

    Page 1 of 3 (39 items) 123