[Feature] VM migration Zero Downtime

[ThibautBascoulergue]

Got an idea? Nice! 💡 We love hearing what features would make PegaProx better for you.

A friendly reminder: PegaProx is built by volunteers in our spare time. We can't promise timelines or guarantee every feature will be implemented — but every suggestion helps shape the roadmap!

Want to help move things faster?

• 💖 Become a Sponsor — sponsored features get prioritized
• ⭐ Star the project — helps with visibility
• 🤝 Even better: submit a PR with your idea!

---

Describe the feature

Add a VDDK/NFC-based disk transport (e.g. nbdkit-vddk + qemu-img) for reading powered-on source VMs, as an alternative to the current file-level transports (HTTP /folder, SSH dd, SSHFS) used by snapshot_zero.

On standard ESXi, those file-level methods cannot read the base -flat.vmdk of a running VM: ESXi refuses raw opens of an active snapshot-chain extent, regardless of lock state. A VDDK transport reads the snapshot disk through the VMware management stack (NFC, port 902) and works while the VM is running — the same mechanism Veeam and virt-v2v rely on.

Use Case

Migrating of VMs from ESXi 8.0 (VMFS on FC) to Proxmox, I want the low-downtime path snapshot_zero advertises (copy the base live, then a short cutover). In practice the live path never works:

• Snapshot S0 is created fine; the base goes to lock mode 2 (RO) as expected.
• dd of the -flat → Device or resource busy
• HTTP /folder GET of the -flat → HTTP 500, even with the correct dcPath=ha-datacenter (the directory listing works, the flat GET doesn't)
• SSHFS → Operation not permitted
• Adding disk.locking = "FALSE" to the VMX changes nothing — so it isn't the lock, it's the vmkernel guarding active chain extents

As a result, snapshot_zero only succeeds with the VM powered off, which defeats its purpose. A VDDK transport would make genuine near-zero-downtime migration possible, and with CBT (QueryChangedDiskAreas — the -ctk.vmdk is already present) it could do iterative deltas + a ~10 s cutover.

Implementation pointers: nbdkit + vddk plugin exposing the snapshot disk as NBD, then qemu-img convert straight to the Proxmox block device. Works host-direct against standalone ESXi (no vCenter required).

Alternatives considered

• Offline mode — works (VM off → -flat unlocks → any method reads), but full downtime. Fine for most VMs, not for those that can't take an extended window.
• Fixing the /folder URL (adding dcPath) — required for the directory listing, but the flat GET still returns 500 on a running VM, so it doesn't unblock the live path.
• disk.locking = "FALSE" — confirmed no effect, and unsafe (split-brain corruption risk on an HA/FC cluster).

How important is this for you?

Blocking my use case for low-downtime migrations — as it stands, snapshot_zero is effectively offline-only on standard ESXi.

[MrMasterbay]

Hi @ThibautBascoulergue ,

Really really thank you for that write up.
I was able to test this yesterday and could say that worked as you described.

I already implemented it and it will be out with the next update :).

[ThibautBascoulergue]

Hi @ThibautBascoulergue ,

Really really thank you for that write up. I was able to test this yesterday and could say that worked as you described.

I already implemented it and it will be out with the next update :).

Hi @MrMasterbay ,

I saw that you'd implemented live clone in the new release. I'm going to test all that out and I'll give you some feedback. Thanks for the work.

[ThibautBascoulergue]

[15:18:54] === TRANSFER MODE: vmkfstools_clone (VDDK-free near-zero downtime) ===
[15:18:54] Creating clone snapshot (freezes base VMDKs; VM stays up)...
[15:18:55] Snapshot confirmed — base frozen, writes now hit the delta
[15:18:55] Waiting 10s for ESXi to settle...
[15:19:05] Phase: pre_sync
[15:19:05] === CLONE + COPY base VMDKs while the VM keeps running ===
[15:19:06] Cloning frozen base of disk 0: [vsanDatastore] da055867-ae11-0d7f-7e08-000af7c9a908/POISRPSUITECRM.vmdk (32.0 GB)
[15:19:06] vmkfstools cloning frozen base -> _pegaprox_clone_135_0.vmdk (PID 78072920)
[15:19:26] FAILED: Disk 0 clone is implausibly small (0 vs 34359738368 bytes) — likely a raw-device-mapped (RDM) disk, which vmkfstools cannot clone. Use offline transfer mode for this VM.
[15:19:26] Phase: failed

