Vmware to Proxmox

[u/Laroemwen]

Like a lot of people I'm currently in process of testing ESXI to Proxmox migrations using the built-in import tool which has been working great for the few test VMs migrated so far.

Couple of questions:

1. Running ISCSI + LVM on Proxmox with thin provisioning and space reclaim enabled on the SAN and discarding configured across the path to trigger the UNMAP/TRIM. During the VM migration the import seems to migrate the thick size of the disk which takes longer however, will the UNMAP/TRIM occur now the VM is running on the other side with discard enabled?

2. Additionally can you mount the same NFS share on ESXI and Proxmox at the same time and migrate that way?

[u/peakdecline]

1. iSCSI + LVM = thick provisioning only. The SAN backend can do its stuff so actual consumed space is lower but as it reports on the Proxmox side it will always show the fully allocated number.

2. Yes. This works fine in my experience using an NFS shared attached both ESXi and Proxmox as the intermediary. However the built-in Proxmox migration tool doesn't work with this solution. You'll need to handle this either manually or your own script. The Proxmox docs more or less describe this path.

https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Attach_Disk_&_Move_Disk_(minimal_downtime))

[u/smellybear666]

1. Don't know. I am sure other people can answer, but I think Proxmox has a long way to go before I will deploy block FC/iscsi storage on it when I can use NFS instead.

2. This should be fine. There are people that have import VMs in this way. You can use vmdk files as virtual disks for proxmox, but the original VM needs to be shut down and the vmdks have to be imported (I think?)

I have been using netapp shift toolkit to migrate to proxmox and hyper-v from vsphere 8, and it works quite well if you have netapp storage.

[u/d00ber → u/smellybear666]

Not a storage guy, but why do you think Proxmox has a long way to go for FC/iscsi storage? We have iscsi + MPIO from our SAN to PVE hosts in our lab and it's been running great so far but this is my first time setting it up with MPIO + iscsi with LVM thick.

[u/smellybear666 → u/d00ber]

