Organizations considering moving from Windows Server 2012 R2 Hyper-V to the next Hyper-V version (presumably Windows...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Server 10 Hyper-V) will need to consider how they will be able to migrate their virtual machines to the new version. The next version of Hyper-V will include a rolling upgrade feature that will allow administrators to upgrade existing Hyper-V cluster nodes one node at a time, without having to take the cluster offline. Even so, administrators will have to consider how the VMs will be moved to the new version of Hyper-V.
Regardless of whether an organization is running a clustered Hyper-V deployment, it will be possible to live migrate a VM from a legacy Hyper-V server to a next-generation Hyper-V server. Best of all, the live migration is not necessarily a permanent operation. The administrator has the option of live migrating the VM back to the legacy Hyper-V server so long as they have not updated the VM's version. Updating the VM's version makes the VM compatible only with the latest Hyper-V version.
As was the case with previous versions of Hyper-V, the host server must be enabled for sending and receiving live migrations of VMs.
To see how this works, take a look at the example below. I have used the Get-VM PowerShell cmdlet to retrieve the version number of a VM running on a Windows Server 2012 R2 Hyper-V Server. As you can see in the figure, the version number is 5.0. The actual PowerShell command that I am using is:
Get-VM <VM name> | Select-Object Name, Version
You can use the Get-VM cmdlet to retrieve a VM's version number.
The live migration process works exactly as it did in Windows Server 2012 R2 Hyper-V. Even a live migration that is initiated from a legacy Hyper-V server can move a VM to a next generation Hyper-V server.
If you look at the next image, you can see the legacy VM after it has been live migrated to the "Windows Server 10" Hyper-V server. More importantly however, you can see that the VM has retained its version number in spite of the fact that it is running on a newer hypervisor than it was created on.
Because the VM has retained its version number, it can be live migrated to a legacy Hyper-V server without any issues. Live migrating to a legacy Hyper-V server only becomes impossible after the VM's version is upgraded to version 6.
This brings up an important point. Earlier I mentioned that the new version of Hyper-V will offer a rolling upgrade feature that allows cluster nodes to be upgraded one by one. If a VM is running on a cluster consisting of new and legacy Hyper-V versions, you will not be able to upgrade the VM version until all of the nodes in the cluster are running the new Hyper-V version.
Of course this raises the question of whether there are any benefits to raising the VM version, especially since a VM's version cannot be downgraded. Upgrading a VM to version 6 enables new Hyper-V features and the new configuration file format. As such, version 5 VMs continue to behave as if they are running on a legacy version of Hyper-V. New features and capabilities are only exposed to VMs that have been upgraded.
Upgrading a VM to version 6 is a simple task. To do so, enter the following command into PowerShell:
Update-VMConfigurationVersion <VM name>
Upon entering this command you will receive a warning message cautioning you that you will not be able to migrate the VM or import it into a host that is running an older version of Hyper-V. You can see what the command looks like in Figure D.
As you can see, it is easy to migrate a VM to a "Windows Server 10" Hyper-V server. The VM can be live migrated back to a legacy Hyper-V server so long as its version is not updated.