From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 9853D1FF0AA for ; Mon, 07 Sep 2026 22:20:09 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 8B49C21545; Mon, 07 Sep 2026 22:19:48 +0200 (CEST) Date: Mon, 07 Sep 2026 23:04:28 +0300 User-Agent: K-9 Mail for Android In-Reply-To: References: <807a9c32-cc3b-4a93-bf57-4fbce34817b6@eddie.fdn.fr> <8a9f3b2d-4fb6-481a-b69b-1464b7d46467@junkyard.4t2.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: RE: Migrating a 10TB VM from ESXi to PVE/Ceph To: pve-user@lists.proxmox.com From: Andrei Boros Message-ID: X-FE-Last-Public-Client-IP: 193.231.72.244 X-FE-Policy-ID: 2:4:2:SYSTEM DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=srr.ro; s=srr; c=relaxed/relaxed; h=date:references:mime-version:content-type:subject:to:from:message-id; bh=97NTQ89fiWXgmRk39geLiqxWSXZgQvQHuNotX00FPCY=; b=bRfr61XYC1rI9y2B7tU78IegzVG3iKfC8U2zKZ07LbqtkDXRaS5DDPOWevFymyBNeyIYeAcb0Z32 2rYPqRZFMgyADO327hxRxOdS3IvUdszo0185Rh7FbOHJghRw8Q5uD78TYo/TVXeucwQNgAV3X6h4 BNeqc9jQQtRWvkja0G0H+4yeAJ5E2tEVafooJ0HdZFgAtL+6vHM/s8MOtcJc0r1aC/czzuaZhRJN JAXvzResdm9NMR83z9OGzhIi7CIKQvpaJTUF+bgLoWVu+9/F4LYwJapJS8pWeFJoHO65fewPGj6t MhTlgY7m8s6KS4Ybp/wxjCiAKN2mwSawfsB6SQ== X-SPAM-LEVEL: Spam detection results: 0 DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy HTML_MESSAGE 0.001 HTML included in message SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 5D7EGKNGAIZS7ZINAW3RLWKK3GDRK7MD X-Message-ID-Hash: 5D7EGKNGAIZS7ZINAW3RLWKK3GDRK7MD X-MailFrom: andrei@srr.ro X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header Content-Type: text/plain; charset=utf-8 X-Content-Filtered-By: Mailman/MimeDel 3.3.10 X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE user list List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 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 >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//qemu-server/.conf) and vm--disk-.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--disk-.vmdk names used in the >.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! -- ing. Andrei Boros Serviciul IT&C 0745-115721