The ESXi import wizard copies what you provisioned, not what you use

There is a short thread on the Proxmox forum with three figures from the same case that explain, better than any manual, why a VMware migration eats your maintenance window. A 5 TB virtual disk. Inside it, 255 GB actually in use. The import through the ESXi wizard: a good eight hours, over a 1 Gbit link. And on the destination, a ZFS pool, the machine ended up taking 260 GB. All three figures are compatible, and together they say the same thing: the wizard does not size your migration by your data, it sizes it by your provisioning. Zeros cost nothing on the destination disk. They cost you the window.

The fourth figure is ours, and we flag it as such, because it is napkin arithmetic: a gigabit moves around 112 MB/s on a good day, which is on the order of 0.4 TB per hour. At that rate, 255 GB is about 38 minutes. The real window in that case was eight hours. Twelve times longer than the volume of data that actually needed moving, with the machine powered off the whole time.

Why it happens: the API does not say which blocks are written

The explanation comes in the same thread from Falk R., a distinguished forum member and Proxmox subscriber, on 29 January 2026, and it is two sentences long: "Das Problem ist die vSphere API. Die liefert das Storage, aber keine Thin Provisioning Informationen." The problem is the vSphere API: it hands over the storage, but no thin provisioning information. Translated into what that means for you: the wizard can ask "how big is this disk?" and get 5 TB back; it cannot ask "which of these blocks have anything written in them?". So it asks for the whole logical range, and what is not there travels down the wire too.

It is worth being honest about the limits of that arithmetic. Five terabytes at 0.4 TB/h would be twelve and a half hours, and even at perfect line rate —125 MB/s— eleven, and this case took eight, so the full 5 TB did not cross the wire: what crossed was somewhere between the real 255 GB and the nominal 5 TB, on the order of terabytes rather than gigabytes. We do not know the exact split and we are not going to invent it. What the case's own figures do establish is the direction of the error: whoever planned with the "used" number was off by a wide factor.

The arithmetic to do before you promise a date

The estimate is a division, and the only thing you need to get right is the numerator: the provisioned size. For the denominator, these are realistic throughput figures rather than line rates —they frame the order of magnitude, they do not sign an SLA—:

In a migration of large, mostly empty disks, the window is set by the old ESXi box's network port. The freshly bought NVMe drives on the destination do not touch it. If you can put the source host on a 10 Gbit link for a weekend, that is worth more than any tuning of the new storage.

Two bills: one can be dodged, the other cannot

Provisioning that does not exist gets billed twice, and the two bills are independent. The capacity bill is paid by the destination, and it can be dodged: the Proxmox documentation says it in one line —"With thin provisioning activated, only the blocks that the guest system actually use will be written to the storage"— so if the destination is one of those that absorb zeros, 5 TB lands as 260 GB, which is exactly what happened to the thread author on ZFS. The time bill is absorbed by nobody. It is paid by the outage window, and therefore by the business.

Which destinations absorb zeros: the rule the manual gives is that every storage type with snapshots supports thin provisioning, which puts LVM-thin, ZFS, Ceph/RBD, BTRFS and the file-based storages —local directory, NFS, CIFS— when the disk is stored as qcow2 on the list. Classic LVM with raw is not: there, a 5 TB import reserves 5 TB. It is the most expensive mistake and the easiest to make, because raw sounds like "no frills" and on block storage it means "all of it". The migration manual offers the --format parameter with raw, vmdk and qcow2, but with small print worth reading: "If the target storage stores the disk images as files…". That option only exists if the destination keeps images as files, which classic LVM never does. There the choice is made earlier, by choosing a different destination.

And the warning attached to that advantage, also verbatim from the documentation: "If a storage runs full, all guests using volumes on that storage receive IO errors. This can cause file system inconsistencies and may corrupt your data." Absorbing zeros is a loan, not a gift. A whole migration of over-provisioned disks lands on the destination as an oversell that needs watching with a capacity alert, not with good intentions.

The number you plan with is not the one everyone looks at

The vSphere inventory has two columns and you need both. UsedSpaceGB is what the machine actually occupies on the datastore, and ProvisionedSpaceGB is what it was promised: the VMDKs, plus snapshots, plus the swap file if memory is not reserved, plus logs. On thick disks the two columns match; the gap between them is, literally, the size of your problem. A planning inventory fits on one line:

Get-VM | Select-Object Name, ProvisionedSpaceGB, UsedSpaceGB,
  @{N='Ratio';E={if ($_.UsedSpaceGB) { [math]::Round($_.ProvisionedSpaceGB / $_.UsedSpaceGB, 1) }}},
  @{N='Snaps';E={(Get-Snapshot -VM $_).Count}} |
  Sort-Object ProvisionedSpaceGB -Descending

Sort by provisioned size descending and look at the first five rows: those five machines are your migration calendar. One nuance worth not skipping: UsedSpaceGB is the usage observed on the datastore, not the usage of the file system inside; a Windows guest that deleted 300 GB without trimming still counts them as written. It is a measure of what has to be moved, not of what has to be kept.

The snapshot column is there for two reasons that travel together: snapshots count towards the provisioned size, and on top of that the Proxmox manual warns that the import "can be significantly slower if the VM has snapshots". So the same delta penalises you twice, once by size and once by speed. If a machine has been carrying a forgotten snapshot "just in case" for six months, that "just in case" now has a price and it gets paid in the small hours of a Saturday.

