Migrating VMs from VMware to Alternative Hypervisor: An Ultimate Guide

Many users are concerned about VM migration when planning to replace VMware.

How to migrate VMs from one hypervisor to another?
How to keep the migration process stable and efficient?
How to ensure the compatibility between VMs and the new hypervisor?

Addressing these issues is critical to ensuring a smooth transition away from VMware. In this blog, we will dive into the entire process of migrating VMs from VMware to an alternative hypervisor, using SMTX Migration Tool as an example. Finally, we will share two case studies that have achieved large-scale VM migration from VMware to SmartX ELF virtualization using SMTX Migration Tool.

Q&A: Reliability, Compatibility and Business Impact of VM Migration

Q1: How does the cross-hypervisor VM migration work?

Migration tools provided by different vendors have various designs. SMTX migration tool, for example, mainly relies on VM snapshots for data transfer and synchronization.

Take a snapshot of the source VM and transfer full snapshot: The migration tool takes an initial snapshot of the source VM and transfers the full snapshot copy to the target VM. During this process, the source VM can remain online and operate normally.
Synchronize incremental data of the source VM to the target VM: After the full snapshot copy transfer is completed, users can choose to manually synchronize the incremental data generated during the snapshot of the source VM. Otherwise, users can directly shut down the source VM for incremental data synchronization. The advantage of manual synchronization is that most of the incremental data can be replicated while the source VM remains online, significantly reducing the subsequent downtime of the source VM for the final data synchronization. After the source VM is shut down, SMTX Migration Tool will automatically implement the target VM driver injection, the necessary system configuration, and so on. Once these operations are done, the migrated VMs can be booted in the new cluster.

Q2: What are the stages involved in the entire VM migration project?

Besides the formal migration tasks, the migration project also involves stages such as the evaluation of migration feasibility, making a migration plan, configuration and inspection of hypervisor, and pre-migration.

Q3: Can all VMs be migrated using the migration tool?

Taking the SMTX Migration Tool as an example, some VMs are not suitable for migration through the tool, such as:

VMs with shared virtual disks (e.g. Oracle RAC): Migration of shared disks is not supported by SMTX Migration Tool nor by vMotion.
VDI (e.g. Horizon View and Citrix XenDesktop deployed VMs): These VMs cannot be migrated via the SMTX Migration Tool or vMotion.
AD Domain Controller VMs: Since this type of VM is strictly bound to hardware information, v2v migration may cause improper AD services.
Incompatible operating systems: SMTX Migration Tool cannot migrate VMs on some old or niche operating systems. Please contact SmartX sales for detailed information.

These VMs need to be migrated through manual operations.

Q4: What are the impacts of VM migration on business operations?

As described in Q1, source VM can run normally during full data transfer and manual synchronization of incremental data, meaning that there will be no impact on running business services. However, source VM needs to be shut down for a while for the final incremental data synchronization. Therefore, users need to schedule a downtime window for the migration project.

Dev/Test VMs can be migrated during business hours.
VMs running business services are suggested to be migrated during off-peak hours, which will prevent business services from performance degradation caused by the migration.
To reduce the downtime and final delivery time of business systems, users can manually synchronize the incremental data generated by source VM to target end after the full data transfer is completed. This will be performed online, and the time interval of incremental migration can be adjusted according to the business requirements and network conditions.
The final phase of VM migration involves a manual shutdown of source VM to perform the switchover. Therefore, users need to carefully arrange the downtime window. With SMTX Migration Tool, in most cases, the downtime window will not exceed 30 minutes. But it may extend if there is a large amount of incremental data to transfer (the length of downtime is determined by the amount of incremental data and the efficiency of network transmission).

Overall, source VM can operate normally during the full data transfer phase and the manual synchronization phase, but the performance of VM may be slightly degraded. During the downtime synchronization phase, source VM needs to be shut down, but the shutdown time is relatively short, with its impact on business can be minimized through a careful arrangement of the downtime window.

Q5: How to ensure the compatibility between VMs and the new virtualization platform?

Since the migration tool bridges the VMware and another hypervisor, the migration tool’s compatibility with the vCenter/ESXi version, the VM operating system, the CPU architecture, and the VMware virtual switch type is critical to ensuring a smooth migration. Currently, some migration tools cannot support VMs based on vSphere Distributed Switch (VDS), but only the standard switch fabric (VSS). However, migrating VMs from VSS to VDS may cause business network disruption, making these migration tools less effective.

At present, the SMTX Migration Tool is compatible with a wide range of source and target environments, specifically as follows:

1. Compatibility with vCenter Edition/ESXi Edition

SMTX Migration Tool can set vCenter and ESXi host (in scenarios where vCenter is not deployed) as the source site, but it does not support all vCenter/ESXi versions. For example, the compatibility list of SMTX Migration Tool 1.5 is shown below.

Notably, SMTX Migration Tool is compatible with a wider range of ESXi versions compared to vCenter versions. Therefore, when trying to migrate VMs from an older version of a VMware cluster, users can associate to ESXi host instead of vCenter.

2. Compatibility with VM Guest OS

