I recently had a customer with a 2008 Hyper-V Cluster, who was wanting to start from scratch with a 2012 Hyper-V Cluster. The problem was that the 2008 Cluster was a mess, the networking was all over the shop, and the storage was coming from 4 different Storage Arrays. It had all been built in a blade infrastructure on 2008 Core and grown from the ideas of 3 separate admins who were all long gone and had left no documentation. Yes we might have been able to migrate it, but the underlying infrastructure would have continued to cause problems.
As the IT Manager said, “I can’t do anything any time I make a change it breaks something else”, since we were there to install a new SAN the decision was made to create a new & fresh 2012 Cluster using the new SAN and only bring over the VM’s that were actually needed and being used. We built the new 2012 Hyper-V cluster which worked like a charm.
Now we had the problem of migrating the VM’s with minimal downtime to the new cluster, some of the options were:
1. Do an export of the VM and then copy it to the new cluster and import it. This would have meant a lot of downtime.
2. Use Hyper-V manager to move the VM config files, fine but we would still have to move the data, more downtime.
I then started to think about Veeam, initialy I thought we could use the free Live Migration Utility, but soon realised this was only supported on VMware, then it hit me, why not replicated the VM’s from the 2008 Hyper-V Cluster to the new 2012 Hyper-V Cluster.
As a test we installed Veeam onto a local PC, got a free 30 day license from Veeam, setup the replication job, pretty much went with the defaults except didn’t get it to add an extension to the replica VM name such as _replica, and it worked. The copy job was fast because it was directly between the nodes of the clusters, and Veeam also compressed the data over the wire.
The process was to replicated the VM overnight, and then on the day we actually wanted to move the VM, we would do another replication, that was only the changes so pretty quick. Shut down the source, do another replication, and you had an exact replica of the VM on the new cluster.
A couple of changes we had to do the VM before starting it up, included attaching it to the right Virtual Network, we also noticed that after we had added the VM to the cluster as highly available, if you tried to migrate it failed because it didn’t have Smart Paging setup, a new feature of 2012, but all we had to do was edit the VM to put in the details.
Doing the migration this way meant downtime was less than 10mins per VM and much of the work could be done during normal hours with little disruption, one happy customer, who then went on to buy Veeam, so everyone is a winner.
I hope this helps someone as all the migration info I could find was around using the same storage, and hopefully this flash of inspiration will help.