This website use cookies to help you have a superior and more admissible browsing experience on the website.
Loading...
By:
VMware to OpenStack Migration has become a strategic choice for enterprises to control IT costs. After Broadcom acquired VMware, the perpetual license policy was canceled, and users were forced to adopt high-cost subscription packages, which led to a sharp rise in the total cost of ownership (TCO). Faced with unstable pricing rules, more and more enterprise IT teams choose open-source alternatives to make budgets predictable.
Besides cost reduction, switching from VMware ESXi to OpenStack helps businesses get rid of proprietary vendor lock-in. As an open-source cloud operating system, OpenStack supports highly customized cloud infrastructure via open APIs. It also optimizes hardware investment and benefits from a large global developer community that continuously upgrades security capabilities and infrastructure features.
VMware vSphere is a mature, commercial Type-1 virtualization platform. Its computing, network, and storage resources are centrally managed by tools such as vCenter Server, with high integration of all modules.
OpenStack is an open-source cloud operating system that orchestrates massive pools of compute, storage, and networking resources through modular API-driven microservices, turning bare-metal infrastructure into an elastic multi-tenant private cloud.
To complete workload migration from VMware to OpenStack smoothly, you need to match VMware components with the corresponding OpenStack services. The mapping relationship is shown below:
|
VMware Component |
OpenStack Service Equivalent |
Functional Role in the Cloud |
|
ESXi / vSphere Clusters |
Nova |
Compute resource provisioning and virtual machine scheduling. |
|
vCenter Server & SSO |
Horizon & Keystone |
Centralized web administration dashboard and identity/permission management. |
|
VMware VMDK / Datastores |
Cinder (Block) / Glance (Images) |
Manage persistent virtual disk mapping and system image templates. |
|
vNetwork Distributed Switch |
Neutron |
Software-defined networking (SDN), logical routing, and tenant port controls. |
Executing a large-scale cloud transition requires a standardized, phased framework to guarantee architectural stability. The entire migration lifecycle is governed by these four core principles:
Finish the following four key checks before formal migration. Any omission will cause target system crashes, network disconnection or data corruption.
Agentless cold migration means shutting down the source virtual machine for offline conversion and transmission. It is the most widely used solution for environments with planned downtime. Below are two mainstream implementation methods.
virt-v2v is an automated open-source tool. It can directly connect to VMware, complete format conversion, inject VirtIO drivers, and export available cloud images in one pipeline.
Applicable Scenario: No firewall interception, medium and small virtual machines, planned maintenance window.
Step 1: Source your target OpenStack admin credentials.
Log in to the OpenStack node via SSH, execute the command to load environment variables and API access tokens:
source /etc/kolla/admin-openrc.sh
Step 2: Verify access to Glance image service
Run the following command to confirm the current account has valid administrative permissions:
openstack image list
Step 3: Execute the full migration command.
Connect to vCenter, specify the ESXi host, and push the converted image to OpenStack Glance:
virt-v2v -ic 'vpx://root@vcenter.example.com/Datacenter/Cluster/' \
-it esxi_host_ip_or_name \
-o glance \
-os openstack \
"source_vm_name"
When firewalls block direct connection between tools, use this manual conversion solution to complete migration step by step.
Step 1: Download the flat VMDK file from the ESXi host.
Use the “scp” tool to copy the flattened virtual disk file to the local staging machine:
scp root@:/vmfs/volumes/datastore1/my_vm/my_vm-flat.vmdk /tmp/
Step 2: Convert VMDK to QCOW2 format.
Use “qemu-img” to convert VMware disk format to OpenStack-adapted QCOW2:
qemu-img convert -f vmdk -O qcow2 -p /tmp/my_vm-flat.vmdk /tmp/target_image.qcow2
Step 3: Upload QCOW2 image to Glance
Register the image and mark the corresponding boot firmware type:
openstack image create --disk-format qcow2 \
--container-format bare \
--property hw_firmware_type=bios \
--file /tmp/target_image.qcow2 \
"Migrated-Enterprise-Workload"
Step 4: Create and launch your new Nova instance.
Deploy a new virtual machine based on the uploaded image and specified network:
openstack server create --flavor m1.medium \
--image "Migrated-Enterprise-Workload" \
--network private_service_network \
"New-OpenStack-Instance"For core production workloads with strict SLA requirements, offline migration tools will bring huge business risks. The i2Migration solution adopts agent-based architecture to realize true zero-downtime live migration.
Advanced V2V Mechanics Tailored for OpenStack Fabrics
Please watch the VMware to OpenStack migration demo, cantact us if you want to learn more information.
|
Feature Metric |
Manual qemu-img + CLI |
Open-Source virt-v2v |
Enterprise i2Migration |
|
Migration Mode |
Cold Offline (Requires VM Shutdown) |
Cold Offline (Requires VM Shutdown) |
Hot Live Migration (Zero VM Downtime) |
|
Data Ingestion Target |
Local File System – Uploaded to Glance |
Streamed directly into the Glance Image Registry |
Replicated directly into Cinder Volumes / Ceph RBD |
|
Target Boot Readiness |
Manual VM creation & manual volume attachment required |
Generates a static template image, still requires manual deployment |
Instant Nova instance launch via pre-mapped Cinder storage |
|
Enterprise Scale |
Poor (Requires writing complex manual wrapper loops) |
Moderate (Requires executing serial individual CLI commands) |
High (Automated batch scheduling across multi-tenant Neutron networks) |
What are the main risks of enterprise-level OpenStack migration?
The primary risks are immediate system boot failures (kernel panics or BSODs) due to missing KVM VirtIO drivers, external routing disconnects from network mapping errors between vSphere switches and OpenStack Neutron, and operational delays caused by team skill gaps when transitioning to an API-driven cloud model.
How does OpenStack manage VMware persistent disks after migration?
OpenStack decouples persistent storage from the compute layer using Cinder. During migration, the flat .vmdk structure is converted into an open format (like QCOW2 or raw blocks), stored within distributed Ceph RBD storage pools, and attached to the newly provisioned Nova compute instance as an independent block volume.
Can native tools realize zero-downtime migration?
No. Native migration tools like virt-v2v and qemu-img cannot capture active RAM states or track runtime storage modifications. They require complete workload shutdowns (cold migration). True online replication requires an agent-based framework like i2Migration to sync block-level I/O changes live.
What is the recommended MTU value for migration scenarios?
An MTU value of 9000 (Jumbo Frames) is highly recommended across the physical network switch fabric and OpenStack Neutron overlays to prevent heavy packet drops and performance bottlenecks during massive virtual disk block transfers.
Can I migrate VMware templates directly to OpenStack Glance?
No, OpenStack Glance cannot natively parse proprietary VMware template configurations. You must first extract the base .vmdk disk file from the template, convert it to a cloud-optimized format like QCOW2 via qemu-img or virt-v2v, and then upload it to the Glance image registry.
Migrating from proprietary VMware virtualization to open-source OpenStack is a valuable infrastructure modernization project for enterprises.
Free open-source tools including virt-v2v and qemu-img are suitable for small-scale cold migration within scheduled maintenance windows, with low cost and simple operation. However, they cannot meet the high availability demands of core production business.
For mission-critical workloads that require 7×24 continuous operation, enterprise-grade replication tools such as i2Migration are the optimal choice. It guarantees business continuity and complete data integrity during the whole VMware to OpenStack live migration process.
