Performing a hypervisor upgrade is rarely easy. There is a lot of work that goes into the planning process. With Windows Server 2012 now publicly available, here are some important points to consider when planning a Hyper-V update.
Understanding licensing changes in a Hyper-V update
One of the first things that you will have to take into account before updating Hyper-V is Microsoft's new licensing model. Microsoft has
More resources on upgrading to Hyper-V 3.0
Quiz: Are you ready for a Hyper-V update?
System Center 2012 SP1 to include Hyper-V 3.0 tools
New Hyper-V 3.0 licensing changes
It is worth noting you cannot upgrade Windows Server 2008 R2 Enterprise Edition to Windows Server 2012 Standard Edition. If you are currently running Windows Server 2008 R2 Enterprise Edition, you have no choice but to upgrade to Windows Server 2012 Datacenter Edition.
In most cases, quite a bit of planning goes into the actual upgrade or migration process. After all, your virtualization hosts are presumably running production VMs and the upgrade needs to create as little downtime as possible.
Organizations are generally discouraged from running standalone virtualization hosts, because if the host server fails, then the VMs will also drop offline. But budget constraints often make non-clustered hosts popular for smaller organizations.
If you currently have standalone Hyper-V servers running Windows Server 2008 R2, then you can perform an in-place upgrade on those servers. My experience has been that the Hyper-V update process is generally smooth, and takes just under an hour to complete. Even so, there are a few things that you need to be aware of.
First, performing an in-place upgrade does cause a period of downtime for VMs on that server. So you'll need to schedule the upgrade for a time that will be minimally disruptive to end users.
If your current Hyper-V deployment is clustered, then the Hyper-V update process will be a lot more challenging, because you cannot perform an in-place upgrade of a cluster node, and expect that node to continue to function as a part of the cluster. Likewise, you cannot join a server running Windows Server 2012 to a Windows Server 2008 R2 failover cluster.
Typically, upgrading a cluster will require that you perform a leapfrog migration, which means you'll need at least a couple of new servers. You can use these servers to build a new cluster running Windows Server 2012. Once the new cluster is in place, you can remove nodes from your existing cluster, upgrade those nodes to Windows Server 2012 and then join them to the new cluster.
The most challenging part of this type of migration is you must determine what to do with your VMs during the migration. Once you complete the migration, you can use the export/import process to move VMs to the new cluster.
Lab testing a Hyper-V update: Better safe than sorry
Even though you have planned a Windows Server 2012 upgrade and migration, there is a lot of room for things to go wrong. It is critically important to have a full backup of all VMs and virtualization hosts.
Regardless of whether you are performing an in-place upgrade or a migration, it is a good idea to rehearse the Hyper-V update in a lab environment before trying it in your production environment. The easiest way to do this is to get your hands on some spare hardware and use your backups to restore your hosts and VMs to that spare hardware. Be sure you create the lab on an isolated network segment. Once the lab is in place, you can perform a mock upgrade without fear of compromising your production environment.
Remember: Upgrading the hypervisor is only part of the job. Once your VMs are running on top of the new hypervisor, you will have to update Microsoft Integration Services on each VM. VMware shops can use VMware Tools, which is the equivalent of Integration Services.
A lot of planning needs to go into a hypervisor upgrade. As you prepare for the upgrade process, make sure you have a plan in place to roll everything back to the way it previously existed.
This was first published in November 2012