Use Cross-Version Live Migration to Upgrade to Windows Server 2012 R2 Hyper-V

Now that you can purchase Windows Server 2012 R2 (WS2012 R2), it’s time to consider how you will upgrade to the newest version of Hyper-V. In this article I will discuss a new strategy for upgrading from WS2012 Hyper-V to WS2012 R2 Hyper-V using a new feature called cross-version live migration.

Cross-Version Live Migration FAQs

With cross-version live migration you can perform a one-way (no return trips) live migration of virtual machines from WS2012 Hyper-V to WS2012 R2 Hyper-V. The frequently asked questions about cross-version live migration are:

  • Can I live migrate from older versions such as Windows Server 2008 R2 Hyper-V to a newer version? Nocross-version live migration works only from WS2012 Hyper-V to WS2012 R2 Hyper-V.
  • Can I move virtual machines back from WS2012 R2 Hyper-V to WS2012 Hyper-V? No – see above answer.

It’s the same answer every time!

Cross-Version Live Migration Options

There are two ways to use cross-version live migration, each of which leverages a features of live migration from WS2012 Hyper-V.

1. SMB Live Migration

You can store virtual machines on WS2012 (or later) file servers, including the scalable and continuously available Scale-Out File Server. Changing the possible owners of a virtual machine is basic Windows administration:

  • Grant a new host/cluster permission to the share and folder.
  • Move the virtual machine from the old host/cluster using cross-version live migration.
  • Remove the old host/cluster from the permissions of the share and folder.

Cross-Version Live Migration

Cross-version live migration with SMB 3.0 storage.

There are two notes with regard to live migration to or from a Hyper-V cluster:

  • Live migration from a Hyper-V cluster: Remove the role of the VM from the cluster before live migration. This does not affect the VM and does not require downtime of any kind.
  • Live migration to a Hyper-V cluster: Live migrate the VM to one of the host cluster’s nodes and the cluster’s storage. Then add the VM as a HA role in the cluster to protect it from host downtime.

Some companies that deployed WS2012 Hyper-V in recent months chose to use SMB 3.0 storage (including SANs that were abstracted by scale-out file servers) for their Hyper-V hosts/clusters, because this option allows a very simple migration to newer hosts with no downtime to service availability. An added benefit of this approach is that there is no need to invest in new storage capacity; the existing investment is retained without expansion because the VM’s files are not being moved – only the ownership of the virtual machines is moved in this process.

2. Shared-Nothing Live Migration

Added to WS2012 Hyper-V, shared- othing live migration allows the movement of a virtual machine (as you expect with live migration) as well as the relocation of the virtual machine’s files. When combined with cross-version live migration you get migration options such as the following.

From WS2012 To WS2012 R2
Non-Clustered WS2012 Hyper-V host Non-Clustered WS2012 R2 Hyper-V host
Non-Clustered WS2012 Hyper-V host WS2012 R2 Hyper-V cluster
WS2012 Hyper-V cluster WS2012 R2 Hyper-V cluster
WS2012 Hyper-V cluster Non-Clustered WS2012 R2 Hyper-V host

The ability to move the virtual machine’s files means that you can use direct-attached storage (DAS) or internal disk in the source and destination non-clustered Hyper-V hosts. You could also introduce new cluster shared volumes (new SANs or SAN LUNs) when moving to a new WS2012 R2 Hyper-V cluster.

Shared-nothing Cross-Version Live Migration

Shared-nothing cross-version live migration.

This option will not be as fast as cross-version live migration with SMB 3.0 storage. The time required depends on several factors, including:

  • The speed of the source storage
  • The size of the virtual machines RAM and files
  • The capability of the live migration network
  • The speed of the destination storage

This means that while there is little human involvement in this zero-downtime migration, it might take some time to move lots of virtual machines from WS2012 Hyper-V to WS2012R2 Hyper-V, and that might be an issue if your older infrastructure is not healthy.


Considering Cross-Version Live Migration

There are reasons not to use cross-version live migration. Consider the following:

  • Project deadline: You need to get VMs onto the new host/storage platform as quickly as possible and there are acceptable windows of downtime to accomplish this. Some out-of-band options can be completed more quickly than live migration, especially shared-nothing live migration, which must copy and synchronize the files of running VMs.
  • Small business host capacity: Small businesses with non-clustered host(s) may not be able to afford a new host just to have a zero downtime migration to WS2012 R2 Hyper-V. There may be no choice but to perform a host upgrade.

Those who are considering the following will like cross-version live migration:

  • Service-oriented IT: Upgrades are usually bad for service level agreements. Being able to introduce new infrastructure with zero downtime to services (VMs) availability is important to these organizations.
  • New hardware: Servers, networking, and storage have to be replaced every once in a while. Using cross-version live migration will make this possible.
  • Redesign: Most organizations were new to Hyper-V when they last deployed it. They may have learned lessons from that deployment or want to take advantage of new storage/networking features in WS2012 R2. They can build and test a new infrastructure and then use cross-version live migration to move their VMs onto this new platform.

There Will Be Downtime

Cross-version live migration makes it possible to move your VMs onto WS2012 R2 Hyper-V with no downtime, but your upgrade project is not complete. There are still two steps to perform – one of which is very important and should be done, and the other which should be considered.

  • Upgrade the Hyper-V integration components: The drivers and services that make a guest OS function efficiently and make it possible to use new features must be updated. This will require a reboot of each VM, but you can do this during a maintenance window.
  • Upgrade the guest OS: This one is optional. Assuming you have the required Windows Server 2012 Client Access Licenses (WS2012 CALs are sufficient for WS2012 R2), you can choose to upgrade your guest OS installations to avail of the latest features.