Turn VMware dependency into a controlled OpenStack roadmap
We qualify what can move, prove the target with a representative pilot, then industrialize migration waves with acceptance and rollback plans. The objective is not a format conversion: it is a stable operating model your team can own.
- 1QualificationInventory of guests, disks, firmware, network dependencies and licences; eligibility matrix per VM.
- 2Representative pilotReal workloads covering several risk profiles, measured windows, tested rollback.
- 3Industrialized wavesConversion with VirtIO drivers, Glance and Cinder integration, network mapping, application acceptance.
- 4Cutover and stabilizationSource VM kept intact until acceptance; storage, network and cost tuning on the OpenStack side.
A structured path from VMware to OpenStack
VM inventory and dependencies
We identify workloads, topology, storage, and network dependencies before conversion.
Conversion and validation
We convert disks, inject VirtIO drivers when needed, and validate the VM in the OpenStack target environment.
Cutover and optimization
After cutover, we fine-tune storage, networking, and workloads for production stability and cost efficiency.
Decisions made before the pilot
Workload eligibility, target flavors, network mapping, storage strategy, Windows and Linux driver readiness, migration windows, acceptance criteria and rollback thresholds.
Deliverables you keep
Dependency inventory, migration factory scripts, pilot report, wave plan, cutover and rollback runbooks, acceptance records and operating documentation.
Why organisations are leaving VMware now
Unpredictable licensing costs
The shift to per-core subscription bundles has sharply increased virtualization budgets and removed pricing visibility. OpenStack eliminates hypervisor licensing and puts the budget trajectory back under your control.
Sovereignty and reversibility
Open standards, documented APIs, no single-vendor dependency. Your data and your control plane stay under your own governance, on infrastructure you can audit and reverse.
A production-proven ecosystem
KVM, Ceph and OVN are open source building blocks operated at scale by the largest cloud providers, backed by an active community and a broad skills market.
VMware to OpenStack component mapping
Every VMware capability has an OpenStack counterpart. Knowing the mapping early avoids designing the target as a copy of the source.
| VMware component | OpenStack equivalent | Migration notes |
|---|---|---|
| ESXi / vSphere | Nova + KVM/QEMU | VirtIO drivers required in guests for disk and network performance |
| vCenter | Horizon + CLI/APIs OpenStack | Multi-tenant model with projects, quotas and role-based access |
| vSAN / datastores VMFS | Ceph RBD via Cinder + Glance | RAW format optimal for Ceph, native thin provisioning and snapshots |
| NSX / vDS | Neutron + OVN/OVS | Security groups replace distributed firewall rules; plan the flow matrix |
| vMotion | Live migration Nova | Requires shared storage such as Ceph across compute nodes |
| vSphere HA | Masakari | Automatic instance evacuation on compute node failure |
| DRS | Nova scheduler + Watcher | Initial placement plus continuous optimisation policies |
| vROps / vRealize | Prometheus + Grafana + Alertmanager | Service-oriented alerting and dashboards built with the platform |
| Templates / Content Library | Images Glance + Heat / Terraform | Versioned, automated image pipeline instead of manual templates |
Two field-proven migration paths
These are the two migration paths we industrialize most often. The choice is made during qualification, per workload profile; the command-by-command procedures are published in our technical guides.
Path A: direct conversion with virt-v2v
vCenter ➔ CinderAutomated tooling that connects to vCenter, converts the guest OS, injects VirtIO drivers and creates the Cinder volumes directly in OpenStack. The preferred path for Windows fleets and standard Linux distributions.
Technical guide: virt-v2v procedure →Path B: vSphere export and Glance import
OVF ➔ GlanceThe standard, fully controllable procedure: export ESXi disks, convert them offline, then ingest into Glance and Cinder. Ideal for air-gapped environments and scripted bulk migrations.
Technical guide: export and import procedure →When to prefer virt-v2v
Windows guests needing VirtIO driver injection, standard Linux distributions, direct network path between vCenter and the conversion node, and teams looking for maximum automation per VM.
When to prefer export and convert
Air-gapped or strictly segmented environments, non-standard guests, full control over each intermediate artefact, and bulk migrations scripted into a repeatable migration factory.
The pitfalls we neutralize before they occur
Windows VirtIO drivers
Without VirtIO storage drivers injected before first boot, Windows guests crash on startup. We inject and verify drivers as part of the conversion, not after.
IP and MAC preservation
Application licences, firewall rules and hardcoded configurations often depend on addresses. Neutron ports are created with fixed IP and MAC when continuity requires it.
VMware Tools removal
Leftover VMware Tools degrade the migrated guest. They are removed before export and replaced by the qemu-guest-agent for clean OpenStack integration.
UEFI versus BIOS boot
A UEFI guest booted in BIOS mode simply fails. Firmware type is inventoried per VM and pinned on the Glance image with hw_firmware_type.
Multi-terabyte volumes
Large disks stretch export windows considerably. We stream conversions directly into Ceph RBD and size cutover windows against measured throughput, not estimates.
Snapshots and CBT chains
Unconsolidated snapshot chains corrupt or bloat exports. Snapshots are consolidated and backup integrations paused before any disk leaves vSphere.
Frequently asked questions
How much downtime should we expect per VM?
The window covers export, conversion and first boot, so it mostly depends on disk size and available throughput. Waves are planned per application, large volumes are streamed directly into Ceph, and each window is validated on the pilot before being committed.
Are Windows virtual machines supported?
Yes. virt-v2v injects the VirtIO drivers during conversion and the guest boots on KVM without manual intervention. Activation and licensing impacts are checked during qualification, before the migration wave.
What happens if a VM does not start on OpenStack?
The source VM is kept intact on vSphere until acceptance is signed. Rollback is a documented, tested runbook: restart the source, reconnect flows, log the deviation and feed it back into the eligibility matrix.
Do we have to migrate everything?
No. The qualification produces an eligibility matrix separating direct migration, prior remediation, rebuild on the target and retirement. Exceptions become explicit programme decisions instead of late surprises.
Who operates the platform after the migration?
Your team. Runbooks, automation, observability and acceptance records are delivered and transferred through pairing sessions, so the operating model does not depend on us once production is stable.
Ready to build your VMware exit roadmap?
A representative pilot removes uncertainty before any programme commitment: real workloads, measured windows, tested rollback.