Re: Migrating a 10TB VM from ESXi to PVE/Ceph

["DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>]

pegaprox have also nice importer for vmware
https://docs.pegaprox.com/migration/esxi-migration/

with different methods (like snasphot on vmware side, or qemu-drive
mirror through sshfs)

 
Le lundi 07 septembre 2026 à 23:04 +0300, Andrei Boros a écrit :
> I was thinking of the same thing for a esx->pve migration scenario we
> have.
> 
> Still in the concept stage until hardware is fully connected, so will
> be back with feedback.
> 
> On 7 September 2026 22:35:22 EEST, Adam Thompson
> <athompso@athompso.net> wrote:
> > I went with NFS precisely because FC storage isn't generally
> > something
> > PVE can mount - it's block storage, so it'll have (most likely) a
> > VMFS5
> > filesystem and raw files with extents inside it, not VMDKs. 
> > Pivoting
> > through an NFS server flattens everything into a VMDK, which PVE
> > can
> > then mount and see and use.
> > -Adam
> > 
> > -----Original Message-----
> > From: Tom Weber <pve@junkyard.4t2.com> 
> > Sent: Monday, September 7, 2026 12:46 PM
> > To: pve-user@lists.proxmox.com
> > Subject: Re: Migrating a 10TB VM from ESXi to PVE/Ceph
> > 
> > Hi,
> > 
> > I'd try to make your FC SAN Storage visible to your PVE Cluster -
> > so
> > that it can "see" the .vmdk Files.
> > 
> > Next define a VM with the needed Hardware Settings (CPU, RAM,
> > Network...) but small / empty Disks on your FC SAN Storage - choose
> > VMDK Format.
> > 
> > This should give you a machine description in PVE (in
> > /etc/pve/nodes/<NODE>/qemu-server/<ID>.conf) and vm-<ID>-disk-
> > <x>.vmdk
> > files on the FC SAN Storage.
> > 
> > Now with the VM shut down (in both worlds), you could rename the
> > production VMDK Files to the vm-<ID>-disk-<x>.vmdk names used in
> > the
> > <ID>.conf file and you should be able to fire up the VM on the PVE
> > cluster working with the vmware disks on the FC SAN (current Data).
> > 
> > Once the VM is running you could do a live migration (move Storage)
> > of
> > the VMDK disk to Ceph or whatever other PVE Storage.
> > 
> > 
> > From time to time I did something similar and I dont see why it
> > shouldn't work but please test and experiment with smaller VMs
> > first -
> > and if possible work with Snaphots/Backups whatever before mounting
> > the
> > production .vmdk files in PVE.
> > 
> > Regards,
> >   Tom
> > 
> > 
> > Am 07.09.26 um 09:08 schrieb Fabien Sirjean:
> > > Dear all,
> > > 
> > > After successfully migrating most of our infrastructure (300+
> > > VMs)
> > from VMware ESXi to PVE, we're struggling with one last critical
> > VM:
> > our BlueMind/Cyrus mail server (~800 users), with a 10TB virtual
> > disk.
> > > 
> > > Our setup is:
> > > 
> > > Source: ESXi → Dell EMC VPLEX (FC) → Dell Unity
> > > Target: Proxmox VE → Ceph RBD (dedicated cluster)
> > > 
> > > We tried the Proxmox ESXi importer, but I/O performance degraded
> > > so
> > much during the live import that the mail service could not sustain
> > its
> > normal workload.
> > > We then stopped the service to complete the migration, but the
> > > import
> > eventually failed after almost 3 days, forcing us to start over.
> > > 
> > > Application-level migration/synchronization is not an option, so
> > we're looking for a block/storage-level approach with minimal
> > downtime.
> > > 
> > > Since the datastore ultimately resides on our FC SAN, could we
> > > bypass
> > ESXi entirely and temporarily present the relevant VPLEX/Unity LUN
> > to a
> > PVE or migration host, mount/access the VMFS datastore read-only,
> > and
> > copy/convert the VMDK directly to Ceph RBD?
> > > Even better, is there a practical way to perform the bulk copy
> > > while
> > the VM is running, then only synchronize the changed blocks during
> > the
> > final cutover?
> > > 
> > > Any advice or experience with direct VMFS access, VPLEX/Unity
> > snapshots/clones, or other approaches for this kind of migration
> > would
> > be greatly appreciated.
> > > 
> > > Thanks!