I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

The layer of abstraction between a virtual machine (VM) and its physical hardware means you can move VMs to other hosts without worrying about compatibility with the underlying hardware. Even so, there are other challenges you may encounter during the hardware migration process.

Your biggest challenge is preventing downtime. To avoid downtime during the hardware migration process, you can implement server clustering, which allows VMs to migrate to other hosts when you bring the physical host down. Server clustering and other fault-tolerance methods are useful for preventing data loss when performing a virtual server migration. A cluster is not required, but it will help you to prevent extended downtime.

The following hardware migration techniques assume you’re sticking with the same virtualization platform on both hosts. There are ways to migrate VMs from VMware to Microsoft Hyper-V hardware, or vice versa, but such techniques greatly complicate things when performing a virtual server migration.

Hardware migration in a clusterBy far the easiest type of virtual server migration to perform is when the VM resides on a host in a virtual server cluster, because that means you can move a VM without taking it offline. With server clustering, you can bring a new host into the cluster, migrate VMs to the new host, and then remove the original host from the cluster.

There are a few important things to consider around this type of hardware migration. First, you must consider the size of the cluster. Any virtualization platform that supports server clustering also imposes cluster sizing limits, which control the maximum number of hosts and VMs within the cluster.

As you formulate your hardware migration plan, take these limits into account. If you have a small cluster that’s nowhere near the platform’s limits, you can bring all your new hosts into the cluster, move the VMs to the new hosts, and then decommission the old hardware. If, however, the cluster is at or near its limits, you’ll have to be more creative with the hardware migration.

If the cluster already contains the maximum number of nodes, you have no choice but to perform a multi-step virtual server migration. The first step is to move the VMs off the obsolete hardware and onto other cluster nodes. Because each host limits the total number of VMs that it can host, you will likely have to spread the VMs across the remaining nodes in the cluster. That way you don’t exceed the limits or capabilities of any single host.

Once you have removed all VMs from the obsolete hardware, you can remove that host from the cluster and replace it with a new one. Then, you can move VMs back to the new node. After doing so, you can decommission that node and replace it with a new server. You would then repeat the process for each remaining cluster node.

Another important consideration when performing a virtual server migration within a cluster is VM availability. Some server clustering tools allow you to perform a live migration with no downtime. Others may only offer a quick migration. A quick migration means each VM is offline for a brief period of time during the hardware migration.

Hardware migration without server clusteringIf the host you’re replacing is not in a virtual server cluster, you won’t be able to perform a live migration or quick migration -- meaning you won’t be able to avoid some downtime. If you don’t have a virtual server cluster, you can instead perform a manual import/export of the VMs or use a management utility to expedite the virtual server migration.

A manual import/export incurs a significant amount of downtime during the hardware migration. The basic idea is that you take the VM offline, copy it to the new location, and import it to the new hardware. If the old server stored VMs on a storage area network (SAN), you may be able to skip the copying portion of the hardware migration. You must still configure the new host to connect to the SAN before you begin the virtual server migration.

There are enterprise VM management tools that can reduce the amount of time it takes to move VMs in a hardware migration. Such utilities work by copying the virtual hard disk files to the new location while the VM is still online. These tools only take the VM offline after the copy process completes. This process isn’t as efficient as a virtual server migration within a cluster, but it usually requires less downtime than a manual import/export.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy