VMware Workloads After Moving Hypervisors

When you move existing VMware workloads to another hypervisor, the virtual machines (VMs) are converted to a new format and then run on the new platform, but the guest operating system, applications, and data inside each VM remain unchanged. The process typically involves exporting each VM from VMware (often as OVF/OVA or via a dedicated migration tool), converting the virtual disk and configuration to the target hypervisor’s format, and then importing and starting the VM on the new host. The result is that your workloads keep running, but their underlying virtualization layer changes, which has implications for performance, management, and licensing.

Why People Move Off VMware

Organizations migrate away from VMware for several reasons. Cost is a major driver: VMware’s licensing model charges per CPU socket or per core, which can become expensive as hosts scale. Some IT teams also want to consolidate onto a single hypervisor if they already run a mix of platforms, or they prefer the open-source or included-in-the-OS options like KVM (part of Linux) or Hyper-V (part of Windows Server). Others move to take advantage of different management tools, better integration with cloud providers, or to avoid vendor lock-in. Whatever the reason, the migration itself is a well-trodden path, but it requires planning to avoid downtime and data loss.

How VM Conversion Works

VMware VMs are stored as a set of files: a .vmx configuration file, one or more .vmdk virtual disk files, and additional files for snapshots, logs, and memory state. Other hypervisors use different formats—Hyper-V uses .vhdx, KVM uses .qcow2 or raw images, and Xen uses its own formats. The conversion process reads the VMware disk image, copies the data block-by-block into the new format, and creates a new configuration file that matches the target hypervisor’s syntax.

There are two main approaches:

• Offline conversion: The VM is shut down before conversion. This ensures data consistency but causes downtime. Tools like qemu-img (for KVM) or Microsoft’s Virtual Machine Converter can perform this.
• Live migration: The VM keeps running while the data is copied, then a brief pause occurs to sync the final changes. This minimizes downtime. Commercial tools like StarWind V2V Converter or Zerto support this, but they often require a license.

During conversion, the virtual hardware is recreated: the virtual network adapter changes from VMware’s vmxnet3 to the target’s equivalent (e.g., virtio for KVM, or the Hyper-V synthetic adapter), and the SCSI controller may change from VMware’s paravirtualized controller to a standard one. The guest OS usually needs drivers for the new hardware to boot properly, which is why most conversion tools inject the necessary drivers automatically.

What Actually Changes for the Workload

The guest OS and applications are essentially unaware of the hypervisor swap—they see the same virtual CPU, memory, and disk. However, a few things do change:

• Virtual hardware drivers: The OS must have drivers for the new virtual devices. Without them, the VM may fail to boot or have no network connectivity. Modern conversion tools handle this, but it’s a common source of post-migration issues.
• Performance characteristics: The new hypervisor’s scheduler, memory management, and I/O stack differ. You may see slightly different CPU or disk performance, though modern hypervisors are broadly comparable. For latency-sensitive workloads, it’s worth benchmarking after migration.
• Management and monitoring: You lose VMware-specific tools like vSphere HA, DRS, and vMotion. You’ll need to adopt the new platform’s equivalents (e.g., Hyper-V Live Migration, KVM’s live migration with libvirt). Monitoring agents that were VMware-specific (like those using vSphere APIs) need to be replaced.
• Licensing: The guest OS licenses are tied to the VM, not the hypervisor, so they remain valid. However, if you had VMware-specific licensing for third-party software (e.g., backup agents), you may need to switch to versions that support the new hypervisor.

Common Migration Problems and How to Avoid Them

Most migration issues fall into a few categories:

1. Missing drivers: The VM boots to a black screen or blue screen because the storage or network controller isn’t recognized. Solution: use a conversion tool that injects drivers, or manually add the drivers to the VM before migration.
2. Corrupted data: If the VM is powered on during conversion without proper snapshotting, the disk may be inconsistent. Always shut down the VM or use a tool that takes a VMware snapshot first.
3. IP address conflicts: If the new VM starts on the network before the old one is fully decommissioned, you’ll have duplicate IPs. Plan the cutover to shut down the old VM first.
4. UEFI vs BIOS: If the VM uses UEFI boot and the target hypervisor doesn’t support it (or vice versa), the VM won’t boot. Check the firmware type before conversion.

To avoid these, test the migration on a non-production VM first, and always have a rollback plan (keep the original VMware files until the new VM has run successfully for a few days).

How to Choose a Migration Method

The right method depends on your environment and tolerance for downtime:

• Manual export/import: Export each VM as OVF from vSphere, then import it into the target hypervisor. This is free but requires downtime and manual driver fixes. It works for small environments.
• Free conversion tools: qemu-img can convert VMDK to QCOW2 or raw. Microsoft’s Virtual Machine Converter (MVMC) converts VMware to Hyper-V. These are free but typically require the VM to be off.
• Commercial migration tools: Products like StarWind V2V Converter, Zerto, or vCenter Converter (which is free but only to VMware) offer live migration, automated driver injection, and parallel migration of many VMs. They cost money but reduce downtime significantly.

For a large environment, consider a phased approach: migrate test VMs first, then less critical workloads, and finally production. Use a checklist to verify each VM’s OS boots, network is reachable, and applications respond.

Cost and Licensing Considerations

Moving off VMware can save on hypervisor licensing, but it’s not free. You’ll need to factor in:

• Migration tools: Free tools work, but commercial ones may cost per VM or per socket.
• Training: Your admins need to learn the new platform’s management tools.
• Third-party software: Backup, monitoring, and security tools may require new licenses if they don’t support the new hypervisor.
• Support contracts: If you use paid support for VMware, you’ll cancel that, but you may need support for the new hypervisor (e.g., Red Hat or SUSE for KVM, Microsoft for Hyper-V).

In many cases, the total cost of ownership decreases because the hypervisor itself is free (KVM, Hyper-V is included with Windows Server), but the operational costs can offset some of that. Do a thorough cost analysis before committing.

Frequently Asked Questions

Will my applications break after moving to another hypervisor? Usually no, because the guest OS and applications are abstracted from the hypervisor. However, if the conversion doesn’t inject proper drivers, the OS may not boot. Also, any application that relies on VMware-specific features (like VMtools) may need reconfiguration.

Can I move a VM from VMware to Hyper-V without downtime? Yes, with live migration tools like StarWind V2V Converter or Zerto. These tools copy the disk while the VM runs, then do a final sync with a brief pause. Without such tools, you’ll need to shut down the VM.

What happens to VMware snapshots during migration? Snapshots are typically not migrated. The conversion tool creates a flat copy of the current disk state, effectively merging all snapshots. If you need to keep snapshots, you’ll need to recreate them on the new hypervisor, but it’s usually better to consolidate them before migration.

Do I need to relicense my Windows Server guest OS after moving? No, the Windows license is tied to the VM, not the hypervisor. However, if you have a license that is tied to the physical host (like some OEM licenses), you may need to reactivate. Always verify with Microsoft’s licensing rules.

Can I move back to VMware later? Yes, the process is reversible. You can export from the new hypervisor (e.g., as OVF) and import into VMware. However, you’ll face similar driver and configuration issues, so keep your VMware templates updated.

Is it safe to delete the original VMware files after migration? Only after you’ve verified the new VM runs correctly for a few days. Keep the original files as a rollback option, especially for critical workloads. Once you’re confident, you can delete them to free up storage.

Related

• Feet and Inches to Millimeters Calculator
• Temperature Degrees Calculator: Convert °C, °F and K
• Convert Grams to Centigrams: Formula and Examples