Free online QCOW2 to OVA converter

What the QCOW2 format is

QCOW2 (QEMU Copy-On-Write version 2) is a virtual disk image format used by QEMU, KVM, Proxmox VE, and many Linux virtualization systems. It supports sparse allocation, snapshots, optional compression, encryption, and backing-file chains, so its apparent capacity can be much larger than the physical file.

You commonly encounter QCOW2 files in directories containing QEMU or KVM virtual machines, exported cloud images, Proxmox backups, and Linux-based virtualization appliances. The file normally contains a guest operating system and its virtual disk data, but not necessarily the complete virtual machine definition, hardware settings, network configuration, or firmware selection.

What the OVA format is

OVA is a single-file Open Virtualization Appliance package. Technically, it is a TAR archive containing an OVF descriptor, one or more virtual disks, and optionally a manifest containing SHA checksums. The OVF descriptor defines virtual hardware such as memory, CPUs, controllers, firmware, and disk attachments.

OVA is useful for moving a complete virtual appliance between products such as VMware Workstation, VMware ESXi, Oracle VirtualBox, and some other OVF-compatible platforms. It is easier to distribute as one file than a directory containing an OVF descriptor and separate disks, but import compatibility still depends on the target hypervisor.

How to actually convert QCOW2 to OVA

Convert with QEMU and VirtualBox

The reliable desktop workflow is to convert the QCOW2 disk to VMDK with qemu-img, attach that disk to a new VirtualBox machine, and export the machine as OVA.

1. Install the required tools. Install QEMU utilities, which provide qemu-img, and Oracle VirtualBox with its VBoxManage command-line tool. On Debian or Ubuntu, the QEMU utility package is commonly installed with sudo apt install qemu-utils.
2. Inspect the source image. Run qemu-img info --backing-chain source.qcow2. Make sure every backing file is available and that the image is not encrypted or still being written by a running VM.
3. Convert the disk. Run qemu-img convert -p -f qcow2 -O vmdk source.qcow2 converted-disk.vmdk. Replace the filenames with the actual paths. The output size depends on the allocated guest blocks, not only on the QCOW2 file's apparent capacity.
4. Create a matching virtual machine. The following example creates a two-CPU, 4 GiB Linux machine with a SATA controller and BIOS firmware:

VBoxManage createvm --name "Converted VM" --ostype "Linux_64" --register
VBoxManage modifyvm "Converted VM" --memory 4096 --cpus 2 --firmware bios
VBoxManage storagectl "Converted VM" --name "SATA Controller" --add sata --controller IntelAhci
VBoxManage storageattach "Converted VM" --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium "converted-disk.vmdk"

Choose a different --ostype, memory amount, firmware mode, or controller when the guest requires it. For a UEFI guest, use --firmware efi. Attach additional converted disks to their original boot order and controller type when the source VM has more than one disk.

5. Test the imported machine. Start it with VBoxManage startvm "Converted VM". Confirm that the guest boots, its partitions are visible, and its network adapter and storage drivers work before exporting.
6. Export the machine. Run VBoxManage export "Converted VM" --output converted-appliance.ova. VirtualBox creates the OVF descriptor and packages the virtual disk into the OVA archive.
7. Verify the package. Use tar -tf converted-appliance.ova to list its contents. You can also test it by importing the file into a separate VirtualBox or VMware installation.

For a browser-based option, 101convert.com provides free conversion without installing software. Virtual machine images can be very large and may contain credentials or other sensitive data, so local conversion is preferable for confidential systems.

Quality, compatibility, and limitations

• Conversion does not change the guest OS. It changes the disk container and creates new virtual hardware metadata. Installed applications, boot loaders, and drivers remain those from the source image.
• QCOW2 backing chains and snapshots are not represented as equivalent OVA snapshots. The conversion normally produces the current disk state as a consolidated disk; retain the original chain if rollback points are needed.
• Match the original boot mode. A guest installed for UEFI may fail with BIOS, while a BIOS-installed guest may not boot with UEFI unless its disk layout and boot loader support it.
• Storage-controller changes can cause boot failures, especially on Windows. If the source guest uses VirtIO and the exported VM uses SATA or IDE, install the required guest drivers before changing controllers, or configure the target controller to match.
• An OVA is not guaranteed to be fully portable. VMware, VirtualBox, and other products may interpret OVF hardware identifiers, disk variants, USB devices, network adapters, and firmware settings differently. Remove unsupported devices or edit the OVF descriptor only when you understand the target hypervisor's requirements.
• OVA packaging does not inherently compress the virtual disk. The archive may be larger than the original sparse QCOW2 file, and extracting or importing it requires enough free space for both the archive and the expanded disk.
• Do not convert an image while its source VM is running unless the virtualization platform provides a consistent snapshot. Shut down the guest or create a verified application-consistent copy first to avoid filesystem corruption.