Posts Tagged Hyper-V cluster

Hyper-V Server R2 RC failover cluster to Enterprise/full version RTM…

A couple of months ago I wrote about the joys of upgrading your Hyper-V R2 release candidate cluster to a new version (e.g. release code).  This process involved tearing down and destroying your cluster which can be a complete pain on many levels (not just for your users! ;-))

Anyway, on this occasion I’m attempting to upgrade a Hyper-V R2 Release Candidate failover cluster to Enterprise RTM full product without destroying the cluster (although rebuilding the nodes clean – this is a must to be supported).

What this means is that from Beta->RC and from RC->RTM, you will have to do the following:

1. Move workloads onto fewest node/s

2. Move ownership of Storage from the node you are going to remove and rebuild.  You may need to stop the cluster service if th Quorum will not move (it will if you force it by stopping the service ;-))

3. Using ‘Failover Cluster Manager’ drill-down on Nodes, and right-click on the non-primary node, chose More Actions…, Evict – you’ll get a message warning that evicting a node can cause problems if a clustered application requires that node.. obviously! – click ‘Evict node NODENAME’

3.5. Move the node out of the domain back to a workgroup (so we can reuse this name) and delete the computer account from AD

4. When it comes to the last remaining node in the cluster, due to Quorum requirements, you will need to destroy the cluster.  Select the cluster, goto More Actions… select Destroy the Cluster

5. Remove the ‘Failover cluster virtual network name account’ from AD Users & Computers

5. Being slightly paranoid, I also disabled the Failover Clustering service from with Hyper-V Configuration and removed the machine from the domain (back to a workgroup)

3. Wipe/Reload with new version of Hyper-V.

4. Create new 1 Node Cluster, join to SAN etc

5. Move VMs, offline, to new Hyper-V host.

a. Upgrade VM’s IC’s

6. Wipe/Reload remaining host

7. Join it to the cluster

8. Smile, before you do the same for RTM… 😉

 

  1. Configure Clustering
    1. Install the Windows Server Failover Clustering feature
      from a cmd shell “start /w ocsetup FailoverCluster-FullServer”
    2. Configure Shared Storage
      Use iscsicpl.exe, if the service is not started then start it – click ‘Yes’
      Use Quick Connect to connect to the iSCSI Target, click ‘Done’ to list the targets
      Connect to the Quorum target, then add the volume
      Repeat adding the other cluster volumes (VHDs, Data, Logs, etc.)
    3. Add the new node to the Failover Cluster
      Use Failover Cluster Manager to validate the cluster
      Add the node to the cluster even if validation fails (it will if node O/S is different)
    4. Modify Hyper-V Settings for the cluster
      Change the location of VHDs and VMs to:
      C:\ClusterStorage\volume1\hyper-v\
  2. Move virtual machines and correct network errors on the target node
    1. Use Hyper-V VM Settings to correct the network setting if they report a Configuration Error
  3. Start the VM’s on the new node J
  4. Rebuild the next one..  😉

Leave a Comment

Windows Server 2008 R2 & Hyper-V Cluster upgrades or not…

Ahh the joys of participating in beta programs! 😉

 As part of my day job, and as co-founder of IT consulting firm “The Full Circle” www.thefullcirle.com – a Microsoft Gold Partner that likes to keep ahead of the game (or at least stay in it!) by being an early adopter, we are always working with new software and that means building and rebuilding boxes.  Clearly virtualisation can make huge savings, especially in time but not always, especially when working with beta & pre-release software…

Our current journey of discovery is clustering with Windows Server 2008 Release 2 (R2) which is currently in late stages of development (went RC about month ago), and we are delighted to be a UK Early Adopter Program partner! 🙂

We have been working with a couple of different builds, the beta build 7000, and recenly the Release Candidate build 7100.  Our own infrastructure was built using the beta, as is our customer EAP project, and following a number of cluster issues we performed an in-place upgrade to the RC code…

However, last week I learnt that in-place upgrades to clusters are not supported across beta/pre-releases to RC, and eventually to RTM – this is often the case as would never be a mass adopter / real-world scenario.

What this means is that from Beta->RC and from RC->RTM, you will have to do the following:

1. Move workloads onto fewest nodes (1 in my case)

2. Using ‘Failover Cluster Manager’ drill-down on Nodes, and right-click on the non-primary node, chose More Actions…, Evict – you’ll get a message warning that evicting a node can cause problems if a clustered application requires that node.. obviously! – click ‘Evict node NODENAME’

3. When it comes to the last remaining node in the cluster, due to Quorum requirements, you will need to destroy the cluster.  Select the cluster, goto More Actions… select Destroy the Cluster

4. Remove the ‘Failover cluster virtual network name account’ from AD Users & Computers

5. Being slightly paranoid, I also disabled the Failover Clustering service from with Hyper-V Configuration and removed the machine from the domain (back to a workgroup)

3. Wipe/Reload with new version of Hyper-V.

4. Create new 1 Node Cluster, join to SAN etc

5. Move VMs, offline, to new Hyper-V host.

a. Upgrade VM’s IC’s

6. Wipe/Reload remaining host

7. Join it to the cluster

8. Smile, before you do the same for RTM… 😉

Comments (1)