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.. 

Its all great news of course, but the important bit for us (www.thefullcircle.com), are the changes to Hyper-V, dubbed Hyper-V v2.

This is a major version upgrade to the product, indeed Microsoft is so confident in the robustness of Hyper-V 2.0 that it placed the public www.microsoft.com site on it! (already the whole of the TechNet site had been running on Hyper-V v1 since early 2008).

One of the most important inclusions in Hyper-V 2.0 is Live Migration. Live Migration allows you to move a virtual machine from one physical host to another with no down time, or at least good enough so the users, or even the network stack doesn’t see it!
While the existing release of Hyper-V supported quick migration, there were a few seconds of downtime associated with the move; that has been removed.

Another unheralded feature of Hyper-V 2.0 is Cluster Shared Volumes (CSV). Essentially, if you tried to set up a cluster using Hyper-V virtual machines in the original release, for each virtual hard drive (VHD) you had to carve out a LUN on your SAN where that VHD could reside.

Using Cluster Shared Volumes allows you to place multiple VHDs on a single LUN, while the VMs themselves still act as if each VHD is on its own LUN. All CSV volumes are stored in the ClusterStorage root directory, so navigating the different volumes is as simply as using Explorer.

Hyper-V 2.0 also supports up to 64 logical processors on the host computer and includes the ability to add to a running virtual machine (and remove them) without needing to reboot the OS on that VM. You can also dynamically allocate memory without any interruption of service. Finally, the processor compatibility feature allows live migration across different CPU versions within the same processor family (for example, Intel-to-Intel and AMD-to-AMD), but not across processor vendors (same with VMware).

Hyper-V v2.0 is what Microsoft shops (and maybe even some VMware shops!) have been waiting for.
Hyper-V now offers feature parity with VMware’s enterprise solutions in some scenarios, and in others surpasses it (see how long merging a large snapshot on VMware takes.. )