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:
Cost Savings: OpenStack significantly reduces licensing fees.
Vendor Independence: Avoid vendor lock-in and make choices based on how they favor your business.
Innovation and Collaboration: Open-source fosters rapid advancements.
Scalability and Elasticity: Automatically scale resources on demand
Multi-Cloud Support: Manage multiple clouds and data centers from one interface.
Integration with Open Source: Seamlessly integrate with Kubernetes and other open-source tools.
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 https://trilio.io/ Platform can help simplify and automate the migration process.
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.
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.
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.
A very intuitive tenant dashboard for the tenant to manage their migrations. If you want to migrate to KubeVirt, Red Hat’s MTV solution can be helpful.
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.
Trilio migration functionality supports three types of migrations
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 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 leverages VMware snapshot and the Change Block Tracking functionality to migrate VMs with less disruption. It first takes the 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 a few more blocks of data, which then gets uploaded by taking a second snapshot of the VM. It then shutdowns the VM, takes another snapshot of the VM, copies the blocks that were changed since the last snapshot, and reboots OpenStack VMs. So warm migration incurs less disruption compared to cold migration.
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.
You will need to be ready with below-mentioned resources before starting with the deployment:
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)
The minimum set of permissions required for a vCenter user to successfully migrate VMs are as follows:
Trilio requires this kit for the VM migration feature to work. You can download it from the VMware Customer Connect portal by accessing the below link
Make sure you download the below-mentioned file
VMware tools need to be installed and should be in running state on all the windows VMs which are to be migrated. Alternatively, the guest OS may be shutdown but they should not be in power off state
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:
set hw_firmware_type
property to UEFI
set hw_machine_type
property to q35
This is not required for BIOS booted VMware VMs
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.
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.
RHOSP version | Supported ? |
---|---|
Privilege Level | Required Permissions |
---|
Product | VMware vSphere Virtual Disk Development Kit 7.0 |
---|
To enable the CBT, follow the instructions at
Also understand the limitations Trilio has described in .
Datastore |
|
Sessions |
|
Virtual machine / Interaction |
|
Virtual machine / Provisioning |
|
Virtual machine / Snapshot management |
|
Version | 7.0 |
Release Date | 2020-04-02 |
Build Number | 15832853 |
File Name | VMware-vix-disklib-7.0.0-15832853.x86_64.tar.gz |
Check the supported OpenStack distributions here and follow their deployment guides to install or upgrade to the latest version of T4O.
17.1 16.2
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 requires manual configuration.
Trilio does not support nested virtualization OpenStack deployments for VMware migration.
For Windows VMs, post migration all the non system disk would be in offline state. You would need to login to the guest VM and manually bring all the attached disk online, follow the below steps:
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 Post-Conversion Tasks for more information.