Monthly archives for August, 2009

Our research HP c3000 Blade Enclosure at Nobel, sometimes referred to as Shorty, has been running several builds of Hyper-V clusters. Last summer we started with installing our first Hyper-V (now referred to as R1) cluster which went RTM at the end of June 2008.

Just after TechEd 2008 in November that year, a fresh beta appeared and I was quick enough to reinstall the server blades with the beta, which was still called Windows 7 Server at the time. In this build Cluster Shared Volumes (CSV) could not yet be enabled through the Failover Cluster Manager GUI. There was a new PowerShell 2.0 command to load the FailoverCluster module and to enable CSV at the PS prompt.

About six months later, in May 2009, Microsoft made a release candidate available of the newly named Windows Server 2008 R2 with Hyper-V R2. I attempted an in-place upgrade which did not go all too well. The probable cause was a slight change in the implementation of CSV in the new build. Therefore it was necessary to recreate the cluster after first getting rid of the old one. I still didn’t feel like a complete reinstall yet.

Evict all cluster nodes except the last one
PS> Remove-ClusterNode [nodename] -force

If for some reason you are unable to recreate the cluster the following line at an ordinary command prompt will do:cluster node [nodename] /forcecleanup will certainly do the job.

Very stable early buildsNot once in the beta or the release candidate have I found any problems or even a small glitch of instability. The hypervisor not only seemed rock solid, it plainly was bloody rock solid!

Only two more months passed by before the final release appeared of Windows Server 2008 R2 and Hyper-V R2. Looking at the date of the files of R2 it was July 14th 2009 when the code was finalized. It was the second day of the Worldwide Partner Conference (WPC09) when Bob Muglia hinted at the RTM of R2 in next few days, but did not officially release it as MS had done with Windows 7 on the previous day. Eight days later on July 22nd Windows Server 2008 R2 was formally released to manufacturing and on August 14th we were able to really get our hands on it. Even though there was such a short time between the first beta and RTM, it seemed like ages. We wanted to get projects started with the final version of Hyper-V R2 and finally there it was.

Another migration of our research cluster was imminent. This time I studied all possible scenarios. A rolling upgrade of the cluster seemed an attractive method, knowing that in-place had failed with the previous attempt. I joined the MVP cluster team meeting and we discussed the migration scenario’s in detail. It became clear that an in-place upgrade of Hyper-V R1 to R2 will only be supported on a non-clustered Hyper-V server, after taking every possible precautions such as deleting snapshots, stopping all VM’s, taking backups of the VHD’s and updating Hyper-V integrations after migration. The verdict was no in-place or rolling upgrades of Windows clusters to Windows Server 2008 R2 clusters, period. So what is the preferred method for upgrading to Hyper-V R2. Because our research cluster already was an Hyper-V R2 release candidate, I could not verify if migrating from Windows Server 2008 would be any different. Except for CSV, I suspect all steps will be identical.

Some of the following steps use the Hyper-V PowerShell Management Library: http://pshyperv.codeplex.com/
Copy hyperv.ps1 to a directory on the hyper-v server and be careful to type the exact command:

. [space] .hyperv.ps1

All VM Functions are now loaded.

Let’s assume a 2-node Hyper-V R1 cluster (which will be the majority of implementations):

Be careful with spelling (case sensitive) the name of the virtual network because the name of all virtual networks in the cluster must be identical

Run Validate This Cluster from the Action Menu and fix all issues that might arise

Create new cluster using a new clustername and IP

Configure all networks

NIC1-DOMAIN

NIC2-VM

NIC3-MIGRATION

NIC4-ISCSI

Add new shared disks, bring them online, initiate them and give them a meaningful volume name

Give node 2 access to the newly created shared disks

Enable Cluster Shared Volumes from Failover Cluster Manager

Add those disks to the cluster from Failover Cluster Manager

Rename the cluster disk name to the same name as the volume name (to avoid getting lost)

You now have two single-node clusters, one with Hyper-V R1 and one with Hyper-V R2

Because you have two separate clusters you cannot migrate VM’s from one cluster to the other. I would advise you not to reattach existing cluster disks from cluster 1 to cluster 2. This might cause havoc. Take the extra step to create one or two fairly large LUN for Cluster (let’s say 300 to 500GB or the size required for about 10 VM’s). These two CSV volumes will be the target for the VM’s, which in Hyper-V R1 were all on their own LUNs.

I strongly advise you to use System Center Virtual Machine Manager 2008 R2 (still a release candidate at the time of writing, but perfect for the job) and perform a storage migration for all VM’s from the old cluster to the new R2 cluster

Use VMM2008R2 by any means!

Add old cluster to VMM2008R2 if it not already there. If you don’t have VMM2008 R2, download it from the Microsoft Connect site and install it on a server

Add new cluster to VMM2008R2

Refresh clusters and make sure cluster is ready to accept VM’s (you might have to ease remove the cluster reserve or overcommit status in VMM2008R2

Check you can see all VM’s in cluster 1 and check the CSV’s are available on cluster 2

Now it becomes really simple ….. Just drag and drop 1 or 2 VM’s at a time from cluster 1 to cluster 2.

It is really that easy!

I moved a few VM’s by using the online mode and a few in the offline mode. I would probably prefer the offline version because the VM’s are already offline on node 1 and it doesn’t use any snapshotting techniques as is done in the online mode. The offline mode will probably be a little faster.

I did the VM move during a meeting at the office and I could see my colleagues smile while their test VM’s were moved under their eyes. It is unreal to see your VM’s move at top speed between two clusters.

The good thing is that you don’t have to recreate any VM configurations and if your VM was in a folder, that folder is completely moved and everything is taken care of.

The final step is to destroy cluster 1 and cluster node [node name] /forcecleanup

Remove access to the disks, take the LUNs offline and keep them for a short while until you are sure the migration is successful