How to Export Virtual Machine VMware: 2026 Definitive Guide

Learn how to export virtual machine VMware with our 2026 guide. Master OVA, OVF, VMDK formats, vCenter, ESXi, ovftool, and cross-platform migration steps.

You need to move a VM. Maybe it's a migration to new hardware, an archive for compliance, or a backup before a risky upgrade. You open the vSphere Client, right-click the VM, and... the export option is greyed out. Or it starts, and then stalls at 87% for what feels like an eternity. Or worse, it fails halfway through with a cryptic error about disk space.

I've been there. More times than I care to count. And after fifteen years of working with VMware environments—from two-host ROBO clusters to multi-site enterprise deployments—I can tell you this: the secret to a smooth export isn't luck. It's picking the right method for your specific situation, and knowing the pitfalls before you hit them.

This guide is designed as a decision tree. We'll walk through the three export formats, the GUI and command-line methods, cross-platform migration paths, and the troubleshooting you'll inevitably need. By the end, you'll know exactly how to export virtual machine VMware workloads without the guesswork.


Close-up of a computer screen displaying ChatGPT interface in a dark setting.

Choosing the Right Export Format: OVA vs OVF vs VMDK

Before you click anything, you need to answer one question: where is this VM going? The destination determines the format, and getting this wrong at the start is the most common—and most avoidable—mistake I see.

What is an OVF Template?

OVF (Open Virtualization Format) is an open standard that describes a virtual machine in a portable way. Think of it as a folder containing three key pieces:

  • A .ovf file—an XML descriptor that defines the VM's hardware (CPUs, memory, network adapters, disk controllers)
  • One or more .vmdk files—the actual virtual disks
  • A .mf manifest file—contains SHA-1 checksums for integrity verification
my-vm/
├── my-vm.ovf
├── my-vm-disk1.vmdk
├── my-vm-disk2.vmdk
└── my-vm.mf

The beauty of OVF is its compatibility. Because it's an open standard, you can deploy it on VirtualBox, KVM, XenServer, and a host of other hypervisors—not just VMware. In my experience, this makes OVF the go-to choice when you're not 100% sure where the VM will end up.

The trade-off? It's not a single file. You need to keep all the pieces together. Lose the .mf file, and you'll get warnings about integrity checks. Lose a .vmdk, and the whole thing is useless. For long-term archiving, that's a risk I'm not always comfortable with.

What is an OVA File?

OVA (Open Virtualization Appliance) is essentially the same package, but bundled into a single tar archive. One file. That's it.

FeatureOVFOVA
File countMultiple filesSingle archive
PortabilityRequires keeping files togetherEasy to share, download, email
Update flexibilityCan replace individual filesMust re-archive the entire package
Best forCross-hypervisor compatibilityDistribution and sharing
I'll be honest—for 90% of my export needs, I reach for OVA. When you're sending a VM to a colleague or uploading it to a cloud service, dealing with one file instead of five is a massive quality-of-life improvement. The downside is that if you need to update just the disk, you're re-archiving everything.

When to Use Raw VMDK Files

Sometimes you don't need the whole VM. You just need the disk.

Exporting a raw VMDK gives you direct access to the virtual disk file without any of the OVF wrapper. This is useful when:

  • You're converting to another format using tools like qemu-img or StarWind V2V Converter
  • You need to mount the disk directly for data recovery
  • You're working with a platform that expects raw VMDK input

The catch? A VMDK alone is not a complete VM. It's missing the .vmx configuration file, so you can't just "open" it in VMware Workstation and expect it to boot. You'd need to create a new VM and attach the disk manually.

If you're comfortable with the command line, copying a VMDK is straightforward:


scp root@esxi-host:/vmfs/volumes/datastore1/my-vm/my-vm.vmdk /local/path/

vmkfstools -i /vmfs/volumes/datastore1/my-vm/my-vm.vmdk /vmfs/volumes/datastore1/my-vm-copy.vmdk

Silhouette of a person using ChatGPT on a computer screen in a dark room, highlighting digital interaction.

Step-by-Step: Export VM via vSphere Client and ESXi Host

Now that you've picked your format, let's get into the actual export. There are two GUI paths, and which one you use depends on whether you're managing through vCenter or directly against an ESXi host.

Exporting from vCenter (vSphere Client)

