virt-v2v Guide: Easily Convert Virtual Machines from VMware, Hyper-V to KVM – ITFROMZERO

Introduction: The Common Worry When “Moving House” for Virtual Machines

In today’s IT world, managing diverse virtualization platforms has become commonplace. Perhaps you are managing an enterprise environment with VMware vSphere, but want to leverage the flexibility and open-source nature of KVM on Linux servers.

Or more simply, like me, you have a homelab running Proxmox VE managing dozens of VMs and containers – this is the ideal playground to test everything before putting it into production. Moving virtual machines between platforms is a daily occurrence, but it’s not always smooth sailing.

The biggest problem many people face is how to migrate a virtual machine (VM) running on VMware ESXi or Hyper-V to a KVM environment (or Proxmox VE – a KVM-based platform). How to do this without data corruption, lost configurations, or having to reinstall from scratch? If the system is complex, this can take hours, even days of work, accompanied by the risk of unforeseen errors.

Why is Virtual Machine Conversion Complex?

Migrating a virtual machine directly from one platform to another is like trying to plug an electronic device from Japan (using 100V electricity) into an outlet in Vietnam (using 220V electricity) without a converter. It won’t work, or worse, it will cause damage. The main reason is the fundamental differences in architecture and how hypervisors manage virtual machines:

Virtual Disk Formats: VMware uses VMDK, Hyper-V uses VHD/VHDX, while KVM typically uses QCOW2 or RAW. These formats are not directly compatible.
Virtual Hardware: Each hypervisor emulates different virtual hardware devices. A VMware virtual machine might see an E1000 or VMXNET3 network card, while KVM prioritizes VirtIO for high performance.
Guest OS Drivers: The operating system inside the VM usually installs specific drivers for the virtualization environment it’s running on (e.g., VMware Tools for VMware, Hyper-V Integration Services for Hyper-V). When migrating to a new platform, these drivers may become useless or cause conflicts, preventing the VM from booting or performing efficiently.
Bootloader Configuration: Some changes in virtual hardware can affect the boot process of the guest operating system.

These differences make it impossible to “lift and shift” a virtual machine to a new platform, or it requires many manual adjustments.

Existing Virtual Machine Migration Options

Before we get to the optimal solution, let’s review some other common approaches and their limitations:

1. Recreate from Scratch

This is the simplest way in theory: You create a new virtual machine on the KVM platform. Then, reinstall the operating system, all applications and configurations, and finally migrate data from the old VM.

Advantages: Ensures a clean system, fully optimized for the new KVM environment.
Disadvantages: Extremely time-consuming and labor-intensive, especially for virtual machines with complex installations, many software applications, or those requiring specific system settings to be maintained. This process can take tens of hours of work and carries a very high risk of errors.

2. Manual Disk Conversion with `qemu-img convert`

The qemu-img convert tool is very useful for changing virtual disk file formats. For example, you can convert a .vmdk file (VMware) to .qcow2 (KVM) as follows:


qemu-img convert -f vmdk -O qcow2 /path/to/source_vm.vmdk /path/to/destination_vm.qcow2

Advantages: Simple, quick for changing disk formats.
Disadvantages: This is only half the problem! qemu-img convert only handles disk file formats; it does not interfere with the operating system inside to remove old drivers or inject new ones. After you have the new disk file, you still have to manually create the VM on KVM, attach the disk, and struggle with driver and bootloader issues to get the VM to boot and operate stably.

3. Proprietary Tools

Some vendors offer their own conversion tools, such as VMware vCenter Converter Standalone. This tool does a fairly good job of P2V (Physical to Virtual) or V2V (Virtual to Virtual) conversion within the VMware ecosystem.

Advantages: Highly effective when converting between products from the same vendor.
Disadvantages: Often limited when you want to migrate to a different platform (e.g., from VMware to KVM), easily leading to “vendor lock-in.”

virt-v2v: The Optimal Solution for Virtual Machine Migration

When faced with the complexity of migrating virtual machines between hypervisors, virt-v2v emerges as a savior. This is a tool I frequently use to prepare VMs before bringing them into my Proxmox environment.

What is virt-v2v?

