OVA File Documentation

Summary

An .ova file is an Open Virtual Appliance, a single-file package of a complete virtual machine: its hardware definition plus one or more virtual disks, bundled so a VM can be moved between hosts. It is an uncompressed TAR archive (the DMTF Open Virtualization Format packaged as one file), MIME type application/x-virtualbox-ova. You do not open it like a document; you import it into a hypervisor such as VirtualBox or VMware Workstation. Because it is a TAR, you can also rename it to .tar to extract the disks.

Technical details

FeatureValue
Full nameOpen Virtual Appliance (Open Virtualization Format Archive)
File extension.ova
MIME typeapplication/x-virtualbox-ova
Format typeUncompressed TAR archive bundling an OVF descriptor + disks
DeveloperDMTF (Distributed Management Task Force); promoted by VMware
StandardOVF — DMTF DSP0243 (OVF 1.0, 2009)
Open standardYes — cross-vendor
CategoryDisk image / virtualization
Container / base formatPOSIX TAR (ustar)
Magic number75 73 74 61 72 (“ustar”) at offset 257, not byte 0
First memberThe .ovf XML descriptor (by convention)
Descriptor.ovf — CPU, RAM, NICs, disk references (XML)
Manifest.mf — SHA-1/SHA-256 checksums of each member
Signature.cert — optional digital signature of the manifest
Virtual disks.vmdk or .vhd image(s)
Contains running stateNo — disks + hardware only, no snapshots
Imported byVirtualBox, VMware Workstation/Fusion/ESXi, Proxmox, ovftool
Convert to.ovf, .vmdk, .vdi, .vhd (extract / convert disks)
Related extensions.ovf, .vmdk, .vhd, .vdi, .vbox, .iso
Specificationdmtf.org/standards/ovf
File signature (magic bytes)
75 73 74 61 72 00

Offset 257, ASCII ustar followed by a NUL. An OVA is an uncompressed POSIX TAR archive, so it has no signature in its first bytes: the ustar magic sits at byte 257 inside the first 512-byte TAR header block, where the member's name occupies bytes 0–99. By convention the first archived member is the .ovf XML descriptor, followed by the .mf manifest, an optional .cert, and the virtual disks (.vmdk/.vhd). Because there is no leading magic, tools identify an OVA by extension and by the ordered TAR members inside.

What is an OVA file?

OVA stands for Open Virtual Appliance, the single-file packaging of the Open Virtualization Format (OVF). OVF is an open standard published by the DMTF as DSP0243 in 2009 for distributing virtual machines and virtual appliances between different hypervisors. In its unpacked form a virtual appliance is a folder of files: an .ovf XML descriptor, a .mf manifest of checksums, an optional .cert signature, and the virtual disk images. An .ova rolls all of that into one archive so an entire VM is a single download.

An OVA solves portability. A vendor can ship a ready-to-run appliance (a firewall, a Linux server, a security lab) that you import in one step instead of installing an operating system from scratch. The format is widely associated with VMware, which co-authored and promoted OVF, but it is genuinely cross-vendor: VirtualBox, VMware Workstation, Fusion and ESXi, and Proxmox all handle it. One thing an OVA does not contain is the machine's running state or snapshots; it is a static export of disks plus a hardware definition.

An OVA is a TAR archive, member by member

The most useful technical fact about an OVA is that it is an ordinary uncompressed TAR archive. There is no compression and no proprietary wrapper: it is the POSIX ustar tape-archive format. That means you can rename appliance.ova to appliance.tar, or open it directly in 7-Zip or with tar -xf, and pull out the individual files without any virtualization software at all.

appliance.ova  (one TAR archive)
 ├─ appliance.ovf    XML: virtual hardware (CPU, RAM, NICs, disk refs)
 ├─ appliance.mf     manifest: SHA-1/SHA-256 of each member
 ├─ appliance.cert   optional signature of the manifest
 ├─ appliance-disk1.vmdk   the virtual hard disk image
 └─ appliance-disk2.vmdk   additional disk(s), if any

The OVF specification requires a definite order inside the archive: the .ovf descriptor must come first, the manifest and certificate next, and the disk images after. That ordering lets a streaming importer read the small descriptor at the front, learn what disks to expect, and process the large disk images as they arrive, rather than seeking to the end of a multi-gigabyte file first.