This is the method most administrators will use, simply because vCenter is the central management point for larger environments.

  1. Log in to vSphere Client and navigate to the VM you want to export.
  2. Power off the VM. This is non-negotiable for a clean export. I'll explain why in the prerequisites section below.
  3. Right-click the VM, hover over Template, and select Export OVF Template.
  4. Name the template and choose a location. The export will download to your local machine via the browser.
  5. Allow browser pop-ups for the vCenter site. This trips up more people than you'd think—the download silently fails if pop-ups are blocked.

One thing I've learned the hard way: this method works great for single VMs, but it's a browser-based download. For large VMs (say, over 100GB), the browser connection can time out or drop. If that happens, don't fight it—switch to ovftool, which we'll cover shortly.

Exporting Directly from an ESXi Host

If you're running a smaller environment without vCenter, or you need to export a VM that's on a specific host, the ESXi Host Client has you covered.

  1. Access the ESXi Host Client by navigating to https://<host-ip>/ui in your browser.
  2. Navigate to Virtual Machines, right-click the target VM, and select Export.
  3. Check the files you want to include—.vmdk, .ovf, and .mf are typically selected by default.
  4. Click Export to start the download.

This method is simpler and more direct than going through vCenter. But it lacks the centralized management features—you're working against a single host, so you don't get the same visibility into your entire environment.

Prerequisites: Snapshots and Disk State

Before you export anything, take a moment to check these three things. Skipping them is the #1 cause of failed exports and corrupted files.

Pre-Export TaskWhy It Matters
Delete all snapshotsSnapshots create delta files that can cause inconsistency and bloat the export size
Power off the VMA cold export ensures a consistent state; hot exports aren't natively supported
Check datastore spaceThe export destination needs room for the full VMDK size, not just the used space
I can't stress the snapshot point enough. I once spent an entire afternoon troubleshooting an export that kept failing at 60%. Turns out, the VM had a snapshot chain that was 14 levels deep. Deleting the snapshots reduced the export size by 40% and it completed in minutes.

Automating Exports with ovftool and PowerCLI

If you're exporting VMs on a regular basis—or you're dealing with large VMs that choke the browser-based methods—it's time to get comfortable with the command line.

Using ovftool for Command-Line Exports

VMware's OVF Tool is a free utility that gives you far more control than the GUI. It's scriptable, resumable, and handles large VMs without the browser timeout issues.

First, download and install the tool from VMware's website. On Windows, it typically installs to C:\Program Files\VMware\VMware OVF Tool.

The basic syntax is straightforward:

ovftool vi://user:password@host/VM_Name /path/to/output.ova

But the real power comes from the flags:

ovftool \
  --powerOffTarget \
  --noSSLVerify \
  --diskMode=thin \
  --compress=9 \
  vi://admin:password@vcenter.example.com/MyVM \
  /exports/MyVM.ova

Here's what each flag does:

  • --powerOffTarget: Powers off the VM before export (useful for automation)
  • --noSSLVerify: Skips SSL certificate validation (use with caution in production)
  • --diskMode=thin: Exports disks in thin-provisioned format
  • --compress=9: Maximum compression to reduce file size

In my experience, ovftool is the only reliable method for VMs over 200GB. The browser-based export will time out; ovftool will chug along happily and even resume if the network drops.

Batch Export with PowerCLI

For bulk operations, PowerCLI is your friend. The Export-VApp cmdlet does exactly what it sounds like:

Get-VM "VM01" | Export-VApp -Destination "C:\Exports" -Format OVF

But the real value is in looping through multiple VMs:

$vms = Get-VM | Where-Object { $_.PowerState -eq "PoweredOff" }
foreach ($vm in $vms) {
    Write-Host "Exporting $($vm.Name)..." -ForegroundColor Green
    $vm | Export-VApp -Destination "C:\Exports" -Format OVA
}

You can even schedule this as a recurring task for regular backup exports. I've seen teams use this approach to create nightly OVA backups of critical VMs, which is a solid lightweight alternative to a full backup solution.


Cross-Platform Migration: From VMware to Hyper-V and AWS

Exporting a VM is rarely the end goal. Usually, you're moving it somewhere else. Here's where things get interesting—and where the format choice really matters.

Migrating to Hyper-V: Step-by-Step

Moving from VMware to Hyper-V is a common scenario, especially in organizations standardizing on Microsoft infrastructure. The process involves a conversion step, since Hyper-V uses VHDX disks, not VMDK.

  1. Export the VM as OVF/OVA from VMware (using any of the methods above).
  2. Convert the VMDK to VHDX using Microsoft Virtual Machine Converter (MVMC) or StarWind V2V Converter.
  3. Create a new VM in Hyper-V and attach the converted disk.
  4. Install Hyper-V Integration Services for optimal performance.
