This applies to Server 2012 and newer, but these directions are from when I moved VMs from a 2012 cluster to a 2012 R2 cluster.
- On the new cluster, right-click on the cluster and choose More Actions -> Copy Cluster Roles
- Choose the roles to copy, and then complete the wizard. This will set up the roles and their dependencies on the destination cluster.
- Shut down the VMs on the source cluster
- Take the relevant storage offline in Failover Cluster Manager (FCM)
- Disconnect the iSCSI volumes on all source cluster nodes
- Re-assign the LUNs to the new cluster nodes in your SAN of choice’s management console
- Connect the LUNs on the destination cluster nodes, but leave the disks offline in disk management
- In FCM, go to storage and bring the copied disks online. You should see the volume details reflected in the bottom details pane if all is successful.
- Start the VMs
Today I had to troubleshoot an issue on our 2012 (non-R2) cluster that was causing live migration to fail. Quick migration wasn’t affected.
The error I was receiving was:
Cluster network name resource 'Cluster Name' failed registration of one or more associated DNS name(s) for the following reason: DNS bad key.
I tried all of the suggestions on the various KB articles and blog posts, but none of them would help. A lot of them were related to externally-hosted DNS, but our DNS is a normal AD-integrated zone hosted internally. I tried removing the cluster node object’s DNS A record, and forcing a repair:
(By the way, just confirming that taking the Cluster Name resource offline doesn’t affect the Hyper-V workloads running on the cluster)
The repair recreated the CNO A-record with the correct permissions assigned to the cluster’s AD computer account. This still didn’t help.
I then edited the permissions on the CNO’s DNS A-record to allow the individual cluster nodes’ computer accounts write access, and the problem went away.
I’ll be the first to admit that this is an annoying solution as I’m going to have to add the permissions for new cluster nodes as they’re added to the cluster in the future. That said, I think I’m going to build a new 2012 R2 cluster on the other two blades, move the workloads across, and then rebuild these nodes as well.
Had an issue on some new Server 2012 Hyper-V clustered hosts. Started seeing the following error in the logs:
Cluster Shared Volume 'SERVERNAME' ('') has identified one or more active filter drivers on this device stack that could interfere with CSV operations. I/O access will be redirected to the storage device over the network through another Cluster node. This may result in degraded performance. Please contact the filter driver vendor to verify interoperability with Cluster Shared Volumes.
Active filter drivers found:
Yes, those are random characters in the error message, so it’s difficult to track down the filter driver in question.
This seems to match the same issue in Server 2008 R2 – Redirected mode is enabled unexpectedly in a Cluster Shared Volume when you are running a third-party application in a Windows Server 2008 R2-based cluster
In the Microsoft KB notes, they state one of the conditions as being:
- The third-party application has a mini-filter driver that uses an altitude value to determine the load order of the mini-filter driver.
- The altitude value contains a decimal point.
Running fltmc.exe on these hosts shows the following filter drivers loaded:
The filter driver with the decimal point is stcvsm, the “StorageCraft Volume Snapshot Driver” The problem has only been occurring recently, after I installed ShadowProtect.
I’ve had to uninstall ShadowProtect from these servers until it’s officially supported on Server 2012. According to StorageCraft, that should be 90 days after the official launch date of Server 2012. That means there should be a new version of ShadowProtect around the 3rd of December 2012.