The TAR header and the ustar magic at offset 257

TAR stores each member as a 512-byte header block followed by the file content padded up to a 512-byte boundary. The header is a fixed layout of fields, and this is why an OVA has no signature in its first bytes: byte 0 is the start of the first member's name, not a magic number.

TAR header block (512 bytes), key fields:
  offset 0    name        100 bytes  (e.g. "appliance.ovf")
  offset 100  mode         8
  offset 124  size        12  (octal ASCII byte count)
  offset 136  mtime       12
  offset 148  checksum     8
  offset 156  typeflag     1
  offset 257  magic        6  "ustar\0"   <- format identifier
  offset 263  version      2

The string ustar at offset 257 is the closest thing an OVA has to a magic number. The archive ends with two consecutive 512-byte blocks of zero bytes, the standard TAR end-of-archive marker. Because the file sizes are stored as octal ASCII in the header, a reader walks from one member to the next by reading each header, rounding the size up to the next 512-byte boundary, and jumping there.

The OVF descriptor: virtual hardware in XML

The .ovf file is the brain of the appliance. It is an XML document that describes the virtual machine's hardware in a hypervisor-neutral way using the DMTF Common Information Model (CIM) virtual-hardware schema. It declares the number of virtual CPUs, the memory size, the network interfaces, and, crucially, references to the disk files by their archived names.

<References>
  <File ovf:id="file1" ovf:href="appliance-disk1.vmdk"
        ovf:size="2147483648"/>
</References>
<DiskSection>
  <Disk ovf:diskId="vmdisk1" ovf:fileRef="file1"
        ovf:capacity="42949672960"
        ovf:format="http://www.vmware.com/.../vmdk.html"/>
</DiskSection>
<VirtualHardwareSection>
  ... rasd:ResourceType elements for CPU, memory, NIC, controller ...
</VirtualHardwareSection>

Each hardware item is a ResourceType element with a numeric CIM code (a processor, a chunk of memory, an Ethernet adapter, a disk controller). Because the disk format is named by a URI, an importer knows the disks are VMDK and can decide whether to convert them for its own runtime. The .mf manifest lists a SHA checksum for the descriptor and every disk, and the importer verifies those before powering on, which is how a truncated or tampered download is caught.

Importing an OVA into a hypervisor

Because an OVA is a whole machine, you import it rather than open it. In VirtualBox the path is File › Import Appliance: it reads the OVF, shows the proposed CPU, RAM and disk settings, and builds a VM, storing the disk as its native VDI or keeping the VMDK. In VMware Workstation Pro or Fusion Pro (both free for personal use since Broadcom's 2024 change) the path is File › Open. On the command line, VBoxManage import appliance.ova and VMware's ovftool source.ova target.vmx do the same non-interactively.

Cross-vendor import usually works because OVF is a standard, but the embedded disks and hardware sections are not perfectly neutral. VirtualBox and VMware write slightly different OVF hardware sections, so importing a VMware OVA into VirtualBox occasionally needs the “relax OVF validation” or “continue anyway” option, or a pre-pass through ovftool. The most common import failures are a checksum mismatch from an incomplete download, a hardware section the target rejects, or simply not enough free disk space for the expanded virtual disks.

Extracting the VMDK without importing

Sometimes you do not want the whole machine, only the disk. Since an OVA is a TAR, you extract the .vmdk directly with 7-Zip or tar -xf appliance.ova, then attach it to an existing VM or convert it. The extracted VMDK can be turned into other disk formats: VBoxManage clonehd disk.vmdk disk.vdi --format VDI for VirtualBox, or qemu-img convert to qcow2 for QEMU/KVM, or to .vhd/VHDX for Microsoft Hyper-V. OVF and OVA are the same standard in two packagings, so extracting the archive and repacking the folder is a lossless round trip.

What you cannot do is turn an OVA into an ISO. An OVA is a hardware definition plus disks; an ISO is an optical-disc image. They are different artefacts, and there is no meaningful conversion between them. If you need install media you download the OS's own ISO; if you need the appliance's data you extract the VMDK.

References