SMTX Migration Tool has been adapted to a wide range of operating systems including CentOS, Windows Server, Redhat, Linux, Ubuntu, etc. Please make sure the VM Guest OS is included in the SMTX OS Compatibility List before the migration. If your Guest OS is not included in the list, please contact SmartX professionals.

3. Compatibility with server chips

SMTX Migration Tool supports Intel x86_64 architecture chips on the source (VMware cluster), and Intel x86_64 architecture chips and Hygon x86_64 architecture chips on the target (SMTX OS cluster).

In addition, SMTX Migration Tool enables VM migration based on the vSphere Distributed Switch architecture.

Q6: How to improve VM migration efficiency?

Migration rates can be affected by a variety of factors, including network bandwidth, the number of concurrent migration tasks, and where the migration tool is deployed.

Take SMTX Migration Tool as an example. SMTX Migration Tool can be deployed in the form of a VM in an existing VMware cluster or a newly created SMTX OS cluster. The migration tool is associated with both the VMware cluster and the SMTX OS cluster, and copies the disk data of VMware VMs to SMTX OS cluster over the network. Therefore, the migration efficiency can be affected by factors such as network bandwidth between the clusters, and disk performance. The charts below show SMTX Migration Tool’s performance under 1GbE network.

Test 1: Performance of SMTX Migration Tool with the same deployment location (in VMware cluster) but different storage type (of the source cluster):

Test 2: Performance of SMTX Migration Tool with the same storage type of the source cluster (SSD) but different deployment locations:

In addition, VM of SMTX Migration Tool can mount two virtual NICs, one (required) for connecting to the VMware cluster management network and the SMTX OS cluster management network, and the other (optional) for connecting to the SMTX OS storage network to increase data transfer speeds, which can effectively shorten the migration time.

Q7: How to make a VM migration plan?

Before making a migration plan, you need to know the basics of your current VMware VMs. Inventory information for VMs can be exported from VMware vCenter through the following steps:

Log into the vSphere Client.
Select Inventory List Overview.
Click the Virtual Machines tab to display a list of all VMs, and then filter as appropriate.

Typical information that needs to be collected includes CPU, memory, memory utilization, provisioned space, used space, number of network cards, port groups, and so on. The purpose of this session is to understand the overall resource requirements of the virtualized environment. Therefore, the new cluster can be configured based on the total resources required by the VMs to be migrated.

After confirming the migration time window and compatibility, a detailed migration schedule can be created. Currently, the maximum number of concurrent migration tasks performed by SMTX Migration Tool is 5. It also supports setting task queues. During the migration, users need to control the number of concurrent migrations according to the migration bandwidth. If the bandwidth utilization becomes too high, the migration will be interrupted or fail. For example, if the migration network bandwidth is 1G, the recommended number of concurrent tasks will be 1 or 2. If the migration network bandwidth is 10G, the number of concurrent tasks can be set to 5 (also need to take the original cluster performance into account).

The migration order can be sorted according to the importance of the business running on the VMs from low to high and the disk space from small to large. In addition, it is recommended to arrange a pre-migration (using VMs that do not contain real businesses) before the formal migration to get familiar with the whole migration process.

Q8: How to enhance the reliability of the migration process?

Besides checking VM information and compatibility of the migration tool, users can also inspect hypervisor settings and implement pre-migration to enhance the reliability of VM migration.

1. Environmental inspections

Check network connectivity: This is basically about the network connectivity between the migration tool and vCenter/ESXi hosts. For instance, if there are firewalls between them, you need to open the relevant ports in advance.
Check if the vCenter and ESXi hosts are associated with each other via DNS domain names: If so, you need to make sure that the migration tool and the destination cluster and host are all interpreting the DNS domain names properly.
Check whether the VM to be migrated contains a snapshot: If it does, you need to delete the snapshot before performing the migration.
Clean up non-essential virtual peripherals, such as USB passthrough devices, ISO images, etc., on the VMs to be migrated.
Uninstall the VMware VMTools on the VMs to be migrated.

2. Pre-migration

Users can select a VM template in VMware clusters and migrate it to the destination cluster using the migration tool. Pre-migration allows you to verify if the entire migration process is smooth and efficient. In this phase, you can obtain information such as VM disk capacity, migration speed, migration time, etc., and use it as a reference for the formal migration.

Q9: How to carry out the formal migration?

With SMTX Migration Tool, the formal migration involves the following steps:

Select VMs to be migrated: Select the VMs to be migrated (one or more concurrently) according to the migration plan.
Select target cluster and host: If there are multiple SMTX OS clusters on your site, select the appropriate cluster as the target cluster based on resource utilization.
Select the virtual network: Generally, select the same subnet as the original VM. If there are multiple virtual NICs, they should correspond to each other as needed to ensure normal communication on the virtual network after the migration is completed.
Full copy transfer: The data transfer phase requires a complete copy of the virtual machine’s disk data over the network, and the whole process takes a long time. In case of network interruption during the transfer, you can use the SMTX Migration Tool’s breakpoint resumption function to ensure the continuity of VM migration.
Incremental data synchronization: When data transfer is completed, users can choose to manually synchronize the incremental data and then shut down the source VM. After shutdown, the migration tool will automatically synchronize the remaining incremental data and perform the necessary driver injection and system configuration operations.
Check target VMs: After the migration is completed, users should check the new VMs in the SMTX OS cluster to ensure that the operating system can be logged in normally, the network can communicate normally, the virtual disks have all been mounted normally, and the critical applications can run normally.