What does not fix it

The natural reflex is to empty things first: trim inside the guest with fstrim and punch holes in the VMDK with vmkfstools -K so the file shrinks to what it really holds. That is good hygiene and worth doing anyway. One user in the long import-wizard thread reported, in April 2024 when the importer had just shipped, that neither fstrim inside the guest nor vmkfstools -K on the VMDK shortened his import. Which fits the cause: trimming changes the file, and what is missing is for the API to be able to report it. As long as the interface does not hand over the block map, tidying the house does not shorten the move. Falk R. closes his own message with it: "Da gibt es keinen Workaround, außer eine andere Methode zu nutzen." There is no way around it; there is another method. In that long thread people also ask for the wizard to talk to vCenter and transfer only the consumed size, as some backup tools already do; today that is still an open request.

The screening that comes before the division

Not every machine makes it into the hour count, because not every machine goes through the wizard: disks backed by vSAN, disks encrypted via a storage policy and datastore names with characters such as + are out, and we went through the manual's limitations one by one in the disk arrives intact and Windows will not boot. What this case adds is when that screening happens: before the division, not after you have given the committee a date. A machine on vSAN needs a completely different route rather than simply more hours, and finding that out on migration day is the difference between a long night and a sleepless one.

The alternative for the big, empty machine

For those cases the manual documents a different method, "Attach Disk & Move Disk (minimal downtime)", whose whole point is that it moves the disk with the machine already running on Proxmox. The short version: create a storage in Proxmox pointing at the network share where the VMDK lives, with the Disk Image content type enabled; create a target VM matching the source as closely as possible; point the descriptor at the original -flat.vmdk by relative path; power off the machine in VMware; start it on Proxmox; and with it running, use Disk Action → Move Storage to bring the disk onto its final storage. The outage shrinks to the time it takes the machine to boot.

The drawbacks, which are real: it needs a datastore reachable from both hypervisors, you edit descriptor files by hand, and for a while the Proxmox machine is reading from a disk that physically still sits on the VMware datastore. And it comes with the warning the manual puts in bold, which sums up the one way to destroy data in this procedure: "Make sure that the VM is only powered on in either Proxmox VE or VMware, but never at the same time in both to avoid disk corruption!" With this method, the migration checklist starts and ends with a dumb question: who has confirmed it is powered off over there?

If your disks are thick, close this tab

If your disks are thick, the ratio between provisioned and used is one and there is nothing to optimise here: the window is what it is and the table's arithmetic is already right. If your machines are 80 GB each, the gap between provisioned and used is noise and does not deserve a meeting; fire up the wizard and move on. And two things we do not recommend even though they shorten the window: do not shrink virtual disks live to save copy hours —changing the geometry of a disk with data on it is choosing for yourself the outage you were trying to avoid— and do not push the big machine through the wizard at three in the morning "because it worked with the small ones". The small ones worked because they were small.

The four steps before you give the date

In this order, before anyone writes a date in an email:

1. The inventory with both columns and the ratio, sorted by provisioned size, plus the snapshot count.
2. The screening of the ones that cannot go through the wizard, with their alternative route decided in writing.
3. The division, using throughput measured on a small test machine instead of the cable's line rate.
4. The choice of destination according to whether it has to absorb zeros, with the capacity alert in place before you start.

A note on step four: if the destination is a Ceph cluster, disks arrive thin by default and the per-node distribution starts working the moment they land, so the same copy time also puts the redundancy in place. The trade-off is that with replica 3, every gigabyte that lands gets written three times inside the cluster: Ceph's network goes into the window arithmetic just like the source's does. Deciding that before the migration rather than during it is part of what we do in a VMware to Proxmox migration. The other two places this kind of migration goes wrong we wrote about in the disk arrives intact and Windows will not boot and in the rollback plan.

We do not sell VMware or Proxmox licences, so what you have here is a planning warning. The ESXi import wizard is a good, free tool that has made a great many migrations possible. What it does is bill your window in a currency —provisioning— different from the one you read off the inventory —usage—.

Sources (verified): the three-figure case —5 TB disk, "ca. 255 GB belegt", "gut 8h (1 Gbit)" and 260 GB on the destination ZFS— and Falk R.'s quote (29 Jan 2026) on the vSphere API, ESXi Import thin provision thread on the Proxmox forum; one user's report (Apr 2024) that trimming inside the guest and punching holes in the VMDK did not shorten his import, and the request for the wizard to talk to vCenter and transfer only the consumed size, import wizard thread; wizard limitations (vSAN, policy-encrypted disks, special characters in datastore names, slowness with snapshots, tested versions 6.5–8.0), the "Attach Disk & Move Disk (minimal downtime)" method, the warning about never powering the VM on in both places and the --format options — Migrate to Proxmox VE wiki; thin provisioning definition, the list of storages that support it and the warning about a full storage — Proxmox VE storage documentation; what ProvisionedSpaceGB and UsedSpaceGB contain — VMware PowerCLI documentation and community. The throughput figures in the table, the 38 minutes, the twelve and a half hours and the factor of twelve are our own arithmetic over realistic throughput figures, deliberately rounded and valid only as orders of magnitude: what actually crossed the wire in the cited case is somewhere between 255 GB and 5 TB, and we do not know precisely.