This website use cookies to help you have a superior and more admissible browsing experience on the website.
Loading...
By:
Moving a virtual appliance from VMware or VirtualBox to a KVM-based platform means dealing with one immediate problem: format incompatibility. Your exported OVA file won’t work directly on Proxmox, a KVM host, or an EVE-NG lab — each of these expects a QCOW2 image instead.
This guide walks through the full conversion process on Linux, Windows, and Proxmox, with step-by-step commands and solutions to common issues.
Before running any commands, it helps to understand what you are actually working with.
An OVA (Open Virtualization Archive) is not a single disk file. It is a compressed TAR archive that bundles three components together:
QCOW2 (QEMU Copy On Write v2) is the standard disk format for KVM-based hypervisors. Unlike VMDK, it supports thin provisioning, built-in snapshots, and AES encryption natively.
OVA vs. QCOW2 at a Glance
| Feature | OVA (VMDK) | QCOW2 |
|---|---|---|
| Primary Platforms | VMware, VirtualBox | KVM, QEMU, Proxmox, EVE-NG |
| File Type | Archive (TAR) | Single disk image |
| Snapshots | Hypervisor-managed | Built-in native support |
| Disk Allocation | Fixed or dynamic | Thin provisioning |
| Compression | Manual (zlib) | Native support |
Why Convert?
The main reason to convert OVA to QCOW2 is cross-hypervisor migration. If you are setting up a Proxmox homelab, deploying a network appliance in EVE-NG, or moving a legacy VMware workload to a KVM-based environment, the disk format should match what the target platform expects before the VM can boot.
The Linux command line is the most straightforward environment for this conversion. The qemu-img utility handles virtual disk format changes and is available on most major distributions.
Before starting, make sure you have the following:
sudo apt install qemu-utils. On RHEL/CentOS, use sudo yum install qemu-img.An OVA is a TAR archive, so you need to unpack it before converting anything.
tar -xvf your-appliance.ova
This produces several files. The one you need is the .vmdk file — the virtual hard disk. The .ovf (configuration) and .mf (manifest) files are also extracted, but you can ignore them for this conversion.
With the VMDK extracted, run the following command to convert it:
qemu-img convert -p -f vmdk -O qcow2 your-disk-image.vmdk output-image.qcow2
What each flag does:
-p flag needs come before -f and -O to work correctly with some versions of qemu-img. Placing it at the end may cause it to be ignored.After conversion, confirm the output file is valid:
qemu-img info output-image.qcow2
Check that the file format line reads qcow2. The output also shows the virtual disk size versus the actual space consumed on disk — useful for spotting any unexpected size differences.
Step 4: Optional: Shrink the QCOW2 File
The converted file may be much larger than the data it actually holds, because empty blocks are preserved during conversion. You can compact it with a second pass:
qemu-img convert -O qcow2 output-image.qcow2 output-shrunk.qcow2
This rewrites the file and skips empty blocks. A 100 GB virtual disk with only 5 GB of actual data can shrink dramatically. The original file is not modified, so you can delete it once you have verified the shrunk version.
Step 5: Use the QCOW2 with KVM / virt-manager
To attach the disk to a VM in a KVM environment:
1. Move the file to the default image directory:
sudo mv output-image.qcow2 /var/lib/libvirt/images/2. Open virt-manager (Virtual Machine Manager).
3. Click New Virtual Machine.
4. Select Import existing disk image.
5. Browse to your QCOW2 file and complete the setup by configuring CPU and RAM.
Windows does not support OVA or QCOW2 natively, but you have two options without switching to a Linux machine: using the Windows Subsystem for Linux (WSL) or a native Windows build of qemu-img.
Prerequisites
Before starting, make sure you have:
WSL lets you run Linux tools directly on Windows, which makes this the most reliable method. The commands are identical to the Linux workflow.
1. Install WSL: Open PowerShell as Administrator and run:
wsl --installThis installs WSL 2 with Ubuntu by default. Restart your machine when prompted. If Ubuntu is already installed, skip to step 2.
2. Install qemu-utils: Inside your WSL Ubuntu terminal, run:
sudo apt update && sudo apt install qemu-utils -y3. Access your files: Windows drives are mounted inside WSL under /mnt/. To navigate to your Downloads folder on the C: drive:
cd /mnt/c/Users/YourName/Downloads/4. Extract and convert: Follow the same tar and qemu-img steps from the Linux section above.
If you prefer not to use WSL, you can use a standalone Windows build of qemu-img.
C:\qemu\..ova file in 7-Zip and select Extract here. This unpacks the .vmdk, .ovf, and .mf files. .\qemu-img.exe convert -p -f vmdk -O qcow2 "source-disk.vmdk" "output-disk.qcow2"
Limitations of Method 2: The Windows binary of qemu-img may lag behind the Linux version in terms of updates and performance. For production use or large disks, WSL is the more dependable option.
C:\Virtual Machines\), the command will fail unless you wrap the path in double quotes, as shown above..vmdk to a short path such as C:\temp\ and try again.Proxmox VE is one of the most common destinations for OVA migrations. The web interface does not have a direct OVA import option, but Proxmox provides command-line tools that handle the process reliably.
This approach avoids uploading a large converted disk from your local machine. Instead, you transfer the smaller OVA first, then extract and convert directly on the host.
1. Upload the OVA: Use an SCP client such as WinSCP or the scp command to transfer the OVA to your Proxmox host. A safe destination is /tmp/.
2. SSH into Proxmox: Connect as root:
ssh root@<your-proxmox-ip>3. Extract and convert:
tar -xvf your-appliance.ova
qemu-img convert -p -f vmdk your-disk.vmdk -O qcow2 managed-disk.qcow24. Import the disk to a VM: Replace 100 with your actual VM ID and local-lvm with your target storage name:
qm importdisk 100 managed-disk.qcow2 local-lvmSome versions of qemu-img can read through the OVA’s TAR wrapper and convert directly, without manually extracting the VMDK first:
qemu-img convert -p your-appliance.ova -O qcow2 output.qcow2
This only works reliably when the OVA contains a single virtual disk. If the appliance has multiple disks, this method may fail or convert only the first disk. When in doubt, use Method 1.
Method 3: Using qm importovf (Native Proxmox Import)
Proxmox includes a built-in command that reads the .ovf configuration file and creates the VM automatically, including CPU and RAM settings.
1. Extract the OVA:
tar -xvf appliance.ova2. Run the import: Replace 100 with your VM ID and local-lvm with your storage name:
qm importovf 100 ./appliance.ovf local-lvm --format qcow2Common error: If you see “invalid host resource,” the OVF is referencing a network name (such as “VM Network”) that does not exist on your Proxmox host. You can safely ignore this and configure the network interface manually in the web UI afterward.
When to use this method: qm importovf is best when you want Proxmox to configure the VM settings automatically from the OVF file. Use Method 1 if you prefer to control the VM configuration yourself.
After importing the disk, the VM will not boot until you complete these steps in the Proxmox web UI:
Network engineers often need a QCOW2 image to run virtual firewalls and routers — such as Palo Alto, FortiGate, or Cisco appliances — inside EVE-NG (Emulated Virtual Environment Next Generation).
The conversion steps are the same as the Linux method, but EVE-NG has strict requirements for folder names and disk file names. Follow these exactly, or the node will not appear or boot correctly.
1. Create the device directory: EVE-NG expects each node type to live in its own named folder under /opt/unetlab/addons/qemu/. The folder name should match the image name you configure in EVE-NG. For example, for Palo Alto PAN-OS 9.0.1:
mkdir -p /opt/unetlab/addons/qemu/paloalto-9.0.1/2. Upload and extract the OVA: Transfer your OVA to the device directory via SCP, then extract it:
tar -xvf your-appliance.ova3. Convert and rename the disk: EVE-NG requires the disk file to be named virtioa.qcow2 or hda.qcow2 depending on the node type. Convert and name it in one step:
qemu-img convert -p -f vmdk appliance-disk1.vmdk -O qcow2 virtioa.qcow24. Fix permissions: Run this after every image addition. It sets the correct ownership and permissions so the EVE-NG hypervisor can read the file:
/opt/unetlab/wrappers/unl_wrapper -a fixpermissionsThe command-line methods covered in this guide work well for one-off conversions. But if you are managing a larger migration — moving dozens of VMs from a VMware environment to KVM or Proxmox, or transitioning workloads across data centers — manual extraction and conversion quickly becomes time-consuming and error-prone.
Format incompatibility is only part of the challenge. Keeping production systems running during the transition, validating data integrity after the move, and handling legacy operating systems all add complexity that qemu-img alone cannot address.
i2Migration is a unified migration platform built for exactly these scenarios. It supports live, non-disruptive migration across physical, virtual, and cloud environments — without requiring manual disk extraction or format conversion steps.
For teams that need to migrate at scale or cannot afford downtime during the transition, i2Migration offers a more controlled and auditable path than manual conversion.
If you are rethinking your virtualization infrastructure, data protection is the other side of the equation. Once your VMs are running on the new platform, i2Backup provides centralized backup across physical servers, virtual machines, and databases — including Proxmox and KVM environments. For workloads where availability is critical, i2Availability adds real-time replication and automatic failover to keep services running if a host goes down.
Click the button to get a free trial of Info2soft’s solutions!
Q1: Can I convert OVA to QCOW2 directly without extracting?
Sometimes. If the OVA contains a single disk and you are running a recent version of qemu-img, direct conversion can work. That said, extracting the TAR file first is the safer approach — it lets you confirm which VMDK file to use, especially when the appliance includes multiple disks.
Q2: Is QCOW2 better than VMDK?
It depends on the platform. VMDK is the standard format for VMware environments. QCOW2 is optimized for KVM-based hypervisors like Proxmox and offers native compression, built-in snapshot support, and copy-on-write behavior that uses disk space more efficiently. If you are running KVM or Proxmox, QCOW2 is the better choice.
Q3: How do I convert a CentOS QCOW2 image back to OVA?
There is no single command for this. The process involves two steps: first, convert the QCOW2 to VMDK using qemu-img, then import that VMDK into VirtualBox or VMware and export it as an OVA.
The conversion command is:
qemu-img convert -p -f qcow2 -O vmdk input.qcow2 output.vmdk
Q4: How long does conversion take?
It depends on disk speed and virtual disk size. A 40 GB VMDK typically converts in 2 to 5 minutes on an NVMe drive. On a traditional HDD, expect significantly longer. The -p flag in qemu-img shows a progress bar so you are not left guessing.
Q5: Can I convert back from QCOW2 to OVA?
Yes. Convert the QCOW2 back to VMDK using qemu-img, then use VMware Workstation or VirtualBox to wrap the VMDK into an OVF/OVA archive. The steps are essentially the reverse of what this guide covers.
Converting OVA to QCOW2 comes down to a few consistent steps: extract the archive, convert the VMDK with qemu-img, verify the output, and attach the disk to your target VM. The platform you are working on — Linux, Windows, or Proxmox — changes the tooling slightly, but the core process stays the same.
A few things worth keeping in mind before you wrap up:
For one-off migrations, the manual methods in this guide are practical and free. If you are moving multiple VMs or need to keep production systems online during the transition, a dedicated migration platform like Info2soft’s i2Migration removes much of the manual work and adds built-in validation to the process.
