Tasked with looking for an alternative to VMware?
The OpenMetal team is standing by to assist you with scoping out an OpenStack based fixed-cost cloud to fit your budgets and timelines.
The ground shifted beneath the virtualization world when Broadcom announced licensing cost increases for VMware ESXi—by as much as 300%. This massive price hike caught organizations worldwide off guard, forcing an uncomfortable choice: pay the inflated costs or migrate to an alternative solution.
For system administrators who’ve built their careers around VMware, this decision carries weight beyond simple economics. You’re looking at retraining staff, learning new technologies, and managing the complex process of moving mission-critical workloads.
The good news? OpenStack emerges as a compelling alternative that offers both technical excellence and economic sense.
This guide (based on a video collaboration with LearnLinuxTV) walks you through the complete process of migrating virtual machines from VMware ESXi to OpenStack, using real-world examples and battle-tested approaches. Whether you’re evaluating your options or ready to begin the migration, you’ll discover that moving to OpenStack is more straightforward than it initially appears.
Why OpenStack Makes Sense for VMware Refugees
OpenStack stands out among virtualization alternatives for several compelling reasons. As an open-source platform, it eliminates the licensing uncertainty that VMware users now face. You gain control over your infrastructure costs while accessing enterprise-grade features that scale with your organization.
The platform’s architecture supports multi-tenancy natively, meaning you can host multiple companies or departments from a single OpenStack deployment. This capability alone often justifies the migration effort for organizations managing complex, segmented environments.
Perhaps most importantly, OpenStack skills are increasingly valuable in the job market. As more organizations migrate away from VMware, demand for OpenStack engineers continues growing. Learning this platform positions both you and your organization for long-term success.
Planning Your Migration Strategy
Before touching a single virtual machine, successful migrations start with proper planning. This isn’t about creating lengthy documentation—it’s about thinking through the process systematically to avoid costly mistakes.
Start by cataloging every VM in your VMware environment. During this inventory process, identify virtual machines you no longer need. Migration projects present perfect opportunities to audit your infrastructure and eliminate unused resources. Why waste time migrating servers you’ll decommission anyway?
Next, determine migration order strategically. Begin with your least critical systems—test servers, development environments, or staging platforms. These systems give you hands-on experience with the migration process without risking production workloads. Each successful migration builds your confidence and refines your procedures.
Consider downtime requirements carefully. While the migration process itself shouldn’t cause extended outages, DNS propagation and network changes can create temporary inconsistencies. Communicate with users about potential intermittent issues during transition periods.
Critical Best Practices That Prevent Disasters
One best practice deserves immediate attention because it prevents a specific type of chaos: after successfully migrating a VM, immediately shut down the original VMware instance. More than shutting it down—ensure it cannot automatically restart.
This prevents “split-brain” scenarios where both the old and new versions of a server operate simultaneously. Users or applications might connect to either instance randomly, creating data consistency nightmares. This situation sounds unlikely until you experience it firsthand and spend hours untangling the resulting mess.
Prepare your DNS infrastructure before migration day. Set Time to Live (TTL) values for your servers’ DNS entries to five minutes, and do this several days before starting migrations. Lower TTL values help users and applications switch to new IP addresses faster, minimizing service disruption.
Document everything as you progress. Your first migration teaches lessons that make subsequent moves smoother. Notes about timing, unexpected issues, and successful workarounds become invaluable when migrating your next batch of servers.
Exporting Virtual Machines from ESXi
The migration process begins within your VMware ESXi environment. You’ll need administrative access to the ESXi host or vCenter managing your target virtual machines.
Start by cleanly shutting down the VM you want to migrate. Avoid forced shutdowns unless absolutely necessary—clean shutdowns ensure data consistency and reduce complications during the import process.
Once the VM stops completely, right-click on it within the ESXi interface and select “Export.” This creates a complete backup of the virtual machine as downloadable files. The export includes the virtual disk (VMDK format), VM configuration files, and metadata describing the machine’s hardware configuration.
The export process duration depends on your virtual disk size and network connection speed. A 50GB VM might take 30 minutes over a gigabit connection, while larger systems require correspondingly more time. Plan accordingly, especially if you’re migrating during business hours.
Save the exported files to a location accessible from your conversion workstation. You’ll need these files for the next step: format conversion.
Converting Virtual Disks for OpenStack
OpenStack natively supports QCOW2 disk format, while VMware exports use VMDK format. Converting between these formats requires the qemu-img utility, available on most Linux distributions.
Set up a Linux workstation or server for this conversion process. If you’re working from a Windows environment, consider spinning up a temporary Linux VM specifically for format conversion tasks. On Debian-based systems, install the required package:
sudo apt install qemu-utils
Copy your exported VMDK files to this Linux system using SCP, SFTP, or your preferred file transfer method. Then convert the disk image using qemu-img:
qemu-img convert -f vmdk -O qcow2 original-server.vmdk converted-server.qcow2
The conversion process transforms the VMware disk format into OpenStack’s preferred QCOW2 format while preserving all data, installed software, and configurations. Conversion time varies with disk size—expect roughly 2-3 minutes per gigabyte on modern hardware.
Monitor disk space during conversion. The process temporarily requires storage space for both original and converted files. Ensure your conversion system has adequate free space before starting large migrations.
Importing Images into OpenStack
With your converted QCOW2 file ready, you’ll import it into OpenStack through the Horizon dashboard. This web-based interface provides the most straightforward approach for administrators new to OpenStack.
Log into your OpenStack Horizon dashboard and navigate to Compute > Images. Click “Create Image” to begin the import process.
Provide a descriptive name and description for your image. Use naming conventions that clearly identify the source (VMware migration), purpose, and any relevant version information. Clear naming prevents confusion when managing multiple imported images.
Set the format to QCOW2 and use the “Choose File” button to select your converted disk image. Specify the minimum disk size to match your original VM’s disk capacity. If your VMware VM used a 32GB disk, set the minimum disk to 32GB.
The upload process transfers your disk image to OpenStack’s image storage (Glance). Upload time depends on file size and network connectivity between your workstation and OpenStack environment. Monitor the progress and avoid interrupting the process once started.
Launching Your Migrated Instance
After successful image import, you’re ready to create a new virtual machine instance from your migrated disk. Navigate to Compute > Instances and click “Launch Instance.”
Select the appropriate project if you manage multiple tenants within OpenStack. Provide an instance name—consider using the same name as your original VMware VM to maintain consistency across environments.
In the Source tab, select “Image” as your boot source and choose the QCOW2 image you imported. Set the volume size to match your original disk capacity if it isn’t automatically populated.
Choose a flavor that matches your original VM’s specifications. OpenStack flavors define CPU, memory, and disk allocations. If you don’t have a flavor matching your VMware VM exactly, select the closest option or create a custom flavor through the admin interface.
Configure networking by selecting the appropriate network for your instance. If you’re unsure which network to choose, consult your OpenStack administrator or use the default network for initial testing.
Security groups control network access to your instance. Select groups that allow necessary traffic—typically SSH (port 22) for Linux systems, RDP (port 3389) for Windows, and any application-specific ports your service requires.
Review your configuration and click “Launch Instance.” OpenStack begins provisioning your virtual machine using the migrated disk image. The process typically completes within a few minutes, depending on your OpenStack environment’s performance.
Testing and Validation
Once your instance reaches “Active” status, verify the migration succeeded completely. Access the console through Horizon’s web interface or connect via SSH/RDP depending on your operating system.
Check that all your applications, configurations, and data transferred correctly. Look for the specific files, services, and configurations that were present in your original VMware VM. This validation confirms that the disk-level migration preserved everything as expected.
Test network connectivity, application functionality, and any integrated services. Some applications might require minor configuration adjustments to work with new IP addresses or network configurations, but the core system should function identically to the original.
If you discover issues during testing, don’t panic. Common problems include network configuration mismatches or driver compatibility issues. These typically require minor adjustments rather than complete re-migration.
Managing DNS and Network Transitions
With your OpenStack instance tested and validated, you’re ready for the final transition step: updating DNS records and switching traffic to the new server.
Update your DNS records to point to the OpenStack instance’s IP address. If you followed the earlier advice about lowering TTL values, this change propagates to clients within five minutes. Without low TTL values, propagation might take hours depending on your DNS configuration.
After updating DNS, wait for the TTL period to expire before proceeding. You can verify propagation using tools like nslookup or dig from various network locations to confirm clients receive the new IP address.
Only after confirming DNS propagation should you shut down the original VMware instance. This sequence prevents the split-brain scenario mentioned earlier while ensuring service continuity during the transition.
Scaling Your Migration Approach
Once you’ve successfully migrated your first VM, you can scale the process for your entire environment. The steps remain identical: export, convert, import, and launch. However, you might discover opportunities to streamline bulk migrations.
For environments with many similar systems, consider creating standardized images. Instead of migrating each identical web server individually, migrate one representative system and use it as a template for deploying multiple instances.
Automation tools like Terraform, Heat, or Ansible can help manage large-scale migrations. These tools handle the repetitive aspects of launching instances, configuring networks, and updating DNS records.
Alternative Approach: Bulk Spawning from Images
For organizations managing many similar systems, bulk spawning from images offers an alternative to individual VM migrations. This approach works best when you don’t need to preserve exact runtime states and can standardize on common base images.
The process involves exporting template or “golden” images from VMware, converting them to QCOW2 format, and using automation tools to spawn multiple instances from these standardized images. While you lose any unique runtime configurations, you gain deployment speed and standardization benefits.
Consider bulk spawning when migrating development environments, web server farms, or any infrastructure where standardization outweighs preserving individual system quirks.
Choosing Your Migration Method
Your migration approach depends on your specific requirements:
Choose individual VM migration when:
- VMs contain critical in-memory states
- Systems have unique, complex configurations
- You need to preserve every aspect of the current environment
- You’re migrating a small number of specialized servers
Choose bulk spawning when:
- Managing many similar systems
- Standardization is more important than preserving unique configurations
- You’re refreshing your environment with updated, standardized images
- Systems are stateless or easily reconfigurable
Common Challenges and Solutions
Several challenges commonly arise during VMware to OpenStack migrations. Understanding these issues helps you prepare and respond effectively.
Driver compatibility sometimes causes problems, particularly with Windows systems. OpenStack uses different virtual hardware than VMware, potentially requiring driver updates after migration. Prepare Windows systems by installing virtio drivers before migration when possible.
Network configuration mismatches can disrupt connectivity. VMware and OpenStack might use different network interface naming conventions or IP assignment methods. Document your network configurations before migration and be prepared to make adjustments.
Performance differences between platforms occasionally surprise administrators. OpenStack performance characteristics differ from VMware, potentially requiring tuning for optimal results. Monitor your migrated systems and adjust resource allocations as needed.
Building OpenStack Expertise
Successful migration to OpenStack requires developing new skills and knowledge. While the basic migration process is straightforward, managing OpenStack effectively requires understanding its architecture, networking model, and operational procedures.
Consider formal training or certification programs to build OpenStack expertise within your team. The investment in education pays dividends in smoother operations and more effective use of the platform’s capabilities.
OpenStack’s community provides extensive documentation, forums, and support resources. Engage with this community to learn best practices, troubleshoot issues, and stay current with platform developments.
Working with OpenStack Providers
Setting up and managing OpenStack infrastructure requires significant expertise and resources. Many organizations find success partnering with specialized providers who offer hosted OpenStack environments.
These providers handle the underlying infrastructure complexity while giving you full access to OpenStack’s capabilities. This approach lets you focus on migration and application management rather than infrastructure deployment and maintenance.
When evaluating providers, consider their OpenStack expertise, support quality, and alignment with your technical requirements. Look for providers who actively contribute to the OpenStack community and demonstrate deep platform knowledge.
Conclusion
Migrating from VMware ESXi to OpenStack represents more than a response to licensing cost increases—it’s an opportunity to modernize your infrastructure on an open, scalable platform. The migration process, while requiring careful planning and execution, is more straightforward than many administrators initially expect.
Start with proper planning, follow established best practices, and begin with non-critical systems to build experience. Each successful migration builds confidence and refines your procedures for subsequent moves.
OpenStack offers the technical capabilities, economic advantages, and long-term viability that make migration efforts worthwhile. With proper preparation and execution, you can successfully transition your infrastructure while building valuable skills for the future.
The virtualization landscape continues evolving, and OpenStack positions your organization to adapt and thrive regardless of vendor decisions or market changes. Your migration journey begins with a single VM—and that first successful move opens the door to transforming your entire infrastructure.
Ready to start your VMware to OpenStack migration? OpenMetal provides complete OpenStack environments with expert support to make your transition smooth and successful. Their team specializes in helping organizations migrate from VMware while building the skills needed for long-term OpenStack success.