VMware to Proxmox Live Migration: Delta changes

[neilcolyn-jpg]

Good Day,

We are testing the Proxmox Live Migration Feature for our VMware VM's.

During Live Migrations - does Proxcenter perform a final "delta sync" after large VM disk (eg. 2TB database disks) downloads for any changes prior to the source VM being shutdown

"The VM disk is downloaded from the source hypervisor. For ESXi, this uses the VMware VDDK / HTTP file access."

Much appreciated!

[adminsyspro]

Good question !

Short answer for the current "Live" migration: no. Both the ESXi-direct path (vmkfstools clone, then stream) and the vCenter path (VDDK over NFC) copy a single point-in-time snapshot. They do not re-sync changes written on the source during the copy. For a 2 TB database that takes hours to transfer, any writes committed in that window are not carried over, so the target would be missing them. That is a real limitation of the "Live" mode, and not what you want for an active database.

That is exactly why we built a new Warm migration mode (in #395, shipping in the next release):

• The source VM stays online during the bulk copy.
• It uses VMware Changed Block Tracking to find changed blocks, then runs iterative delta passes to converge while the VM keeps running.
• When the remaining delta is small enough, it performs a clean guest shutdown, confirms the VM is powered off, then applies a final delta from the post-shutdown state before attaching and booting on Proxmox.

The result is a no-loss cutover: every committed write, including those made during the long initial copy, ends up on the target. It works for ESXi-direct and vCenter sources (vCenter is required for vSAN), reads via nbdkit-vddk, and writes to raw Proxmox block storage (LVM, LVM-thin, ZFS, Ceph RBD).

For your 2 TB database case, Warm migration is the path: a long initial copy with the database online, a few quick delta passes, then a short final-delta cutover. The Proxmox node needs the VDDK runtime installed (documented), and the dialog runs a readiness preflight before letting you start.

Related: this also resolves the session timeout reported in #394 on a large ESXi-direct copy.

[adminsyspro]

Shipped in the latest release: warm migration with changed-block tracking and a final delta sync moves VMware VMs with no data loss on large or busy disks, including the multi-TB database case described here. Please update to the latest version. Thanks for the detailed discussion.