Q10: What should I do if there is an “accident” during the migration process?

1. The operating system is not covered in SMTX Migration Tool Compatibility List

If the VM’s operating system is not listed in SMTX Migration Tool Compatibility List but GuestOS is compatible with SMTX OS, you can try to migrate the VM to the SMTX OS cluster via SMTX Migration Tool first. If you cannot access the operating system normally after the migration, please refer to the following checking steps to locate the problem and try to work it out.

Boot device cannot be found: If the VM suggests that it cannot find the boot device after booting, this may be because the boot partition cannot be recognized as the Virtio driver for the virtual disk was not injected successfully. In this case, you can switch to the emergency mode on the VM console to check if the virtual disk can be recognized, and try to install the driver and modify the boot configuration information to fix the problem.
Unable to start the GUI: If a Linux VM can normally enter the operating system but can not start the GUI, this may be due to the mismatch between the virtual GPU and its configuration file. You can reset the configuration file to solve this problem.

2. Migration rollback

If the VM cannot complete the migration normally, or the business systems cannot run normally after the migration, you can try to roll back the migration. The process is as follows:

Log in to the CloudTower (SMTX OS UI) and shut down the migrated VMs in the SMTX OS cluster.
Log in to the original VMware vCenter, locate the original VM, and restart the VM.
Check if the VM can be logged in and the business system can provide services properly.

Case Studies: Replacing VMware Virtualization with the Help of SMTX Migration Tools

An Insurance Company: Migrating 500+ VMs from VMware to ELF Virtualization with SMTX Migration Tool

A leading Chinese insurance company had plans to replace VMware virtualization but was concerned about the reliability of VM migration. Upon discovering SmartX’s migration tools, the company conducted tests to assess the efficiency, reliability, and user-friendliness of using the SMTX Migration Tool to migrate VMs from VMware to ELF virtualization.

The company was highly satisfied with the performance of the SMTX Migration Tool and subsequently migrated over 200 VMs in the production environment and 300 VMs in the development and testing environment from VMware to ELF. There are still 500 VMs in the production environment on the waiting list for migration.

To ensure migration reliability, before each migration task, SmartX engineers would carefully check the status of the VM to be migrated with the insurance company, including:

Make sure the VM’s operating system strictly complies with the compatibility list.
Check the VM’s name and IP information, virtual disk capacity, computing resource usage, and the specific downtime window.
Check whether there is automatically mounted network storage in the customer’s operating system (canceling the automatic mounting of NAS storage before migration and restoring it after the migration is completed).

In addition, the migration tasks were arranged during idle time to ensure that the migration would not affect the normal operation of business services. SmartX engineers also strictly followed the standard of 20 minutes of downtime per VM and conducted power-on verification of new VMs in the SMTX OS cluster. The migration tasks were all completed only after the user confirmed that the business services could run normally in the new environment. Notably, despite the normal downtime window being 20 minutes, SmartX engineers managed to complete migration tasks ahead of schedule as the project went ahead, minimizing disruptions to business operations.

Thus far, SMTX OS clusters have been providing stable support for a range of core business services, including life insurance and property and casualty insurance, as well as management systems and OA systems.

Jinjiang Finance: Migrating 100+ VMs Within a Week, and Achieving One-Stop Replacement of VMware HCI

The Finance Company of Jinjiang International Group (referred to as Jinjiang Finance) simultaneously replaced vSphere and vSAN with SmartX HCI.

Initially, Jinjiang Finance used physical servers and VMware HCI clusters to support business systems in the production environment. However, issues such as complex vSAN software upgrades and prolonged fault recovery times disrupted normal business operations. To address these challenges, the company introduced SmartX HCI (leveraging ELF virtualization) into the production environment, specifically to support data warehouses and critical business systems.

After six months of operation, the company gained confidence in SmartX HCI’s performance and stability. Consequently, the company employed the SMTX migration tool to migrate more than 100 VMs from the VMware HCI to the ELF-based SmartX HCI cluster. Remarkably, the migration was completed within a week without any disruption to normal businesses.

Currently, the SmartX HCI cluster has been consistently delivering high-performance support for user’s mission-critical applications, databases (including Oracle and MySQL), middleware (Nginx, JDK, Redis, etc.), and other essential applications for nearly a year.

For more information on VMware replacement, please visit our solution webpage, and read our previous blogs:

The Ultimate Guide to Cope with VMware’s Simplified Portfolio and Licensing Model

Four Case Studies Disclose How to Replace vSAN and VMware HCI with SmartX HCI

Why Enterprises Choose SmartX ELF Virtualization as a VMware Alternative: Five Customer Stories

Three Performance Comparisons Disclose Why You Should Choose SmartX HCI as a VMware Alternative