[mkellermann97]

Thanks for the log @ThibautBascoulergue. That failure is actually PegaProx's safety guard doing its job: the zero-downtime mode clones the VMDK with vmkfstools, your disk 0 cloned to 0 bytes, and the run bailed rather than migrate a blank disk. That happens for raw-device-mapped (RDM) disks and for certain vSAN-backed objects vmkfstools won't clone. For this VM, switch the transfer mode to offline (cold) migration — it reads the disk through a different path that handles those. One thing that'd help me: in vSphere, is disk 0 an actual RDM, or a normal VMDK on vSAN? If it's a plain vSAN VMDK, that's something we should make the zero-downtime path handle. opencollective.com/pegaprox if PegaProx is helping out. — Marcus

[ThibautBascoulergue]

Hi Marcus,

Confirmed — disk 0 is a plain VMDK on vSAN, not an RDM. So this is indeed a case the zero-downtime path should handle ideally. I've switched to cold migration for now and it worked fine.

Thanks for the quick explanation!

[mkellermann97]

Thanks for confirming — plain vSAN VMDK, not an RDM. That makes it a genuine gap rather than expected behaviour: the zero-downtime (clone) path should handle a plain vSAN-backed disk, it's just being caught by the same guard that correctly blocks true RDMs. I've flagged it for the V2P rework so the clone path can tell the two apart; cold migration stays the right call until then. Glad it went through cleanly — opencollective.com/pegaprox helps us get to these. — Marcus

[mkellermann97]

This is supported now ✅ — migrating a powered-ON ESXi VM used to be blocked (the running VMDK can't be read via the plain dd/HTTP/SSHFS paths). The migration wizard now has a live transfer mode that reads the running disk via the NFC/live-mirror path, pre-syncs while the guest keeps running, and does a brief cutover at the end instead of requiring the VM to be shut down for the whole copy — i.e. near-zero cutover downtime.

If your specific scenario still sees more downtime than expected (very large disks, particular storage), open a fresh issue with the details and we'll dig in. Closing as done — thanks! 🚀

[ThibautBascoulergue]

Hello,
On my side, I'm still having the issue with a migration from my vSAN: the disk is seen as an RDM disk and the migration fails.

[12:00:56] Proxmox config: bios=seabios, machine=pc, scsihw=pvscsi, disk=scsi, net=vmxnet3
[12:00:56] Creating VM 140: POISRPMAILHA, 8192MB RAM, 4 cores, l26, disk=scsi, net=vmxnet3
[12:00:58] VM shell created
[12:00:58] Phase: pre_sync
[12:00:58] === PRE-SYNC: VM continues running on VMware ===
[12:00:58] Mounting ESXi datastore via SSHFS...
[12:00:59] TMPDIR for subprocesses: /var/tmp
[12:00:59] Resolved datastore symlink: vsanDatastore → /vmfs/volumes/vsan:52ddaaf26df359e4-c4f62b2e4a96f342
[12:01:00] SSHFS mounted: /tmp/v2p-a6463093
[12:01:00] VMDK files via SSHFS: 2
[12:01:00] === TRANSFER MODE: vmkfstools_clone (VDDK-free near-zero downtime) ===
[12:01:00] Creating clone snapshot (freezes base VMDKs; VM stays up)...
[12:01:01] Snapshot confirmed — base frozen, writes now hit the delta
[12:01:01] Waiting 10s for ESXi to settle...
[12:01:11] Phase: pre_sync
[12:01:11] === CLONE + COPY base VMDKs while the VM keeps running ===
[12:01:12] Cloning frozen base of disk 0: [vsanDatastore] b8e71a69-d40a-1710-c0d4-000af7c9a7a4/POISRPMAILHA.vmdk (32.0 GB)
[12:01:12] vmkfstools cloning frozen base -> _pegaprox_clone_140_0.vmdk (PID 79943346)
[12:01:22] FAILED: Disk 0 clone is implausibly small (0 vs 34359738368 bytes) — likely a raw-device-mapped (RDM) disk, which vmkfstools cannot clone. Use offline transfer mode for this VM.
[12:01:22] Phase: failed

Error: Disk 0 clone is implausibly small (0 vs 34359738368 bytes) — likely a raw-device-mapped (RDM) disk, which vmkfstools cannot clone. Use offline transfer mode for this VM.