Streamline Workload Migration: VMware to OpenStack with MigrateKit

8 min read1 day ago

In November 2023, Broadcom completed its acquisition of VMware and subsequent licensing changes have incentivized organizations around the world to re-evaluate their virtualization strategy. OpenStack, the open source standard for cloud infrastructure, has emerged as a leading alternative. Over 80% of OpenInfra members have already talked to customers about migrating workloads from VMware to OpenStack.

Migration VMware to OpenStack with Migratekit

OpenStack’s flexibility and open development enables organizations to:

Implement a cost effective virtualization strategy by avoiding vendor lock-in
Modernize their infrastructure with a cloud native strategy
Customize their stack through increased integration options
Rely on a global ecosystem and diverse, active open source contributors
Maintain complete ownership of their infrastructure

While these benefits are substantial, the migration process can be challenging. Choosing the right tools can make all the difference in ensuring a smooth and cost-effective transition. MigrateKit, recently open sourced by VEXXHOST, is a CLI tool focused on simplifying VMware to OpenStack migration with near-zero downtime. Designed to be easy to use, flexible, it supports various cloud strategies, provides seamless integration with OpenStack environments and allow user to move as much data as possible online. In fact it also uses Virt-V2V in the migration process.

Key Features of Migratekit:

Open-Source: Migratekit is an open-source tool enhancing cloud migration to an open-source environment ensuring seamless integration and consistent deployment.
Automated Process: Automates the migration, reducing the required manual effort and minimizing human error risk.
Consistent Deployments: Ensure a uniform migration across different environments.
Flexibility: Supports various cloud strategies, making it a versatile tool for any migration plan.
Near Zero Downtime: Migratekit is designed to move virtual machines to OpenStack with little to no downtime, maintaining business continuity.
Seamless Integration: Compatible with all OpenStack deployments

Migratekit has 2 phases that it operates in to allow user to migrate virtual machine with near-zero downtime which are documented below:

1. Migration phase

During this phase, Migratekit proactively transfers data while the virtual machines remain operational. This phase is critical, as it ensures that the bulk of data migration is completed with the virtual machines still running on VMware, vastly reducing the need for system downtime.

2. Cutover phase

The final phase of the migration process entails a brief, carefully orchestrated downtime window where the remaining data is synchronized. Following this, the virtual machine instances are transitioned from the VMware environment to their new OpenStack setting, which is now ready to operate with all data and settings intact.

* Prerequisites:

Existing VMware environment as source migration platform
Existing OpenStack Cluster as target migration platform
Linux server with docker installed (In this article used Ubuntu 22.04)
Have connectivity to VMware vCenter endpoint and OpenStack keystone endpoint
Enable Changed Block Tracking (CBT) on virtual machines
Installed VMware Virtual Disk Development Kit (VDDK) 8.0 for Linux
Credential VMware account with the required permissions
Credential and access to OpenStack API

* Migration Phase

On the first migration cycle, Migratekit will do a full copy of the virtual machine to the OpenStack. On subsequent migration cycles, Migratekit will only copy the changes that have been made to the virtual machine since the last migration cycle. The steps look something like the following:

1. Preparing Migratekit Setup

Check docker version and migratekit images

docker version; docker images

Make sure VMware Disk Development Kit (VDDK) is already extract to /usr/lib64/vmware-vix-disklib/

Test connection to OpenStack API

Test connection and access to VMware vCenter server then list all virtual machines managed by a specific host or datacenter

From the list above, there are 2 VMs that will be migrated to OpenStack, namely vm-ubuntu24 and vm-windows-server-2022

2. Running Migration Cycle with Migratekit

Assuming that OpenStack RC file was provided to interact with OpenStack and Docker already installed on migratekit server, then use the following command to run the Migratekit Docker container:

# Used RC file in OpenStack environment to load administrative credentials
source admin-openrc.sh

# Run Migratekit container 
docker run -it --rm --privileged \
  --network host \
  -v /dev:/dev \
  -v /usr/lib64/vmware-vix-disklib/:/usr/lib64/vmware-vix-disklib:ro \
  --env-file <(env | grep OS_) \
  registry.atmosphere.dev/library/migratekit:latest \
  migrate \
  --vmware-endpoint $VMWARE_ENDPOINT \
  --vmware-username $VMWARE_USERNAME \
  --vmware-password $VMWARE_PASSWORD \
  --vmware-path /Datacenter/vm/$VM_NAME

# Migration vm-ubuntu24

In the process above, migration cycle running against a virtual machine located at /Datacenter/vm/vm-ubuntu24 on the VMware endpoint $VMWARE_ENDPOINT (which can be both an ESXi host or a vCenter server) using $VMWARE_USERNAME and $VMWARE_PASSWORD to access VMware. Make sure all of required OpenStack environment variables set in system environment before running the command so that Migratekit can connect to the OpenStack. Also notice volume_id fffa863d-3e38–4513–8377–970bc10d6ae4 from the output.

# Migration vm-windows-server-2022

