Posey's Tips & Tricks
Moving an Old VM to a New Hyper-V Host
So you want to know whether a Hyper-V virtual machine built on a legacy host will be supported by a newer server? There's a PowerShell command for that.
About a year ago, I wrote this column about my workaround for manually installing Hyper-V Integration Services onto an outdated operating system. At the time, I needed to set up a virtual machine (VM) that was running Windows Server 2008 as its guest OS.
However, Windows Server 2016 does not provide an option to manually install Integration Services as previous versions of Hyper-V did. Instead, Microsoft simply assumes that your VM will run a currently supported version of Windows, which installs Integration Services by default.
In the column linked above, I explained how I worked around the Integration Services issue by using an ISO file as a source for deploying Integration Services. Recently, however, I thought of an easier technique.
My idea was to set up an older Hyper-V Server (in a lab environment) and use it to create the VM. Because the VM is running on an older version of Hyper-V, the option to manually install Integration Services still exists. Once Integration Services is installed on the VM, it should be possible to export the VM, then import it onto a production host.
This technique sounds simple enough, but like so many other things in the world of IT, the devil is in the details.
When you create a new VM, Hyper-V assigns the VM a configuration version. This configuration version not only determines the VM's capabilities, it also impacts your ability to import the VM into another host.
So before you go through the trouble of setting up a legacy Hyper-V host, creating a VM, exporting the VM and then trying to import it into a modern Hyper-V host, how can you be sure that the production Hyper-V host will accept a VM that was created on a legacy host?
Making this determination is actually easier than you might think. Let me show you how it works.
If you look at Figure 1, you can see that I have a VM named "Mirage." This particular VM is running on a Windows Server 2012 R2 host and has a configuration version of 5.0. The configuration version is listed near the bottom of the screen.
[Click on image for larger view.] Figure 1: This particular VM has a configuration version of 5.0.
Let's pretend for a moment that I wanted to move this VM off of my old Windows Server 2012 R2 host and onto something a bit newer. How can I be sure that my newer server will accept the old VM?
There is actually a PowerShell command that you can use to determine which Hyper-V VM configuration versions a host will accept. Before I show you the command, there is another very similar command that I want to show you. That command is:
Get-VMHostSupportedVersion -Default
This command will tell you what the host's default configuration version is. For example, I ran this command on a Windows 10 machine and it reported that the default configuration version was 9.0, as shown in Figure 2.
Figure 2: My Windows 10 machine has a default configuration version of 9.0.
So if you want to know if a newer Hyper-V host will be able to accept a Hyper-V VM that is running an older configuration version, here is the command to use:
Get-VMHostSupportedVersion
Upon entering this command, Windows will tell you all of the Hyper-V configuration versions that it can accept. If you look at Figure 3, for example, you can see that my Windows 10 machine should have no trouble accepting my old Windows Server 2012 R2 VM.
Figure 3: This Hyper-V host can accept VMs with configuration versions as old as 5.0.
What options would have existed if my modern Hyper-V host had not been compatible with the older VM? One possibility would have been to raise the VM's configuration version. However, if the VM is already running the highest configuration version that is supported by the host, then you will have to get a little bit creative.
One option might be to deploy an intermediate Hyper-V host that runs a version of Hyper-V that is newer than the one that is currently hosting the VM, but older than what is running in your production environment. You could then move the VM to the intermediate host, raise its configuration version, then migrate the VM to the production host.
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.