virt-v2v is a powerful open-source tool, part of Red Hat’s libguestfs project. Its primary goal is to convert virtual machines from other hypervisors (such as VMware ESXi, Hyper-V, Xen) to a format compatible with KVM/libvirt. What’s special about virt-v2v is that it doesn’t just convert disk formats; it also intelligently “intervenes” in the guest OS to:

Remove old hypervisor-specific drivers and tools (e.g., VMware Tools, Hyper-V Integration Services).
Inject necessary drivers for the new KVM environment, especially VirtIO drivers to optimize I/O and network performance.
Adjust bootloader and network configurations to ensure the VM can boot and connect to the network immediately after conversion.

Thanks to this capability, virt-v2v makes the conversion process much smoother and more automated than manual methods.

Why Use virt-v2v?

High Automation: Significantly reduces manual steps after disk conversion, potentially saving up to 80% of time compared to manual methods.
Reduced Errors: The ability to handle guest OS drivers and configurations helps avoid many boot and operational errors.
Diverse Support: Supports conversion from multiple sources (VMware, Hyper-V, Xen) to KVM.
Open Source: Developed and maintained by the community, reliable and flexible.

Preparation Before “Departure”

For a smooth conversion process, you need to prepare a few things:

System Requirements

A Linux server (preferably CentOS/RHEL/Ubuntu Server) with KVM/libvirt installed and sufficient resources (RAM, CPU, disk space) to host the new virtual machine.
Ensure network connectivity to the source virtual machine (if the source VM is on ESXi or Hyper-V on another server).

Installing virt-v2v

virt-v2v is usually included in the libguestfs-tools-c (or libguestfs-tools) package.

On CentOS/RHEL/Fedora:


sudo yum install libguestfs-tools-c -y
# Or with Fedora/CentOS 8+:
sudo dnf install libguestfs-tools-c -y

On Ubuntu/Debian:


sudo apt update
sudo apt install libguestfs-tools -y

Check the version to ensure successful installation:


virt-v2v --version

Preparing the Source VM

This step is extremely important to avoid post-conversion errors:

Remove old drivers: If it’s a VMware VM, uninstall VMware Tools. If it’s a Hyper-V VM, uninstall Hyper-V Integration Services. (On Linux, sometimes complete uninstallation is not necessary, just ensure they don’t cause conflicts).
Update the operating system: Ensure the guest operating system is fully updated with the latest patches.
Network configuration: If possible, change the guest OS’s network configuration to DHCP to easily obtain a new IP address in the KVM environment. If not, remember the static IP configuration to re-establish it later.
Completely shut down the virtual machine: Make sure the source VM is shut down, not suspended.
Back up data: Always back up important VM data before performing any conversion operation.

Practicing Virtual Machine Conversion with virt-v2v

Now, let’s move on to the main part: the actual commands to convert virtual machines.

Scenario 1: Converting from VMware ESXi to KVM

In this scenario, virt-v2v will connect directly to your ESXi host to retrieve VM data.


# Recommended to set direct backend for increased performance
export LIBGUESTFS_BACKEND=direct

# Convert from ESXi
sudo virt-v2v -ic esx://esxi_user@esxi_host/VM_NAME \ 
             -o libvirt -os /var/lib/libvirt/images/ \ 
             -of qcow2 --network bridge_name \ 
             NEW_VM_NAME

Explanation of parameters:

-ic esx://esxi_user@esxi_host/VM_NAME: Specifies the source as a VMware virtual machine on ESXi. Replace esxi_user with a user account with access rights (e.g., root), esxi_host with the IP address or hostname of the ESXi, and VM_NAME with the exact name of the virtual machine on ESXi. When running the command, you will be prompted for the ESXi password.
-o libvirt: Specifies that the output will be imported into libvirt (KVM management system).
-os /var/lib/libvirt/images/: Path to the directory containing KVM virtual disk files.
-of qcow2: The output virtual disk file format is QCOW2 (this is a flexible and common KVM format).
--network bridge_name: Attaches the new VM’s virtual network card to a specific network bridge on your KVM host (e.g., virbr0, br0). If not specified, libvirt will use the default bridge.
NEW_VM_NAME: The new name you want to give the virtual machine after conversion on KVM.

If you already have a VMDK file: If you have exported the VMware virtual machine to a .vmdk file (e.g., from VMware Workstation or copied from an ESXi datastore), you can convert directly from that file:


