This post is from my good friend Niall Jennings. One of the most technical guys I know, he currently lives and works in Dublin, Ireland. I invited him to post on this site whenever he likes, the more knowledge sharing in the IT community the better I think and so he’s done all the hard work here, all I have done is provide the platform. So thanks a lot to Niall for sharing, I bet this helps a lot of people out there.
Backstory: In the medium term my company planned to build a Windows Server 2012 Hyper-V farm from which to offer cloud services to our customers. In the meantime we were using a 3rd party provider for our hypervisor infrastructure. Due to various incidents it was then decided to fast forward the build our won Hyper-V farm using Windows Server 2008 R2 on our own kit. Now that Server 2012 has appeared we are looking toward easily upgrading our hypervisor hosts and farm to Hyper-V 2012.
I was given the task to test how easy it would be to move the virtual servers from a 2008 Hyper-V Failover cluster to a 2012 Hyper-V failover cluster.
We have an N+1 cluster so evicting a host from the 2008 cluster and building it as the beginning of a new 2012 HyperV server cluster will be fairly straight forward. (I have already built and tested a Server 2012 HyperV failover cluster)
The issue arises when attempting to move VMs from one cluster to the other. Moving large volumes of vhd files could be potentially time consuming and it would be nice to preserve the existing Cluster Shared Volumes that already exist.
Below is my humble contribution to the knowledgebase on Server 2008 to Server 2012 migrations. It is actually an amalgamation of two really useful blog posts. (Hats off to both gentlemen)
The first by Ruan Kotze was a procedure for moving a 2008 Hyper-V cluster to a new AD Domain (https://namitguy.blogspot.ie/2012/03/moving-hyper-v-cluster-to-new-ad-domain.html)
The steps laid out by Ruan are the steps I followed in the lab except for the obvious fact that I was wiping and reinstalling Server 2012 on each of the servers being evicted from the cluster rather than re-adding them to a new cluster.
This left me in a bit of a bind as to moving the VMs to the new hypervisor; a conventional export moves VHDs and the lot making it a time and space consuming exercise.
Here is where Ben Armstrong and his vb scripts came to the rescue (https://blogs.msdn.com/b/virtual_pc_guy/archive/2010/03/24/performing-a-configuration-only-export-import-on-hyper-v.aspx)
The first thing you need to understand about me is that the only thing I lack more than wit and charm is script writing ability. Blame childhood dyslexia, maybe blame the constant presence of google during my formative years in IT (like the friend that always gave the answers to you in a stage whisper in school that ended up doing you more harm than good). I just can’t write a decent script so resources like Ben are to be treasured and given kudos at every opportunity.
As the title of the article would suggest Ben kindly provided a configuration only export and import script that allows a person to export the VM settings without having to copy and duplicate the vhd files.
A combination of both procedures allowed me to first export the VM config and then move the relevant cluster shared volume to its new home on the HyperV 2012 cluster. I was then able to reimport the VM successfully and make it highly available in its new home.
Steps as Follows:
To avoid affecting existing servers I began the test by creating a new TestMigration volume and making it available as a CSV in the 2008 failover cluster. I then created a number of test boxes to try it out on as below.
I then kicked off the Export script
As directed I entered the name of the HyperV host
I then provided the name of the VM to be exported
Finally I provided the directory where the Export data could be copied. For ease of migration I placed it in a directory on the MigrationTest CSV
Progress dialogue boxes below:
And finally export of VM without the VHD. Success!
Next step is to delete VMs that have been exported from the failover cluster manager
Once the configuration for all your VMs on the Cluster have had their configuration exported it is now time to take the CSV containing them offline and then remove it from Cluster Shared Volumes (To do it in this order is very important or things may get a little funny!) You can do both by right clicking on the volume in question
Then move to the Storage option, take the volume offline and delete it from the Failover Cluster Manager
You can then safely disconnect the volume from the Hyper-V host iSCSI initiators
You can then reconnect the same volume on the Server 2012 iSCSI initiator
Bring Disk online in the Computer Manager (do not initialise it!, if it asks to initialise you have done something wrong and probably wiped all data on the volume)
Next step is to add the disk to the 2012 failover cluster
Step 2 of the process
In the interest of keeping things identical I then renamed the volume to what it had been called in the 2008 failover cluster
The volume then needs to be added the Cluster Shared Volumes
Change the volume name in the ClusterStorage folder to its original name (in this case Volume2 to MigrationTest)
You will need to browse to the Cluster storage location and rename the volume here also. Then double check data is available as it was on the original host boxes
Now that the scary part is over my scripting ability or lack thereof let me down once again. As the WMI objects called in Ben’s scripts don’t seem to work on Server 2012 I had to do a manual import of the VM (outlined below) This is fine in a testing environment but I can imagine would get pretty tiresome in a production environment with 150+ virtual machines.
While a manual import is pretty straight forward and self-explanatory I will outline it below for completeness.
It would be great if one of you fine people could point me in the direction of a blog that deals with scripts for the mass import of configuration only VMs (with their VHDs stored in a standard path) on a Server 2012 HyperV host
Importing the Configuration Only VM manually:
This is achieved as before by right clicking on the host in the Virtual Machine Manager and clicking on Import Virtual Machine
Click on Next
Now point to the folder where the VM configuration data has been exported to
Accept the relevant VM in the list below
There is a nice explanation of the options below in this article https://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/68aa2cbc-3386-44f5-aa87-b53c395d4b6c/
I followed the VMware School of thought on moving VMs, when in doubt say you copied it.
I then entered the standard folder path we use in our environment which goes C:\ClusterStorage\<VolumeName>\<VM name>
Next step was to point at the original VHDs as below
As before just point it at the location where the VHDs already exist.
Finally have a quick read of the summary to make sure all is in order
And happy days after a couple of seconds your VM will appear ready in the Server 2012 Hyper V manager.
Assuming your virtual switches have been named the same and the file paths are identical to the previous host your VM should import with all the settings it had previously with minimal wait time for the VHDs to copy
The next step is to make the VM highly available (again this has not changed drastically since 2008)
Choose Virtual Machine
Tick the relevant boxes
Wait for it to do its thing
All going well you will see the dialogue below:
Server Running Successfully in the Failover cluster manager. Sweet success!
Thank you all for reading; I hope it was informative to those considering a similar migration. I realise the need to move all the VMs on a particular volume at once makes this a somewhat flawed process but it’s the best I have come up with on short notice. Also the lack of mass automation on the import and export is a bit of a fail on my part also
I would be really interested to get some feedback and ideas on better ways of doing it especially in terms of automating the process
Thanks to Rory as well for allowing me to hijack his blog briefly. I don’t know if I am ready for my own blog just yet.