[VMware VM] → [Export OVF/OVA] → [Convert VMDK → VHDX] → [Create Hyper-V VM] → [Install Integration Services]

A word of caution: conversion tools aren't perfect. I've seen Linux VMs that refuse to boot after conversion, and Windows VMs that need a repair install. The backup solution approach—restoring from a backup directly into Hyper-V—is sometimes more reliable, but it's also more complex to set up.

Exporting to AWS EC2

Cloud migration is a different beast. AWS provides the VM Import/Export service, which can handle OVA or VMDK files directly.

The simplest path is through the AWS Management Console, but the CLI gives you more control:

aws ec2 import-image \
  --description "My VMware VM" \
  --disk-containers "file://containers.json"

The containers.json file specifies the S3 bucket and file format:

[
  {
    "Description": "My VM",
    "Format": "VMDK",
    "UserBucket": {
      "S3Bucket": "my-import-bucket",
      "S3Key": "my-vm.vmdk"
    }
  }
]

Before you start, make sure:

  • The VM is powered off
  • The disk is in a supported format (VMDK, VHD, or RAW)
  • You've uploaded the file to S3

For ongoing replication rather than one-time migration, AWS Application Migration Service is worth a look. It handles the heavy lifting of continuous sync, which is a different use case entirely.


Troubleshooting Common Export Failures

Even with the right preparation, exports fail. Here's how to diagnose and fix the most common issues.

OVF Export Option Greyed Out

This is the most frequent complaint I hear. The export option is there, but it's greyed out and unclickable.

Cause: The VM is running, or it has snapshots.

Solution: Power off the VM and delete all snapshots. If the VM is part of a vApp, you may need to export from the vApp level instead.

Insufficient Disk Space During Export

The export starts, runs for a while, then fails with a disk space error.

Cause: The destination (local disk or datastore) doesn't have enough space for the full VMDK size.

Solution: Free up space or export to a different location. If you're using ovftool, add --compress to reduce the file size. And always monitor the export progress—silent failures are the worst kind.

Error MessageLikely CauseFix
"Insufficient disk space"Destination fullFree space or change destination
"Failed to open file"Permission issuesCheck write permissions on destination
"Connection reset"Network instabilityUse ovftool with resume capability

Export Interrupted or Corrupted Files

The export completes, but the files are corrupted or incomplete.

Cause: Network instability or browser timeout.

Solution: Use ovftool, which supports resume functionality. After export, verify the checksums in the .mf file:


sha1sum -c my-vm.mf

certutil -hashfile my-vm-disk1.vmdk SHA1

For large VMs, I always recommend CLI tools over browser downloads. The browser is fine for small VMs, but it's just not reliable for multi-hundred-gigabyte exports.


FAQ

What is the difference between OVA and OVF in VMware?

OVF is a folder of files—an XML descriptor, VMDK disks, and a manifest file. OVA is a single-file archive that bundles all those pieces together. Use OVF when you need maximum compatibility across hypervisors; use OVA when you want portability and ease of distribution.

Can I export a running VMware VM?

No, native export requires the VM to be powered off. For hot migration, you'd need to use vMotion (for moving between ESXi hosts) or a backup solution that supports live snapshots.

How do I export a VM from vCenter using PowerCLI?

It's a one-liner:

Get-VM 'VMName' | Export-VApp -Destination 'C:\Exports' -Format OVF

Why does my VMware export fail with insufficient disk space?

The destination needs space for the full VMDK size, not just the used space. Try using ovftool with --compress to reduce the file size, or free up space on the destination.


Final Thoughts

Exporting a VMware VM doesn't have to be a gamble. The key takeaways:

  • Choose your format based on the destination. OVA for portability, OVF for cross-hypervisor compatibility, VMDK for disk-level access.
  • Use the right tool for the job. GUI for quick exports, ovftool for large VMs and automation, PowerCLI for batch operations.
  • Check your prerequisites. Delete snapshots, power off the VM, and verify disk space before you start.

The most successful exports I've done weren't the ones where everything went perfectly—they were the ones where I had a plan B. ovftool for the browser timeout. A different destination for the disk space error. A checksum verification for the corrupted file.

If you want a quick reference for your next migration, I've put together a free VMware export checklist PDF that covers all the prerequisites and common pitfalls. And if you're tackling a complex migration—especially cross-platform—feel free to reach out for a consultation. Sometimes a second pair of eyes is all you need.

← Back to Home