This website use cookies to help you have a superior and more admissible browsing experience on the website.
Loading...
By:
KVM and VMware use incompatible disk image formats. QCOW2 (QEMU Copy-On-Write) is the native format for KVM hypervisors, while VMware requires OVA — a single-file package containing the virtual disk (VMDK), machine configuration (OVF descriptor), and a manifest file.
Most teams run into this when moving VMs from a KVM setup to VMware, either to take advantage of VMware’s management tools or to consolidate infrastructure onto a single platform.
But there is no single command that handles this conversion directly. The process involves two stages: converting the disk format first, then packaging the result into an OVF-compliant archive.
This guide covers both stages for Linux and Windows, along with the most common errors that cause migrations to fail.
Skipping preparation is the most common reason VMs fail to boot after conversion. There are three things to check before converting QOCW2 to OVA: the tools on your host machine, the drivers inside the guest OS, and the boot mode of the source VM.
Make sure the following are in place before running any commands:
KVM virtual machines use VirtIO drivers for storage and networking. VMware does not recognize these, so the guest OS needs the correct drivers installed before conversion.
Check whether the source VM uses UEFI or legacy BIOS. The target VM in VMware needs to be configured to match. A mismatch here will prevent the operating system from starting after import.
Linux provides native support for all the tools needed for this process. The conversion runs in two stages: transforming the disk format with qemu-img, then packaging the result into an OVA using VMware OVF Tool.
Install qemu-img through your distribution’s package manager.
For Ubuntu or Debian:
sudo apt update && sudo apt install qemu-utils
For RHEL, CentOS, or Fedora:
sudo yum install qemu-img
Once installed, run the conversion:
qemu-img convert -f qcow2 -O vmdk source_image.qcow2 destination_disk.vmdk
The result is a VMware-compatible virtual disk. This file alone is not an OVA — it still needs to be imported into ESXi and packaged in the next steps.
Step 2: Import the VMDK into VMware ESXi
Upload the converted VMDK to your ESXi datastore, then build a VM around it.
Boot the VM and verify it starts correctly before moving to the next step.
Step 3: Export the VM as OVA Using OVF Tool
Once the VM is confirmed to boot in ESXi, use OVF Tool to package it. This step bundles the VMDK and OVF descriptor into a single portable archive, making the image ready for cloning or distribution.
Run the following command against your ESXi host or vCenter:
ovftool vi://username:password@esxi_ip/vm_name output_appliance.ova
Replace esxi_ip with your host’s IP address and vm_name with the name of the virtual machine as it appears in ESXi.
For large-scale migrations involving multiple VMs, V2V migration tools can simplify the process considerably.
Step 4: Verify the OVA
Run a probe check to confirm the archive is valid before deploying it:
ovftool --probe output_appliance.ova
If the command returns no errors, the OVA is ready to use. This catches issues like truncated files or malformed OVF descriptors before they cause problems in production.
Run the Conversion
The conversion command is the same as on Linux. On Windows, use double quotes around any path that contains spaces:
qemu-img.exe convert -f qcow2 -O vmdk "C:\Source VMs\image.qcow2" "C:\Target VMs\disk1.vmdk"
Once the conversion finishes, upload the VMDK to your ESXi datastore and configure it as a virtual machine, following the same steps covered in the Linux section above.
Install and Run OVF Tool on Windows
Download the OVF Tool Windows MSI installer from the VMware website and follow the installation prompts.
Once the VM is running in ESXi, use OVF Tool to package it as an OVA:
& "C:\Program Files\VMware\VMware OVF Tool\ovftool.exe" vi://root@192.168.1.10/MyMigratedVM "C:\Exports\MyVM.ova"
The & operator tells PowerShell to execute a program at a path that contains spaces. Without it, PowerShell treats the path as a string and the command fails.
Most conversion failures happen at one of two points: during the disk transformation, or when the VM first boots in VMware. The fixes below cover the most common causes.
A black screen or “No bootable device” error usually means the firmware setting in VMware does not match the source KVM VM. Go to VM Options > Boot Options and confirm the Firmware is set to match the source (UEFI or Legacy BIOS). If the OS still fails to load, check that the SCSI controller type in VMware is compatible with the drivers installed in the guest.
qemu-img does not fully support the streamOptimized subformat used by some VMware appliances. Add the -o subformat=monolithicSparse flag to convert to a standard monolithic sparse VMDK instead. If a streamOptimized output is specifically required, use OVF Tool to handle that format during the final export step.
A “Permission denied” error usually means the current user lacks read access to the QCOW2 file or write access to the destination directory. Run ls -l to check ownership, apply chmod 644 to the source file if needed, and confirm the destination directory is writable by your current user.
Disk size rounding during conversion can cause partition alignment issues, particularly with GPT partition tables. Set the target disk size in VMware to match the exact byte count of the source image. If partitions are still not recognized, boot from a Live ISO and use gdisk to repair the GPT headers.
Spaces in folder names are treated as argument separators by the command line, which causes an “Unexpected argument” error. Wrap all file paths in double quotes, for example "C:\VM Storage\image.qcow2".
Getting a VM into VMware is only half the job. Once the converted machine is running, it needs ongoing protection against accidental deletion, corruption, and hardware failure. The OVA file you created during migration is a point-in-time snapshot, not a backup strategy.
i2Backup fills that gap with agentless VM backup for VMware and other mainstream virtualization platforms. There is no agent to install inside the guest OS, and backups run without any impact on production workloads.
Key features relevant to VMware environments:
For environments where uptime is critical, i2Availability extends protection further with real-time replication and automated failover, keeping applications running even when a host goes down. If your migration also involves ongoing database replication across platforms, i2Stream handles real-time database sync with support for Oracle, MySQL, SQL Server, and other mainstream systems.
Q1: Can I convert QCOW2 to OVA directly?
No. OVA is a package format, not a disk image format, so there is no single command that handles the full conversion. The process requires converting the virtual disk to VMDK first, then bundling it with the necessary metadata using OVF Tool.
Q2: Does qemu-img support OVA output?
No. qemu-img handles virtual disk formats only, such as VMDK, RAW, and VHDX. It cannot generate the OVF descriptor files that define a virtual appliance. OVF Tool handles that step.
Q3: How do I convert QCOW2 to OVA on Windows?
Use the Windows build of qemu-img to convert the QCOW2 file to VMDK, upload the disk to an ESXi host, then use the Windows version of OVF Tool to export the VM as an OVA archive. The commands are the same as Linux; the main difference is path syntax and how you call the executables.
Q4: What’s the difference between OVA and OVF?
OVF (Open Virtualization Format) is a set of separate files: a descriptor file, the virtual disk, and a manifest. OVA (Open Virtualization Archive) packages all of those files into a single compressed archive for easier distribution and portability.
Q5: Why won’t my VM boot after converting to OVA?
The most common cause is a firmware mismatch. Check that the target VM in VMware is configured to use the same boot mode as the source, either Legacy BIOS or UEFI. Missing guest drivers are another frequent cause, which is why installing open-vm-tools or virtio-win before conversion is recommended.
Converting a QCOW2 image to OVA is a multi-step process, but each stage serves a clear purpose. qemu-img handles the disk format conversion, ESXi gives the VM a working environment, and OVF Tool packages everything into a portable archive. Getting the boot mode and guest drivers right before you start will prevent most of the errors that cause migrations to fail.
Once the VM is running in VMware, the next step is making sure it stays protected. The OVA you created is a starting point, not a safety net. Setting up regular agentless backups with Inf2soft’s i2Backup ensures you have clean recovery points from day one.
For teams managing larger environments, it is also worth reviewing how you backup your ESXi configuration alongside your VMs. Losing host-level settings during a failure can be just as disruptive as losing the workloads themselves.