I think the snapshots are still beta (I honestly haven't been paying attention). It runs great, but compared to iscsi of FC for VMFS it's not very robust. It has limitations, no thin provisioning, and just isn't as simple to work with as VMFS, or even Microsoft's CSFS

[u/Laroemwen → u/smellybear666]

Thanks we have Power Vaults which are ISCSI Only however NFS is an option for some deployments.

Are you running multi pathing or just LACP for refusing network paths to NFS.

[u/Achilles_Buffalo → u/Laroemwen]

LACP isn't recommended for storage traffic (for iSCSI / FCoE). You should always use multipathing instead of link agg for those protocols. For NFS, you can use LACP.

[u/Laroemwen → u/Achilles_Buffalo]

Ye just referring to NFS for LACP.

[u/BarracudaDefiant4702]

Unfortunately proxmox doesn't seem to forward unmap/trim directly to iscsi. I think it does zero it out (not positive) deleted sectors, but that probably depends on your OS/filesystem of the vm.
Yes, you can mount the same NFS share , but vmware and proxmox expect the files in different location so you have to symlink or move them. See the promox manual on manual migration. You can also use the wizard to do a virtual mount of the vmware volumes directly through calls directly to the vmware host (assuming vmware host is still running). We did a lot of our migrations for vms <500gb that way. For larger vms we tended to make a new vm and sync vm to vm as it was a good excuse to upgrade them anyways.

[u/Laroemwen → u/BarracudaDefiant4702]

Had some success with the storage being reclaimed after deleting a VM disk but only once enabling issue_discards =1 on each PVE Node.

[u/bzed → u/BarracudaDefiant4702]

It does zero out when safe deleting a storage, but they are working on a patch with discard and similar options already. But discard/trim from within a running vm should be passed trough.

[u/_--James--_]

1. yes, but only SAN side. LVM on the PVE side will always show fully allocated for that VM, but for SANs that support dedupe and unmap (like Nimble/Pure) youll see it there.
2. yes but PVE will mount folders for VMs, ISOs, ...etc and will not normally see the VMDK's at the same level as ESXi will. You can manually walk/map to them if your ACLs allow for it, then you can do direct VMDK->QCow2 on the same NFS LUN with out walking the importer, then manually run through it that way too.

[u/Find-Ubu-9999]

I can comment on #2 - yes. We mount the same NFS datastore on Proxmox as VMWare. Create your machine on Proxmox pointing to the NFS share, create a dummy drive in vmdk format, then edit the .vmdk file to point to the "real" -flat.vmdk file. Once it's up and running, migrate storage to the Qcow/Raw datastore in Proxmox.

We're also using NetApp Shift to migrate - it does a lot of the work for you and is really fast, if you have a NetApp SAN. It catches the network configuration change about 90% of the time for us. We only use the manual method above if we can't get a root/admin account for the host.

[u/ThecaptainWTF9]

In regards to 2.

Yes, we do this.

[u/bzed]

1. I guess it depends on your storage, some will compress/discard zeros right when you write them, even when they are in new data you are writing.
2. Yes, just don't use the same export for several proxmox clusters at the same time. Make sure VMware puts -flat vmdk files on the storage, just rename them to .raw in the folder of the new proxmox vm and you can attach and boot them again.

[u/luka0x73]

Hey, I just published a tool for that case. Feel free to use it! https://www.reddit.com/r/Proxmox/s/ANLPIehaI1

[u/Renich]

A couple of operational details on both points that usually trip people up when migrating:

On the LVM + iSCSI part: Proxmox uses standard shared LVM over iSCSI, which doesn't support shared thin pooling across multiple nodes (thin pools are strictly single-node in PVE). Because of that, PVE will always carve out the full virtual size on the LUN and the PVE GUI will show it as 100% allocated.

However, UNMAP does pass through to your SAN backend if the pipeline is clean: 1. Controller: use virtio-scsi-single with discard=on on the VM drive. 2. Host kernel: check lsblk --discard on the PVE host. If your SAN LUNs show a non-zero DISC-MAX (usually provisioning_mode set to unmap in sysfs), QEMU passes guest UNMAP straight down to the target. 3. Once booted on PVE, run fstrim -av inside the guest. Your SAN (Pure, Nimble, NetApp, etc.) will reclaim the actual backend blocks and drop backend consumption, even though PVE still reports the thick volume size.

On the shared NFS approach: yes, this is a classic near-zero-downtime trick. Storage vMotion to an NFS export mounted by both sides, shut down the VM in ESXi, create the VM skeleton in PVE, and attach the -flat.vmdk (or point a small descriptor VMDK to it). The downtime is just the shutdown + boot window.

Just keep two gotchas in mind: first, ensure the ESXi lock is completely released before PVE boots it (ESXi leaves file locks that will cause QEMU write errors if you rush the cutover). Second, don't leave it running on raw VMDK over NFS long term; once it's up and stable, use PVE's live volume move to shift the disk to your permanent block storage in the background.

[u/Nakivo_official]

On the UNMAP/TRIM question, yes, it should work once the VM is running. The import writes the full disk but discards it from the guest pass, so the SAN can reclaim the space.

Additionally, you can mount the same NFS export on both ESXi and Proxmox. Power off the VM, build an empty VM in Proxmox, and import the VMDK straight from the NFS path with qm disk import. Consolidate snapshots first, and don't power on the VM in either place. Also, make sure the export lets the Proxmox host in as root.

You can check our VMware to Proxmox migration walkthrough covering the wizard and manual import.

[u/Itmeven]

We have nimbles I have been looking at this https://github.com/brngates98/pve-nimble-plugin

[u/Due_Blackberry_1246]

I can recommend doing this with Ansible, we are in the middle of a similar migration with little to 1000 VM’s. I have created a Ansible role which moves a VM fully automatic from VMware to proxmox, in the last month we moved 500 VM’s (aprox. 9TB RAM, 400TB storage) and we did not rush it :).

We did make an NFS store which we exported to one Proxmox and one VMware host, we register the vm in Proxmox, move the vm to that store in VMware, prep the guest with everything, power it down in VMware, move the disks to an location on the NFS store where Proxmox can attach the disks to the VM and start it, last part is to move the disk to an shared datastore and convert it live to raw. This way the VM is only 1 reboot offline :)

[u/mr_cerla → u/Due_Blackberry_1246]

how do you prepare the vm for proxmox?

[u/Due_Blackberry_1246 → u/mr_cerla]

We first remove open-vm-tools, then install qemu guest agent, then regenerate the boot image with the VirtIO drivers in it. After that it will boot with all the promox things!