Posey's Tips & Tricks
How To Refresh Hyper-V Hardware, Part 1: Get Your Versions Straight
The first half of Brien's project to replace his outdated Hyper-V servers took nearly 10 days and multiple replication failures. Here's what went wrong and how he fixed it.
In a recent column, "A Better Way To Upgrade Hyper-V Storage," I mentioned that I was preparing to do a hardware refresh on my badly outdated Hyper-V servers. Although I ran into a few surprises along the way, the hardware refresh is now done and my new systems seem to be working perfectly.
Because so much effort went into this particular refresh, I thought that I would take the opportunity to share some of the lessons that I learned along the way.
Cross-Version Hyper-V Replication
My previous production environment consisted of two Hyper-V hosts and one production virtual machine (VM). I ran the VM on one of the hosts and replicated it to the other host by way of the Hyper-V replication feature.
Because I was performing a hardware refresh, my goal was to replace both hosts and to also attach some new storage to the hosts. I began the refresh by installing Hyper-V and any available updates onto the new hosts. Once my new hosts were fully provisioned and ready for use, I turned off VM replication within my existing environment, then physically removed the server that had been hosting the VM replica. I replaced this server with one of the new Hyper-V servers, then reconfigured Hyper-V replication. My intent was to replicate my production VM from the remaining Hyper-V server to the new server.
Unfortunately, that process did not go quite as smoothly as I had expected. The VM I was trying to replicate is a file server and contains many terabytes of data. At that time, replication was occurring across a gigabit Ethernet connection (more on this connection later on). Needless to say, the replication process was slow, and it took days to replicate all of the data to the new server. The replication engine replicated 98 percent of the data, then gave me a message stating that replication had failed. Even though 98 percent of the data had already been replicated, Hyper-V restarted the replication process from the very beginning.
After a few more days of waiting for the replication process to complete, replication failed in exactly the same way as it had before. I decided to give the replication engine one more chance. Nearly 10 days into the replication process, the initial seeding failed again.
Although I could not find any documentation to support my theory, my best guess as to why replication was failing was because the host running the VM was running the Windows Server 2012 R2 version of Hyper-V, while the new host was running the Windows Server 2016 version. I also wondered in the back of my mind if differences between the CPUs could be causing the replication failure. My old server was running Hyper-V on an outdated AMD processor, while my new server is equipped with a much newer Intel Xeon processor.
Since a difference in Hyper-V versions seemed the most likely cause of the problem, I upgraded my old host to run the Windows Server 2016 version of Hyper-V. This upgrade brought its own set of challenges.
The first of these challenges was that Windows had been configured to use NIC teaming. However, the Windows Server 2016 setup program requires you to disable NIC teaming before it will allow an upgrade. This meant that I had to break the existing NIC team, create a brand-new Hyper-V virtual switch, configure my VM to use that virtual switch and fix the host's IP address assignment.
The other challenge I ran into was related to the host's memory. That particular machine was equipped with 16GB of RAM. I had configured my VM to use 12GB of memory, leaving 4GB for the host operating system. If these amounts seem a bit inadequate, keep in mind that I work out of my home and, most of the time, I am the only one using the system.
Following the upgrade to Windows Server 2016, I was unable to start my VM because the host was unable to allocate 12GB of memory to it. I reduced the VM's memory requirements to 8GB and was then able to start the VM. Later, once the entire project was complete, I allocated more memory to the VM.
Now that both my old host and my new host were running the same version of Hyper-V, I once again set up VM replication. This time, the replication process completed as expected.
At that point, half of my hardware refresh was complete. I will tell you about the other half in Part 2 here.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.