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.
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
.ovffile—an XML descriptor that defines the VM's hardware (CPUs, memory, network adapters, disk controllers) - One or more
.vmdkfiles—the actual virtual disks - A
.mfmanifest 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.
| Feature | OVF | OVA |
|---|---|---|
| File count | Multiple files | Single archive |
| Portability | Requires keeping files together | Easy to share, download, email |
| Update flexibility | Can replace individual files | Must re-archive the entire package |
| Best for | Cross-hypervisor compatibility | Distribution 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-imgor 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
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.
- Log in to vSphere Client and navigate to the VM you want to export.
- Power off the VM. This is non-negotiable for a clean export. I'll explain why in the prerequisites section below.
- Right-click the VM, hover over Template, and select Export OVF Template.
- Name the template and choose a location. The export will download to your local machine via the browser.
- 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.
- Access the ESXi Host Client by navigating to
https://<host-ip>/uiin your browser. - Navigate to Virtual Machines, right-click the target VM, and select Export.
- Check the files you want to include—
.vmdk,.ovf, and.mfare typically selected by default. - 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 Task | Why It Matters |
|---|---|
| Delete all snapshots | Snapshots create delta files that can cause inconsistency and bloat the export size |
| Power off the VM | A cold export ensures a consistent state; hot exports aren't natively supported |
| Check datastore space | The 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.
- Export the VM as OVF/OVA from VMware (using any of the methods above).
- Convert the VMDK to VHDX using Microsoft Virtual Machine Converter (MVMC) or StarWind V2V Converter.
- Create a new VM in Hyper-V and attach the converted disk.
- 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 Message | Likely Cause | Fix |
|---|---|---|
| "Insufficient disk space" | Destination full | Free space or change destination |
| "Failed to open file" | Permission issues | Check write permissions on destination |
| "Connection reset" | Network instability | Use 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.