There many reasons why an organization might choose to switch to a different hypervisor. The new hypervisor might offer better functionality or a more attractive licensing model, but whatever the reason, migrating is rarely a simple matter. There are several important questions to consider before you begin the transition process and make a hypervisor switch.
Do you have a coexistence strategy?
One of the first considerations is your coexistence strategy. Do you plan to purchase new hardware, or will you reuse existing hardware? If you plan to purchase new hardware, then the biggest
Virtualization hosts are almost always clustered. If you plan to reuse existing hardware, then you will have to remove one node at a time from your existing cluster so that you can begin deploying the new hypervisor. Depending on how many nodes are in your cluster, you may run into a situation in which you have to begin migrating virtual machines (VMs) before the new cluster is fully in place, because of capacity issues. Similarly, you might also run into issues with storage connectivity between the two clusters.
In almost every hypervisor migration, there will be a period of coexistence. The important thing is to properly plan for it.
Has the staff been properly trained?
Whether you are going from VMware to Hyper-V, Citrix to VMware or something else, switching hypervisors is a big transition. Even though there are similarities between all of the major hypervisors, there are also significant differences. Proper training is necessary to ensure that the IT staff knows how to properly deploy, configure and manage the new environment.
Those who have a lot of server virtualization experience might be inclined to feel their way through the transition without investing in formal training. While that approach might work sometimes, it is important to consider whether you know enough about the new hypervisor to fix any problems that might come up.
Are there any features that you will lose?
Over the last two years, VMware and Microsoft have been involved in a feature war. Whenever one vendor releases a new hypervisor feature, the other is likely to release a comparable feature in the near future. The current versions of VMware and Hyper-V are evenly matched in terms of feature sets, but there are certain features unique to each hypervisor. There are also feature differences and scalability limits. For example, VMware and Microsoft both support clustering, but there is a big difference in the number of nodes that can be included in a cluster. Hyper-V allows a maximum of 64 nodes, which is double the maximum amount of 32 nodes that vSphere 5.5 allows.
Before you commit to switching hypervisors, it is critical to do a feature-by-feature comparison so that you can determine whether you will be losing any important features. Remember, modern hypervisors have hundreds of features, and unless you do a comprehensive feature comparison, you might not realize that you have lost something that you need until it is too late.
Will the transition impact VM density?
If your current virtualization infrastructure is being heavily used, then it is important to consider whether the migration will affect VM density. For example, VMware and Hyper-V both support the use of dynamic memory, but in different ways. Making the transition from one platform to another might change the average amounts of memory VMs consumed, thereby either increasing or reducing VM density.
Will there be a service disruption as a result of the hypervisor switch?
Typically, you will have to shut down a VM before you are able to move it from one hypervisor to another. However, there might be additional factors that also affect the amount of downtime that results from the migration.
Suppose you were to move a VM from a Hyper-V server to a VMware server. In doing so, you would break the VM's connection to the Hyper-V virtual switch. In order to re-establish the network, you would likely have to install VMware Tools and possibly reconfigure the VM's IP address assignment.
As you can see, there is a lot of planning that goes into a hypervisor migration. It is important to be patient and test various aspects of the migration process ahead of time whenever possible.
This was first published in January 2014