Many organizations are looking to modernize their data centers and migrate from technologies like VMware to OpenStack. Although historically, VMware has been a dominant virtualization platform, trusted by many organizations for running mission-critical applications, the rapidly evolving technology landscape has already delivered the next generation of virtualization technologies. OpenStack and Kubernetes are setting the stage for edge computing and Hybrid & Multi-Cloud to emerge as industry standards.

Migrating from VMware to OpenStack offers compelling benefits:

1. Cost Savings: OpenStack significantly reduces licensing fees.

2. Vendor Independence: Avoid vendor lock-in and make choices based on how they favor your business.

3. Innovation and Collaboration: Open-source fosters rapid advancements.

4. Scalability and Elasticity: Automatically scale resources on demand

5. Multi-Cloud Support: Manage multiple clouds and data centers from one interface.

6. Integration with Open Source: Seamlessly integrate with Kubernetes and other open-source tools.

7. Community Support: Active community provides resources and expertise

By embracing OpenStack, you gain cost savings, flexibility, scalability, and a vibrant community, empowering your cloud infrastructure.

Migrating VMs from VMware to OpenStack has traditionally been a people-intensive and complex process requiring an "expert-intensive" investment.

Organizations must engage in detailed planning, consult experts, and consider utilizing tools and technologies to facilitate smooth migrations. Because each migration scenario is unique, it has been difficult to come up with best `practices and/or automation. This page is about how Trilio’s Intelligent Recovery Platform can help simplify and automate the migration process.

VMware version

• VMware vSphere ESXi 7.0.x

OpenStack distributions

Guest VMs

[1] SUSE Enterprise Linux guests are validated to run on RHEL hosts. However, SUSE Linux uses the btrfs file system by default, which is unsupported by RHEL. Therefore, converting a SUSE system that use btrfs is not possible with virt-v2v.

In addition, VMs that use X graphics and a SUSE Linux Enterprise Server 11 operating system should be re-adjusted after the conversion for the graphics to work properly. To do so, use the sax2 distribution tool in the guest OS after the migration is finished.

[2] As a Technology Preview, converting Debian and Ubuntu VMs is not supported. In addition, this conversion currently has the following known issues: * virt-v2v cannot change the default kernel in the GRUB2 configuration, and the kernel configured in the VM is not changed during the conversion, even if a more optimal version of the kernel is available on the VM. * After converting a linux virtual machine to KVM, the name of the VM's network interface may change, and thus requires manual configuration.

Note: virt-v2v conversions of any operating system not listed above may in some cases work, but are not supported by Red Hat.

• Refer to the "Supporting Conversions" section of .

Overview

Architecture

Native Service to OpenStack

Trilio’s backup and recovery solution is an OpenStack native service similar to Nova, Cinder, Glance, etc. This software-only solution can be deployed using OpenStack distribution-specific DevOps scripts. For example, Trilio’s solution is native to the RHOSP platform and can be deployed and managed using Red Hat Director.

Highly Scalable

We extended Trilio’s architecture to support migration at scale. Since Trilio migrates the VM from VMware ESXi to the OpenStack compute node, the solution scales with your VMware/OpenStack without suffering from performance bottlenecks.

Self-Service and Inline Migration

The process of migration usually involves moving virtual machines from a source platform to a target platform, however, the strategy to achieve this should be considered carefully.

If the migration process is initiated from the target platform, it is called inline migration. Trilio advocates inline migration as it helps map organizational structures such as data centers/clusters/folders in VMware to regions/domains/projects in OpenStack.

A project owner with sufficient privileges to their VMware resources can migrate the VMs to their project. If every project owner can migrate their resources from VMware, it provides better control to cloud architects to orchestrate the migration.

If the migration process is initiated from an outside source or target platform, it is called out-of-band migration. Out-of-band demands a centralized approach and places constraints on how cloud architects can design their OpenStack clouds.

Horizon Dashboard Plugin

A very intuitive tenant dashboard for the tenant to manage their migrations. If you want to migrate to KubeVirt, Red Hat’s solution can be helpful.

Command Line Interface

The sub-commands for the migration feature are available as:

Migration APIs look and feel like OpenStack API. Each tenant can source their cloud rc and start using migration cli commands. CLI also helps users to extend their Ansible scripting for migration.

Migration Types

Trilio migration functionality supports three types of migrations

Dry-run

Dry-run lets users create the VMs on OpenStack with storage volumes, networking, and security groups attached. It does a migration of VM data from VMware to OpenStack by taking a snapshot of the VM without shutting it down and hence, does not guarantee the data/application consistency. Unlike Cold and Warm migration, there is no disruption to the VMware VMs during this migration. It is a handy feature for users to test VMs and their interconnectivity before completely migrating VMs.

Cold Migration

Cold migration shuts down the VMware VMs and migrates the VMs to OpenStack. Depending on the size of the data to migrate, cold migration can take minutes to hours to complete, and during the entire duration, the applications are unavailable. Cold migration is more disruptive than warm migration.

Warm Migration

Warm migration leverages VMware snapshot and Change Block Tracking functionality to migrate VMs with minimal disruption. It first takes a VM snapshot and copies the full snapshot data to OpenStack. Depending on the size of the data, this upload operation may take a few minutes to a few hours. During this period, the VM may have written additional data blocks, which are then captured by taking a second snapshot of the VM.

At this point, the cutover occurs as per the option selected by the user during invoking the migration:

• Manual cutover (default): After the second snapshot upload, the migration process pauses. The user must manually resume the migration once they are ready for the source VM to be shut down and the final data upload to be performed.

• Automatic cutover: After the second snapshot upload, the source VM is automatically shut down, and the final data upload is performed without user intervention.

In both cases, after the final snapshot is uploaded, the corresponding VM is started on OpenStack. Warm migration therefore provides significantly less downtime compared to cold migration.

Conclusion

Trilio's support for migrating VMware VMs to OpenStack is recognized as an industry-leading solution. Its scalability and ability to be deployed organization-wide scale make it a valuable choice for businesses. The self-paced approach provided by Trilio allows application owners to experiment with migration options and gain confidence before performing the final migration. In the context of businesses transitioning from vendor lock-in to open-source technologies, Trilio's migration feature can be a helpful tool in accelerating the transition process.

Check the supported OpenStack distributions here and follow their deployment guides to install or upgrade to the latest version of T4O.

Enable Migration Tab on Horizon

Follow below steps to enable Migration Tab on Horizon.

1. Login to horizon container.

2. set DISABLED = False in following panel files.

These files can be found at <openstack_dashboard_installed_package_path>/enabled/

Example: /usr/share/openstack-dashboard/openstack_dashboard/local/enabled/ for RHOSP17.1

1. Restart horizon container.

Trilio uses a widely used tool virt-v2v for migration which is one of the open-source tools by Red Hat. The below-mentioned limitations are from this tool and thus a limitation for Trilio as well:

• virt-v2v cannot change the default kernel in the GRUB2 configuration, and the kernel configured in the VM is not changed during the conversion, even if a more optimal version of the kernel is available on the VM.

• After converting a virtual machine to KVM, the name of the VM's network interface may change, and thus may require manual configuration.

• Trilio does not support nested virtualization OpenStack deployments for VMware migration.

• For Windows VMs, post migration, if the secondary disks are in an Offline state, you would need to log in to the guest VM and manually bring all the attached disks online by following any of the below steps:\

  1. Disk Management Console:

     • Open Disk Management. You can do this by searching for "Computer Management" in the taskbar and navigating to Storage > Disk Management.
• Windows VMs migrated with the Dry-Run type won't be bootable on OpenStack, as complete boot information won't be available until the guest VM is shut down.

Please refer to for more information.

Other Limitations specific to VM Migration:

• If any VM is having independent (i.e. not mounted on "/") /usr partition, then migration of such VM will fail with below error:

Introduction

VM Migration Tool is an add-on stand alone utility provided by Trilio for effective migration of VMs from VMWare to OpenStack. This will assist users in planning the migration, creating any missing artifacts, and providing a holistic view of the migration process at an organizational level.

Current document provides the steps to be followed for deploying respective tool.

Preparing vCenter + OpenStack + Trilio

You will need to be ready with the following resources before starting with the deployment:

VMware Resources

vCenter access information

• vCenter access URL

• vCenter access Username and Password

• SSL certificate for secured connection to VCenter (if not available, the SSL verification has to be marked false during configuration)

Network Port Requirement

Trilio needs to have below port accesses for the VM migration feature to work:

• On vCenter:

  • 80, 443: bi-directional access to OpenStack controller and compute nodes

• On ESXi hosts:

VMware vSphere Virtual Disk Development Kit 7.0

• Trilio requires this kit for the VM migration feature to work. You can download it from the VMware Customer Connect portal by accessing the link below

• ​​

• Make sure you download the file

  Name

OpenStack Resources

Glance Images

• For migrating UEFI booted VMware VMs, the OpenStack requires to have the instances with UEFI boot information and so as Trilio.

• So before doing the migration, the user needs to create a Glance image (any image) with following metadata properties:

  1. set hw_firmware_type property to UEFI

Instace Flavors

• Trilio does not create any flavor for the migrating VMs instead it uses the available flavors.

• To avoid any booting issues post-migration, the user needs to have the correct flavors created and available for selection while initiating the migration.

Preparing the Guest VMs on ESXi

Windows VMs Preparation

• VMware tools need to be installed and should be running on all the Windows OS VMs that are to be migrated. Alternatively, the guest OS must be in a Shutdown state and not be in a Power-off state.

• Secondary disks in Windows Server VMs appear offline after migration.

  To avoid the disks going into an offline state, set the SAN policy OnlineAll in the guest VM before the migration. Steps to change the SAN policy:

Enable Change Block Tracking

To leverage the Dry-run and Warm migration features, the vCenter and ESXi should support the Change Block Tracking(CBT) feature. Make sure that all the data disks attached to the VM, have the CBT enabled.

To enable the CBT, follow the instructions at

Also understand the limitations Trilio has described in .

Free space in the guest for conversion

Virt-v2v checks if there is sufficient free space in the guest filesystem to perform the conversion. Currently, it checks:

• Linux root filesystem

  • Minimum free space: 100 MB

• Linux /boot

In addition to the actual free space, each filesystem is required to have at least 100 available inodes.

Access to "/etc/resolv.conf"

In a Linux guest, you see an error such as this:

virt-v2v: error: libguestfs error: command lines: rename: /sysroot/etc/resolv.conf to /sysroot/etc/lwdhuh36: Operation not permitted

This can be caused because the file /etc/resolv.conf in the guest has the set. You can use the command before converting the guest:

and then restore it (+i) after conversion.

In addition, please refer to for other requirements and notes.