When people talk to us about moving away from VMware, Proxmox VE is one of the first destinations they ask about. The practical question comes immediately: does support end with a converted disk, or do I get a VM I can actually boot and operate? A disk alone still leaves firmware, disk order, NICs, MAC addresses and storage references to rebuild. V2K handles that destination work. The runs in this article used Proxmox VE 9.2.2, with Ceph 19.2.3 for RBD.
After a 7.4 GB baseline, the first online delta moved 11.4 MB. The final powered-off pass before cutover moved 26.3 MB.
01 / More than a disk copy
V2K now creates the destination VM.
The source side is still VMware. V2K discovers the VM through vCenter,
reads its disks with VDDK HotAdd and can keep a warm copy current with
VMware CBT. Guest conversion happens with virt-v2v-in-place.
The new part is the destination contract. V2K asks Proxmox to prepare a stopped VM and allocate its storage. It then transfers and converts the disks in place, attaches those same volumes and applies the final VM configuration through the Proxmox API.
This is not the storage-only handoff with a Proxmox label on it. Proxmox has its own destination adapter, with both cold and controlled warm workflow paths implemented.
02 / Proxmox-owned volumes
Who allocates the destination volumes?
V2K doesn't guess a Proxmox filename or RBD image name. PVE allocates every destination volume and returns its canonical identity. V2K stores that exact value, detaches the volume for transfer and later reattaches the same object.
This removes a second copy and avoids a dangerous class of naming bugs. Disk order comes from VMware device keys, not alphabetical filenames. A retry reuses the prepared VM and its frozen volume map.
03 / NFS and QCOW2
The first implemented Proxmox storage path.
On NFS, Proxmox allocates QCOW2 files for the destination VM. V2K writes and converts directly in those files, then asks PVE to attach them to the final slots. No temporary export and no second import copy are needed.
Cold Linux and Windows migrations passed. Warm Linux and Windows CBT paths passed as well. The Windows 2019 case used UEFI/Q35, two vCPUs, 4 GiB RAM, a 50 GiB ROOT disk, a 4 GiB DATA disk and two NICs.
The Windows boot disk uses virtio0 because that is the
injected storage-driver path we tested. The DATA disk is
scsi1 under VirtIO SCSI. This is deliberate compatibility
behaviour, not a disk-order error.
04 / Warm CBT evidence
The later passes were deltas, not full copies.
The strongest NFS warm test used one Windows 2019 VM with two disks and two NICs. V2K took a baseline, two online deltas and one final powered-off delta. Every disk kept an exact input and output CBT anchor between passes, and all temporary VMware snapshots were removed.
Four flushed marker generations were written to both Windows volumes: before the baseline, after it, after delta 1 and before cutover. All eight destination hashes matched. Sampled BLAKE3 verification read 132 regions, 553,648,128 bytes in total, with zero mismatches.
05 / Windows reconstruction
What did Windows look like after cutover?
The migrated Windows Server 2019 guest kept its CPU, RAM, firmware, disk order and source MAC addresses. Both destination adapters appeared as Red Hat VirtIO devices. The first NIC kept its static IPv4 configuration; the second remained on DHCP and received a lease.
QEMU Guest Agent responded, both addresses passed network checks and a controlled reboot returned with both disks, marker hashes, MAC/IP settings and QGA intact. The same basic boot and reboot checks also passed on Ubuntu.
06 / Ceph and RBD
RBD is implemented without file staging.
The Ceph path follows the same ownership rule. Proxmox allocates RAW RBD
images. V2K opens only those exact existing images through
librbd, writes the VMware data and runs
virt-v2v-in-place directly against them.
Missing, renamed or wrong-sized images fail closed. V2K never invents a PVE-looking name and never creates a replacement behind the operator's back. Ceph credentials are stored encrypted and materialised only for the worker operation.
Cold Ubuntu, cold Windows 2019 and warm Windows 2019 migrations completed. The retained warm Windows VM used two RBD data images plus its PVE-owned EFI state disk.
07 / Retries and cleanup
A failed attempt keeps the same destination identity.
Provider preparation is durable. If a worker fails, the next attempt opens the same marker-owned PVE VM and the same frozen volumes. VMID allocation is checked across the cluster and against durable database reservations.
Cleanup is deliberately narrow. It requires the exact VMID, the V2K ownership marker and a stopped VM before Proxmox is asked to destroy it. There is no wildcard RBD deletion and no cleanup based on a guessed prefix.
V2K keeps storage verification, destination boot, reboot, QGA, network and in-guest data checks as separate gates. A successful PVE API call doesn't silently stand in for all of them.
08 / Implementation status
Implemented now, with qualification still running.
NFS/QCOW2 and Ceph/RBD are implemented Proxmox destination paths. The dedicated Proxmox branch has passed the cold and controlled warm cases described here. The combined release candidate is now going through the wider cross-destination test campaign before beta.
Source vTPM presence is detected, but TPM state and keys aren't migrated. Secure Boot isn't part of this MVP; the accepted UEFI guests used no pre-enrolled Secure Boot keys.