public inbox for pve-user@lists.proxmox.com
 help / color / mirror / Atom feed
From: Adam Thompson <athompso@athompso.net>
To: Lund Svein-Erik <sel@selund.se>, Fabien Sirjean <fsirjean@eddie.fdn.fr>
Cc: pve-user <pve-user@lists.proxmox.com>
Subject: Re: Migrating a 10TB VM from ESXi to PVE/Ceph
Date: Wed, 9 Sep 2026 13:08:35 +0000	[thread overview]
Message-ID: <YQ1PR01MB119029E934EE328F7BAB9508EABB02@YQ1PR01MB11902.CANPRD01.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <952992346.10391.1788769257095.JavaMail.zextras@selund.se>

Agreed.  Furthermore, as long as it's all on one filesystem, you can skip the need for hard links by renaming/moving the files instead.  This extends the downtime by perhaps a minute or so, as the mv(1) command runs.
-Adam

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Lund Svein-Erik <sel@selund.se>
Sent: Monday, 07 September 2026 03:20:57
To: Fabien Sirjean <fsirjean@eddie.fdn.fr>
Cc: pve-user <pve-user@lists.proxmox.com>
Subject: RE: Migrating a 10TB VM from ESXi to PVE/Ceph

NFS is the easiest way to solve this.
1) Connect nfs storage to vmware (/<export>/vmware)
2) Move vm in vmware to nfs storage
3) Remove any vmware snapshots
4) Mount nfs storage on proxmox (/<export>/proxmox)
5) Create a identical vm on proxmox with the same sized vmdk files as storage, do not start vm
6) remove vmdk files in /<export>/proxmox/
7) hardlink vmdk files from /<export>/vmware/ to corresponding location in /<export>/proxmox
8) Stop vm on vmware
9) Start vm on proxmox
10) MIgrate vm to permanent storage online.

The downtime in this move will be the time you stop the vm in vmware to you start the vm back up in proxmox.
Where and what type of nfs storage you use isn't really important as long as both proxmox and vmware can access the same export, and that the storage supports hardlinks. You might need to create the hardlinks on the nfs server it self.

--
Svein-Erik

 ---------------------------

From: "Fabien Sirjean" <fsirjean@eddie.fdn.fr>
To: "undefined" <pve-user@lists.proxmox.com>
Sent: Monday, September 7, 2026 9:08 AM
Subject: Migrating a 10TB VM from ESXi to PVE/Ceph

Dear all,
<br/>
<br/>After successfully migrating most of our infrastructure (300+ VMs) from
<br/>VMware ESXi to PVE, we're struggling with one last critical VM: our
<br/>BlueMind/Cyrus mail server (~800 users), with a 10TB virtual disk.
<br/>
<br/>Our setup is:
<br/>
<br/>Source: ESXi → Dell EMC VPLEX (FC) → Dell Unity
<br/>Target: Proxmox VE → Ceph RBD (dedicated cluster)
<br/>
<br/>We tried the Proxmox ESXi importer, but I/O performance degraded so much
<br/>during the live import that the mail service could not sustain its
<br/>normal workload.
<br/>We then stopped the service to complete the migration, but the import
<br/>eventually failed after almost 3 days, forcing us to start over.
<br/>
<br/>Application-level migration/synchronization is not an option, so we're
<br/>looking for a block/storage-level approach with minimal downtime.
<br/>
<br/>Since the datastore ultimately resides on our FC SAN, could we bypass
<br/>ESXi entirely and temporarily present the relevant VPLEX/Unity LUN to a
<br/>PVE or migration host, mount/access the VMFS datastore read-only, and
<br/>copy/convert the VMDK directly to Ceph RBD?
<br/>Even better, is there a practical way to perform the bulk copy while the
<br/>VM is running, then only synchronize the changed blocks during the final
<br/>cutover?
<br/>
<br/>Any advice or experience with direct VMFS access, VPLEX/Unity
<br/>snapshots/clones, or other approaches for this kind of migration would
<br/>be greatly appreciated.
<br/>
<br/>Thanks!
<br/>




  reply	other threads:[~2026-09-09 13:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-07  7:08 Migrating a 10TB VM from ESXi to PVE/Ceph Fabien Sirjean
2026-09-07  8:20 ` Lund Svein-Erik
2026-09-09 13:08   ` Adam Thompson [this message]
2026-09-07 16:57 ` Adam Thompson
2026-09-07 17:46 ` Tom Weber
2026-09-07 19:35   ` Adam Thompson
2026-09-07 20:04     ` Andrei Boros
2026-09-08 11:51       ` DERUMIER, Alexandre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YQ1PR01MB119029E934EE328F7BAB9508EABB02@YQ1PR01MB11902.CANPRD01.PROD.OUTLOOK.COM \
    --to=athompso@athompso.net \
    --cc=fsirjean@eddie.fdn.fr \
    --cc=pve-user@lists.proxmox.com \
    --cc=sel@selund.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal