Migrating a Hyper-V Cluster to Windows Server 2012 R2
I know that migrating a Windows cluster is not an easy job and an in-place upgrade is not possible in the Windows world, not right now anyway. The hard part is where you need to request a maintenance widow from the service owners because production is going to be affected. VMs will need to be shut down and also the nodes in the cluster. Sorry I can’t help you with that, but I can help you do the migration as easy as it can be. Before starting, you need to decide how you want to migrate:
Are you migrating using new servers and new storage?
Are you migrating using the same servers and the same storage?
Are you migrating using new servers and the same storage?
As you can see there are a lot of options involved and I will treat all of them in this article so they can fit in most of the environments out there since every one of them is different. But whatever option you choose, one thing is certain; you need to check if your hardware is compatible with Windows Server 2012 R2. If it’s not, do not continue. First, because you might have hardware problems, and second, Microsoft will hung up when you call for support.
Now you might think, why the big noise about migrating a Windows cluster? All I have to do is put in the Windows 2012 R2 DVD in the drive and do an in-place upgrade of the hosts one by one. As I mentioned in the begging, this path is not supported and by trying you will get the bellow error message:
Setup has determined that this computer is a member of a Failover Cluster which cannot directly upgraded. In order to complete this operation it is recommended that you evict this node from the Failover Cluster and perform a clean installation. See http://go.microsoft.com/fwlink/?LinkID=178962 for more information.
You might also think, why not add a 2012 R2 host in the existing cluster, migrate the VMs and then install from scratch or upgrade the OS on the rest of the hosts? Because this will not work either, and you can tell that by the error message that is displayed in the Validate a Configuration Wizard:
The servers do not all have the same service pack level.
Translating the error message it actually means that you need to have the same version of the OS in order to build or to join a cluster. You can’t mix versions; not even Windows 2012 with 2012 R2. The only way to make this work is to build a new cluster (Hyper-V 2012 R2 cluster in this case) from scratch by using either new hardware or the existing one and migrate the VMs or the storage.
Migrating using new servers and new storage
If you are one of the lucky ones and got new servers and new storage, the migration will be very easy. In case you have System Center Virtual Machine Manager (VMM), make sure you upgrade this first. The next step is to connect the hardware together, install Windows Server 2012 R2 on the new servers then create a new Hyper-V cluster. On this new cluster create the networks exactly like in the old one, provision the storage (create LUNs), patch it, and once you’re done and you verified everything is working smoothly you will need a maintenance window so you can export the VMs from the old cluster and import them on the new one.
If you are migrating from Windows 2008/R2 DO NOT export the VMs using the Hyper-V Manager Console or you will have an error when importing them on the 2012 R2 cluster:
Hyper-V did not find virtual machines to import from location: “your VMs location”.
It happens because Microsoft deprecated the WMI v1 namespace in Window 2012 and then removed it in 2012 R2. This is a known issue and you can read all about it in this Microsoft Technet article. To be able to import the VMs on the new Hyper-V 2012 R2 cluster, just copy them from the CSV volumes and paste them in the new location.
For the copy operation to succeed the Hyper-V Virtual Machine Management service needs to be stopped on the old Hyper-V hosts so the VM files get unlocked.
When importing the VMs make sure you select Register the virtual machine in-place (use the existing unique ID).
Everything after this point is just monitoring the machines; if they are blue screening (in Windows guests case), rebooting, freezing and all kinds of weird errors. If in a few weeks everything is running normally you can go ahead and decommission the old cluster.
Migrating using the same servers and the same storage
If you don’t get new hardware because the existing one is still in warranty and supports Windows 2012 R2, the migration path will be a little bit different and must be performed with more caution. When the same servers and the same storage are used, the migration begins by evicting one or two nodes from the existing cluster and build a new Hyper-V 2012 R2 cluster using the evicted node(s). In case you have just two nodes in the cluster, evict one of them and build the Hyper-V 2012 R2 cluster with just one node.
From the Failover Cluster Manager right-click one of the nodes and choose More Actions > Evict. When you do this the VMs will automatically start migrating to other hosts in the cluster even tough, I will recommend you manually live migrate the VMs then evict the node. This way you avoid a downtime for those VMs.
[important]Make sure you have enough resources in the cluster before evicting a node in order to support the load.[/important]
Once the node was evicted, start from scratch by installing Windows Server 2012 R2 on the host then create a one node Hyper-V cluster.
You will see some warnings on the Validate a Configuration Wizard about the storage, network and other stuff but don’t worry about those right now, we’ll take care of them in just a moment. Click Finish and continue to build the cluster
and when you’re done with that start configuring the networks as in the old one.
Now that the Hyper-V 2012 R2 cluster is built and networks are configured and working, the next step will be to copy the cluster roles from the old cluster. This will copy all the VMs, CSVs and the Replication Broker (if present) configurations; meaning you don’t have to create them manually from scratch on the new cluster. The wizard will not move the actual data (VMs and storage) it will only copy the cluster configuration.
Still in the Failover Cluster Management console, right-click the cluster name and choose More Actions > Copy Cluster Roles.
Click Next to skip the Before You Begin screen and on the second page of the wizard hit the Browse button and select the old cluster name from the list. Click OK and Next to continue the wizard.
On this page select all the cluster roles you want to migrate then click Next. As you can see it reads all the VMs and CSVs from the old cluster and gives us the option to copy their configurations.
On the Confirmation screen click Next to start and copy the cluster roles.
After everything is copied click Finish to close the wizard.
Now if you take a look in the Roles and Disks section of the Failover Cluster Manager console you should see a replica of what you have in the old cluster. Don’t try to start anything because it won’t work anyway. As I’ve said, the wizard does not move the actual data.
This is the part where you need that downtime because the storage needs to be moved to the new cluster nodes and the old servers wiped-out. Also, the VMs will be shut down and the LUNs unmasked from the old cluster nodes and mapped to the new ones.
[warning]Do NOT map the LUNs to both clusters because data will get corrupted. Windows cluster does not support exposing the same LUN(s) to multiple clusters.[/warning]
Once the VMs and the nodes are in an off state proceed with the LUNs unmasking then with a fresh installation of Windows 2012 R2 on the servers. I will simulate the storage using the Windows 2012 iSCSI Target server since a SAN is out of question in my lab. If your hosts are connected to a SAN via a fiber channel controller, you will have to read the documentation for the SAN storage to find out how to unmask your LUNs.
Open Server Manager on your iSCSI Target host, click the File and Storage Services menu from the left hand side, then iSCSI. On the iSCSI Targets section select the target that maps to your old cluster nodes. Right-click it and choose Properties.
On the target Properties page click the Initiators menu then select all the initiators IDs from the list. Click Remove. These were the initiators from the nodes in the old cluster.
Do not close this window yet because the 2012 R2 nodes need to added in this list. For this I presume you already have them installed and the iSCSI Initiator service is running on them. Click the Add button. On the Add initiator ID page hit Browse and type the name of the second 2012 R2 host that will join the new cluster. Click OK twice then repeat the operation for the rest of the hosts, if any.
When you’re done adding the initiators, click OK to save the changes.
Now its time to make the storage available on the servers. Log in on the hosts and launch the iSCSI Initiator GUI. On the Targets tab type the FQDN or IP address of your iSCSI Target server, which in my case is a Windows 2012 R2 box then click Quick Connect and Done on the window that pops-up.
The Initiator should now have the target in a connected state status.
If you open Disk Management the disks (LUNs) should be listed there but in an offline state, which is OK. Connect the LUNs to the rest of the servers, but do not put them online or initialize them. That will be taken care of by the cluster service.
Now that all servers “see the storage” it’s time to add them as additional nodes in the new cluster. I’m presuming here that you already installed the Hyper-V role and the Failover Cluster feature on them, if not, go ahead and do it. Once you took care of that, open the Failover Cluster Manager console, right-click the Nodes node and choose Add Node.
In the wizard that pops-up hit the Browse button and add your servers.
During the validation wizard you might get some warnings about the quorum drive. Just continue, we will deal with it later. If you have other warnings or errors beside the quorum drive ones, you should solve them before continuing.
After a few seconds the nodes should look healthy and online.
Up until now, we’ve shut down an old cluster that was running on Windows Server 2008 R2 and used it’s nodes to build a new one, running on server 2012 R2. During this process we’ve also transferred the old cluster roles to the new cluster and configured the storage. All that is left now is to put the storage online and start the VMs to resume production.
For that, open the Failover Cluster Manager console and click on Disks. On the right hand side you should see the disks that were imported during the Copy Cluster Roles wizard. Select all of them, do a right-lick and choose Bring Online.
In a few seconds the disks should have an online status with a green arrow pointing up.
Before powering on the VMs let’s not forget about the quorum drive. To set it up, right-click the cluster name and choose More Actions > Configure Cluster Quorum Settings.
[important]Just as a tip here. I doesn’t hurt to format the quroum drive since it has data from the old cluster. If you don’t do it, it’s no harm, but I usually format this disk because I like to start clean.[/important]
Follow the wizard and select the disk from the available storage.
Now its time to power on the VMs and the services that are running on them. This is done from the Roles node.
The last step is to do some cleaning in AD, and that is to delete the old hosts records and the old cluster object.
The Hyper-V cluster is now migrated to Windows 2012 R2 along with the VMs. Do a maintenance check, and closely monitor everything for a few weeks.
Migrating using new servers and same storage
If you are going this way, is just a mix of what I talked about until now. On the new servers install Windows Server 2012 R2 then create a new Hyper-V cluster (no storage). Migrate the cluster roles using the Migrate Cluster Roles wizard, shut down the old cluster and unmask the storage then map it to the new cluster nodes. Using the Failover Cluster Manager console put the disks online and configure the quroum drive for the cluster if you are using one. The last steps are to power on the VMs and clean up Active Directory.
Upgrading a Windows cluster is not a difficult process, but it could be easier. Microsoft still has some work to do on this one, and I think most of the administrators will be thrilled when they can just pop-in the DVD and do an in-place upgrade of a cluster. That way the upgrade will take less time and and will have zero downtime for the business; but until then we are stuck with this.
Want content like this delivered right to your
4 thoughts on “Migrating a Hyper-V Cluster to Windows Server 2012 R2”
I have Q ??? about ((Migrating using new servers and new storage)) as same Scenario you mentioned
migrating from Windows 2008/R2 Hyper-v cluster to 2012 R2 Hyper-v cluster
I have 3 nodes in 2008 r2 hyper-v cluster and I need to move to 2012 r2 hyper-v cluster
How can I copy them from the CSV volumes and paste them in the new CSV volumes location?, and Upgrading a HyperV Cluster to 2012 R2 For the copy operation to succeed the Hyper-V Virtual Machine Management service needs to be stopped on the old Hyper-V hosts so the VM files get unlocked.
without Evict Node first and if I Evict the node the VM’s need to bee move to others nodes ((how can I make a copy and stop services without downtime in the old cluster ))
can you give me a Scenario
You can add the new storage and new servers to the existing environment and migrate using VMM. If you don’t have VMM you can replicate the VMs, power off original and power on replica.
In order to give you better advice I need to see your environment first.
Why do you say to not map the LUNs to both clusters, when that is what MS itself is apparently saying to do?
“Before you run the wizard, you must ensure that the new Windows Server 2012 R2 cluster is configured and is connected to the same logical unit numbers (LUNs) storage as the old Hyper-V cluster.”
It says to connect the new cluster to the old LUN’s, but those LUN’s need to be un-mapped from the old cluster. It just doesn’t work having a LUN across tow cluster, not in the Microsoft world and not right now anyway.