Notice that vm-windows-server-2022 has 2 disks, with volume_id 5cf66b7c-61aa-433e-8d10-a3140a2858da and c4936fd6–5650–4809-bbf0–8cc36581f2b8

# From VMware Side when Migration Phase

At this point, virtual machines still running on VMware. Notice the IP of web service, it will used when VM running on OpenStack.

Ubuntu VM hosting a web service running on VMware

Windows Server 2022 VM hosting a web service running on VMware

# From OpenStack Side when Migration Phase

All data copied from VMware is now available in OpenStack as volumes.

List volumes in OpenStack (via OpenStack CLI)

* Cutover Phase

Once VM ready to cut over to the OpenStack cloud, it’s time to run the cutover phase. This will ensure all of the matching resources such as Neutron ports exist on the cloud, do a final sync of the virtual machine, power it off inside of VMware, execute a final sync, and then build a new virtual machine on the OpenStack cloud using the same volumes as the original virtual machine. Run the following command to cutover to the OpenStack cloud:

# Run Cutover
docker run -it --rm --privileged \
  --network host \
  -v /dev:/dev \
  -v /usr/lib64/vmware-vix-disklib/:/usr/lib64/vmware-vix-disklib:ro \
  --env-file <(env | grep OS_) \
  registry.atmosphere.dev/library/migratekit:latest \
  cutover \
  --vmware-endpoint $VMWARE_ENDPOINT \
  --vmware-username $VMWARE_USERNAME \
  --vmware-password $VMWARE_PASSWORD \
  --vmware-path /Datacenter/vm/$VM_NAME \
  --flavor $FLAVOR_ID \
  --security-groups $SECURITY_GROUP_ID \
  --network-mapping mac=$MAC_ADDRESS,network-id=$NETWORK_ID,subnet-id=$SUBNET_ID,ip=$IP_ADDRESS

Run it with the same arguments, however at this time specify the flavor and security group that want to use as well as the network mapping for the virtual machine on the OpenStack cloud.
The network mapping allows Migratekit to know what network to attach the virtual machine to on the OpenStack cloud, as well as the IP address to assign to the virtual machine since it cannot map this information from VMware. The format of the network mapping is as follows:

mac: The MAC address of the virtual interface on the virtual machine that you want to map to the OpenStack network (mandatory)
network-id: The UUID of the network that you want to attach the virtual machine to on the OpenStack (mandatory)
subnet-id: The UUID of the subnet that you want to attach the virtual machine to on the OpenStack (mandatory)
ip: The IP address that you want to assign to the virtual machine on the OpenStack (optional, Neutron will assign an IP address if this is not specified).

Ideally match the network mapping to the network that the virtual machine is attached to on the VMware side to ensure that the virtual machine can communicate with the network once it has been migrated to the OpenStack cloud.

# Cutover vm-ubuntu24 using same IP address (192.168.1.158) with source VM

During cutover, there is a full copy of the migration cycle and the Source VM will automatically shut down. Then a new VM created in OpenStack using volumes copy from Source VM.

VM on VMware was poweroff (left), VM now running on OpenStack (middle), web service running with the same IP Address (right)

At this point check all functionality of services on VM in new environment, IP address, firewall / security group, ensure connectivity with surrounding, data gap with source VM, etc.

A web service with updated content currently hosted on OpenStack

# Cutover vm-windows-server-2022 using different IP address with source VM and has 2 disks

VM windows server 2022 has 2 disks, first disk for OS and a secondary disk for data. During cutover all disks will be automatically attached to the New VM in OpenStack

Cutover process for VM Windows Server 2022

Check all functionality of services on VM in new environment, ensure connectivity with surrounding, data gap with source VM, etc. Secondary disk must working fine after cutover.

VM windows on VMware was poweroff (left), VM windows now running on OpenStack (right)

Finally, both VMs from VMware now running on OpenStack

Based on volume information below, volume-ubuntu24–2000 attached to instance vm-ubuntu24 as /dev/vda. Meanwhile instance vm-windows-server-2022 has 2 volumes attached for OS and secondary disk or data.

Aspects to think about

Migrating from VMware to OpenStack can be a complex process, but with the right tools, strategy, and knowledge, it is possible to streamline the transition while minimizing downtime and disruption. To ensure a successful migration, consider the following key factors:

Choose the right tools: Selecting the appropriate migration tools is critical to support the process effectively.
Migration speed: Evaluate the speed of the migration cycle, from data replication to the final cutover phase, to minimize disruptions.
Application complexity: Align the migration strategy with the complexity of the applications being migrated.
Downtime and rollback planning: Prepare a detailed plan to handle downtime and ensure rollback procedures are in place in case of issues.
Data integrity: Address potential data gaps during the migration process and ensure data consistency.
Workload dependencies: Identify dependencies between workloads and their surrounding ecosystem to avoid service interruptions.

See other content

References :

#VMware #Migration #OpenStack #OpenSource #Migratekit #CloudComputing #PrivateCloud