Move an Ubuntu VM to Another ESXi Host with OVF Export Honest Guide
No vCenter, no shared storage, two standalone ESXi hosts - and an Ubuntu VM that has to live on the other one. OVF export is the built-in bridge: it packages the VM into files you can carry across. It is simple, honest work, as long as you know what the package leaves behind and what changes on arrival.
By Technical AnshuVMware ESXiOVF export and importStandalone hosts
Watch the full video - Ubuntu virtualization on ESXi, the setup, configuration and troubleshooting, step by step
Licensed clusters glide VMs between hosts with live migration, but a standalone host has no such magic - and on the free ESXi edition there is no vMotion at all. The standalone answer is OVF: export the VM from the old host as a set of files, import it on the new host, and verify it like a machine that has just moved house. This page covers the move end to end, including the two surprises - a new MAC address and missing snapshots - that catch people who expected a perfect clone.
What an OVF export gives you
The .ovf fileThe VM description - settings and hardware
The .vmdk fileThe virtual disk itself - the big one
The .mf fileChecksums that prove the copy is intact
Not includedSnapshots, logs, performance history
Package contents for a typical export - the disk file is as large as the data the VM actually uses and more
1
Pick the Right Route First
Three honest options exist for moving a VM between hosts:
vMotion / migration - if both hosts are managed by vCenter with suitable licensing, use it; nothing in this page beats it
OVF export and import - the standalone route in this guide: works host to host with nothing shared, at the price of downtime and a full copy
Copy the VM's folder from one datastore to another (over the network via the datastore browser, or on a disk) and register the .vmx on the new host - viable, and it can carry snapshots with it, but the web tools move big files slowly and a stalled copy is messier to reason about than an OVF
For a planned, one-off move of an Ubuntu VM, OVF is the cleanest default.
2
Export - Patience Included
Power the VM off. An export of a running VM is not a consistent copy; the shutdown is part of the price of this route
Note the VM's settings and its compatibility (hardware) version - the destination host must support it, which matters when moving to an older ESXi
From the host client: select the VM, choose Export, and save the files to a machine with room - the .vmdk will be roughly the size of the data the VM holds, and exports can swell beyond the thin disk's current size, so check free space first
Let it finish completely. A large VM crossing a busy network or Wi-Fi can take a long while, and web-based exports of very large VMs are a known weak spot - if yours keeps failing, that is the moment to switch to the folder-copy route rather than retry forever
Keep the source VM untouched until the copy has booted on the far side. The export is your backup until the move is proven.
3
Import on the New Host
In the new host's client: Create / Register VM, then deploy from an OVF file and point it at your exported files
Choose the datastore with real room - remember thin disks there will grow from what the export wrote
Map the network to the new host's equivalent VM network; the old host's port group names do not travel
Finish the wizard but do not power on yet - the checks in the next section come first
4
First Boot on the New Host - the Checks That Matter
MAC address: the moved VM may arrive with a new one. Anything keyed to the old MAC - a DHCP reservation, a static-address plan, occasionally a licence - needs updating. Check the address the VM actually gets (ip a) against what your network expects, and inspect the netplan configuration if the address is wrong.
The "moved or copied" question: if the host asks whether you moved or copied the VM (you see this mainly on the folder-copy route), "I copied it" generates fresh identifiers - the safer answer when the original still exists anywhere on the network, since duplicate identities cause weird, intermittent faults.
Devices: confirm the network adapter type survived as intended, and re-attach any ISO the VM expects - ISO paths point at the old host's datastore and do not travel. Then boot, watch the console, and test the VM's real job plus SSH from another machine.
5
What Does Not Travel - Plan Around It
Snapshots - an OVF export captures the VM's current disk state only. If a snapshot chain mattered, consolidate or accept its loss before exporting
History and housekeeping - performance history, alarms and event logs stay with the old host
Downtime maths - export time plus import time plus testing is the outage. For a big VM on slow storage that can be hours, which is why this route suits planned moves and lab reshuffles, not emergency evacuations
Only one live copy - once the new VM is verified and on the network, retire or clearly rename the old one. Two identical machines with the same name and address are a fault you schedule for yourself
Finish by treating the verified copy on the new host as the moment the move ends - and take a fresh backup or export of it there, because your previous safety copies describe a machine on a host it no longer lives on.
Watch Ubuntu on ESXi in the Video
The full process on a live ESXi host - creating the virtual machine, installing Ubuntu and fixing the common problems, exactly as they appear on screen.
It is bounded by simple physics: the full virtual disk is written out, moved and written back in, so time scales with the VM's real data size and the slowest storage or network link involved. A small Ubuntu server may take minutes; a large VM over a busy network can take hours. Power-off time is included in that window, so plan the move for a quiet period.
Will my Ubuntu VM keep its IP address after the move?
The configuration travels with the VM, but the virtual network card may receive a new MAC address on the new host. If the address comes from a DHCP reservation tied to the old MAC, the VM will get a different address until you update the reservation; if the address is set inside Ubuntu, check the netplan configuration still matches the interface it finds. Verify with ip a at first boot.
Can I move a VM to an older ESXi host this way?
Only if the VM's virtual hardware (compatibility) version is supported by that older host - a VM created at a newer compatibility level can be refused at import. Check the compatibility before you export, and if a downgrade move is planned, that decision ideally happens when the VM is first created, as the settings guide in this series explains.
This guide is based on the Technical Anshu video on Ubuntu virtualization on ESXi - stuck on a step? Ask in the video comments and you will get a reply.