Manage Learn to apply best practices and optimize your operations.

Preparing your checklist for a flawless hypervisor switch

No matter what your reason is for a hypervisor switch, there is plenty to consider before the change.

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 coexistence issues will be available power and floor space in your data center. However, things become more complicated if you plan to reuse existing hardware.

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.

Dig Deeper on Improving server management with virtualization

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What complications have you encountered when switching hypervisors?
If the article author Brien Posey is involved with virtualization on a professional technology level, is he connected in any way to Microsoft virtualization technology?

My reason for question emanates from each of his intimations in the story where, for example, he poses prospective move "FROM" Vmware "TO" Microsoft, and references Microsoft Hyper-V supporting twice the cluster nodes as VmWare. It is my clear understanding that VmWare 5.5 will support more cluster nodes running on Linux or FreeBSD UNIX-like Operating Systems (OS) than on Windows Server. Furthermore, Mr. Posey made no mention of the KVM virtualization that has significant deployment in Fortune 1000, most of the largest Networking and Services companies in USA and Internationally, as well as a substantial dominant presence in Europe, Asia and South America.

While the intent of the article may have been an attempt to 'appear" generic and objective in discussing VM migration projects, the omission of even 'noting" existence of other world class virtualization technologies and the sly, subconscious push toward Microsoft are quite apparent.

This deceitful trend at TechTarget of strong Microsoft focus and preferences against more credible, objective tech journalism - where it is required and demanded - should be and will be exposed to the general technology public. Already, organizations like the Linux Foundation, The Free Software Foundation, The FreeBSD Foundation, the Apache Organization, The Eclipse Foundation and the Mozilla Foundation have been alerted to the hidden unethical practices, posing as credible, non-partisan tech reporting by TechTarget and a few other technology media.