Coming across — and getting back out

The way is always the same: look first, take over afterwards. What would come into being is read out and shown, together with the points at which it can go wrong, and only then is anything copied. With real disks a takeover runs from minutes to hours, and starting one blindly is the most expensive way to learn that the guest does not boot.

Download the ISO Four sources

The “Take VMs over from ESXi or Proxmox” dialogue with system, address, credentials and the storage the guest is to land on

Four sources

OVF/OVA — VMware's exchange format, out of ESXi through Export or out of vCenter through its command-line tool.
.vmx — the configuration file of an ESXi VM, copied straight out of the datastore together with the .vmdk beside it.
A Proxmox configuration together with its disks.
A bare disk — .vmdk, .vhdx, .vdi, .qcow2 or .raw with no configuration at all.

Or straight off the running host

Phillux can also connect to a running ESXi or Proxmox host, list its machines and fetch the disks over the network. Proxmox is listed through its API and read over SSH, because it offers no way to download a disk while it is in use; ESXi is read through its datastore browser.

The disk is converted while it is being read, so no space is needed for an intermediate copy and nobody has to export by hand first.

On trust: the SSH host key is pinned at the first connection and shown rather than taken silently. Switching that check off would be more convenient and would mean believing anyone who claims to be the Proxmox host — while credentials and disk data are exactly what is going across.

The three things that decide whether it boots

Firmware. BIOS and UEFI are not interchangeable. A UEFI installation started on BIOS does not find its bootloader, and the other way round.
Disk controller. The most frequent failure of them all: a Windows guest from ESXi has no virtio drivers. Started on virtio-scsi it does not see its system disk and stops with INACCESSIBLE_BOOT_DEVICE. Taken-over guests therefore get SATA until somebody deliberately switches.
MAC address. It is carried over wherever the source names it, because a fixed DHCP address or a licence bound to it would otherwise be lost.

All three are read out of the source rather than guessed, and all three are shown before the copying starts.

And back out again

A guest leaves as an OVA for VMware or VirtualBox — the one format that carries vCPUs, memory and firmware along — or as a bare disk in qcow2, VMDK, VDI, VHDX or raw. A container leaves as a root filesystem tarball or as an Incus/LXD image.

Each target says what has to be done on the receiving side. An export nobody knows how to bring in is of no use to anybody, and that sentence is the reason the hint sits next to the target rather than in a manual.

Container exports go through the system's own tar rather than a library's, because only that carries extended attributes and access lists along — without them a capability like the one on ping is silently gone on the target host.

What no export can carry A VM sees different hardware afterwards. A Linux guest usually boots over the OVF's SATA controller without help; a Windows guest may need its driver sorted out first. That is stated here rather than discovered on the target host.