export LIBGUESTFS_BACKEND=direct
sudo virt-v2v -i vmw /path/to/source_vm.vmdk \ 
             -o libvirt -os /var/lib/libvirt/images/ \ 
             -of qcow2 --network bridge_name \ 
             NEW_VM_NAME

-i vmw /path/to/source_vm.vmdk: Specifies the source as a VMDK file.

Scenario 2: Converting from Hyper-V to KVM

For Hyper-V, the best approach is to first export the virtual machine from Hyper-V Manager to a directory. Then, virt-v2v will work with the exported .vhdx file.


export LIBGUESTFS_BACKEND=direct
sudo virt-v2v -i hyperv /path/to/exported/hyperv_vm/Virtual\ Hard\ Disks/source_vm.vhdx \ 
             -o libvirt -os /var/lib/libvirt/images/ \ 
             -of qcow2 --network bridge_name \ 
             NEW_VM_NAME

-i hyperv /path/to/exported/hyperv_vm/Virtual\ Hard\ Disks/source_vm.vhdx: Specifies the source as a VHDX file from the exported Hyper-V directory. Make sure the path to the VHDX file is correct.

Some Useful Advanced Options

virt-v2v provides many options to fine-tune the conversion process. Here are a few examples:

--disk DISK_PATH: If the VM has multiple disks and you only want to convert a specific disk.
--cpu TYPE: Specifies the virtual CPU type for the new VM.
--memory AMOUNT: Specifies the RAM amount (e.g., --memory 4096 for 4GB).
--mac MAC_ADDRESS: Assigns a specific MAC address to the network card.
--dry-run: Runs the command in dry-run mode to see what virt-v2v would do without actually making any changes. Very useful for pre-checks.

Advanced example, converting a VM from ESXi with 8GB RAM and attaching it to bridge br0:


export LIBGUESTFS_BACKEND=direct
sudo virt-v2v -ic esx://esxi_user@esxi_host/VM_NAME \ 
             -o libvirt -os /var/lib/libvirt/images/ \ 
             -of qcow2 --network br0 --memory 8192 \ 
             NEW_VM_NAME

Post-conversion Steps

After virt-v2v completes, you will have a new KVM virtual machine. However, a few small checks and adjustments are still necessary to ensure everything works perfectly:

Start and test the new virtual machine:

Use virt-manager (graphical interface) or virsh (command line) to start and access the VM. For example, with virsh:
```
virsh list --all              # List all VMs
virsh start NEW_VM_NAME       # Start the new VM
virsh console NEW_VM_NAME     # Access the VM console (requires serial console configuration in the guest OS)
```
Observe the boot process and check for any errors displayed on the screen.
Install virtio drivers (for Windows VMs):

If you converted a Windows virtual machine, virt-v2v might have injected basic VirtIO drivers. However, you should install the VirtIO-Win ISO package to have the most optimal drivers for KVM (disk, network, ballooning, etc.).
Network configuration:

Ensure the new VM receives the correct IP address, can access the internet, and other network resources. If you are using a static IP, reconfigure it within the guest OS.
Remove old software:

Check inside the guest OS and completely remove any unnecessary software packages and drivers from the old hypervisor (e.g., VMware Tools if not already removed). This helps reduce resource consumption and avoid conflicts.
Optimize the guest operating system:

For Linux VMs, you can check /etc/fstab to ensure mount points use the correct new UUID/label if there are changes. Ensure the kernel in use is a standard kernel or has been optimized for KVM.
Create Snapshot:

Immediately after the new VM is stable and thoroughly tested, create a snapshot. This provides a safe recovery point if any issues arise in the future.

Conclusion: Optimizing Virtual Infrastructure with virt-v2v

virt-v2v is an extremely valuable tool that simplifies one of the most complex tasks in virtual infrastructure management: migrating virtual machines between different platforms. It not only saves hours, even days of effort, but also reduces the risk of errors, allowing you to fully leverage the benefits of KVM without having to recreate the entire system.

For IT admins considering migrating from paid platforms to KVM/libvirt, or for those like me exploring homelabs with various hypervisors, virt-v2v is an indispensable tool. Always remember, no matter how smart the tool, data backup remains the top priority before any major changes!