Migration to Proxmox VE

ProxCenter provides automated migration pipelines to move virtual machines from VMware ESXi, vCenter, Hyper-V, Nutanix AHV and XCP-ng (Xen) to Proxmox VE. This is designed for organizations transitioning away from VMware or consolidating heterogeneous virtualization environments onto Proxmox.

Overview

The migration feature handles the entire workflow: connecting to the source hypervisor, downloading VM disks, converting disk formats, importing into Proxmox, and configuring the resulting VM. All progress is tracked in real time through the ProxCenter interface.

Five source types are supported:

• Standalone ESXi -- Migrates VMs from a VMware ESXi host addressed directly, including VMs on vSAN datastores
• vCenter -- Migrates VMs through a vCenter Server, which also covers clustered and vSAN-backed hosts
• Hyper-V -- Migrates VMs from a Microsoft Hyper-V host
• Nutanix -- Migrates VMs from a Nutanix AHV cluster
• XCP-ng -- Migrates VMs from XCP-ng / Xen hosts via the XAPI interface

Behind those, ProxCenter runs one of four conversion paths. Which one it picks is not a setting: it follows from the source type, the guest operating system and the mode, as detailed in Migration modes.

Migration Modes

ProxCenter offers two migration modes, selectable in the Migrate to Proxmox VE dialog.

Offline migration (cold). The source VM is powered off and its disks are copied in full, then imported into Proxmox. This works for every source type. How the disks are converted depends on the source: a vCenter, Hyper-V or Nutanix VM, and a Windows VM on a standalone ESXi, are converted by virt-v2v, which also adapts the guest; a Linux VM on a standalone ESXi and any XCP-ng VM are converted with qemu-img by the in-house pipeline, which is faster but does not touch the guest. The open-source tooling the conversion needs on the Proxmox node (nbdkit, libnbd-bin) is installed automatically during the migration if it is missing, so the offline path needs no manual node preparation.

Warm migration (CBT). The source VMware VM stays online while ProxCenter copies its disks using VMware Changed Block Tracking. A short cutover then performs a clean guest shutdown and a final delta sync, so there is no data loss on large or busy disks. The online behavior requires CBT to be usable on the source VM: when it is not (most commonly because the VM carries a pre-existing snapshot), the migration falls back to a checksum mode with very different downtime characteristics, see CBT requirements and the checksum fallback. Warm migration needs a block-storage target (LVM, ZFS or Ceph) and the VMware VDDK runtime installed on the Proxmox node.

Warm migration needs a one-time node preparation

The warm path needs a runtime the offline path does not: the VMware VDDK, a proprietary Broadcom SDK, together with the nbdkit VDDK plugin from the Debian non-free component, which a stock Proxmox node does not enable. The target node must run Proxmox VE 9: Debian 13, its base, is the first release that packages the plugin, so a Proxmox VE 8 node cannot be prepared, automatically or by hand, and the readiness check of the migrate dialog says so instead of offering the action. ProxCenter can prepare the node for you from the migrate dialog, or you can do it by hand; both are described in Warm migration node setup. Either way it is once per node, and the dialog runs a readiness check that blocks the migration until the node is ready.

Which path a migration takes

Mode	Source	Conversion path	Guest adaptation	Downtime
Offline	vCenter, Hyper-V, Nutanix	virt-v2v	VirtIO drivers injected into Windows guests	The whole transfer
Offline	Standalone ESXi, Windows guest, SSH configured on the connection	virt-v2v	VirtIO drivers injected	The whole transfer
Offline	Standalone ESXi, Linux guest, or no SSH on the connection	In-house pipeline, qemu-img	None: a Linux guest boots on any controller	The whole transfer
Offline	XCP-ng	In-house pipeline, qemu-img	None; Windows guests get an e1000 card and a SATA boot disk	The whole transfer
Warm	Standalone ESXi and vCenter only	VDDK block copy, no image conversion	None; Windows guests get an e1000 card and a SATA boot disk	A short cutover at the end
Live	XCP-ng only	XO snapshot, then the in-house pipeline	None	After the transfer, during import

Three rules explain the whole table:

• virt-v2v is the only path that adapts the guest. It maps the virtual hardware itself and installs the VirtIO drivers inside Windows guests. The other paths copy the disks as they are, so a Windows guest is given hardware it can boot without extra drivers, and you install the VirtIO drivers afterwards. See the guest hardware mapping in Configure.
• For a standalone ESXi source, the guest operating system decides. Windows guests are routed through virt-v2v for the driver injection, provided SSH is configured on the connection, because that path needs it to read the VMX and the disks. Linux guests stay on the in-house pipeline, which is faster and has nothing to adapt.
• For vCenter, Hyper-V and Nutanix, every guest goes through virt-v2v, Linux included. This is not about the guest: those sources have no in-house implementation, and virt-v2v is the only component that knows how to read them.

Warm migration never converts an image

The warm path reads changed blocks through the VDDK and writes them straight into the target block device, so there is no image conversion step and no place to inject anything. Its Converting disks phase is the optional post-migration qcow2 rewrite described in Migration options, not a guest conversion. A Windows VM migrated warm therefore boots on emulated hardware and needs its VirtIO drivers installed afterwards, exactly like the in-house offline path.

Modes offered per source

The mode selector only appears for sources that have more than one mode. Hyper-V and Nutanix are offline-only. Standalone ESXi and vCenter offer Offline and Warm. XCP-ng offers Offline and Live, since warm migration relies on VMware CBT and is rejected for non-VMware sources.

CBT Requirements and the Checksum Fallback

Warm migration keeps the source VM online only when VMware Changed Block Tracking (CBT) can actually be used. CBT is available when all of the following are true:

• The VM has no pre-existing snapshots. ProxCenter needs to establish the initial CBT baseline, and VMware only provides a reliable one on a snapshot-free VM.
• The virtual hardware version is vmx-07 or newer.
• No disk is in independent mode and no disk uses multi-writer sharing.

ProxCenter enables CBT on the source VM when needed. This is a standard VMware configuration flag, the same one backup products use, and it stays enabled after the migration.

When any of these conditions is not met, the migration automatically falls back to a checksum block-diff. The fallback is lossless, but its behavior differs from the CBT path in two important ways:

• The source VM is shut down at the very start of the copy, not at cutover, and stays powered off until the migration completes. Downtime therefore scales with total disk size, instead of the short final-delta cutover of the CBT path.
• Before any data is copied, ProxCenter reads each disk in full on both the source and the target to compute block checksums. On large disks this scan phase alone can take a long time.

The job log states which mode is in use: when the fallback is selected, a warning line reading CBT unavailable (pre-existing snapshot) - using checksum block-diff fallback appears at the start of the migration.

Since v1.4.7 the warning also arrives before you start. Selecting warm mode for a VM that cannot use CBT shows "CBT unavailable: this warm migration will use the checksum fallback" in the dialog, names which of the three conditions is not met, and spells out the consequence: the source VM is shut down at the start of the copy and stays powered off for the whole transfer, so downtime scales with the total disk size. When the cause is a snapshot, it adds that removing or consolidating the VMware snapshots before starting keeps the VM online until the short cutover.

Keep the VM online: remove snapshots first

If minimizing downtime is the goal, delete or consolidate all VMware snapshots on the VM before starting the warm migration. With a snapshot-free VM, CBT is used, the bulk of the data is copied while the VM keeps running, and the VM is only shut down for the short final delta sync at cutover.

Warm Migration Phases and Progress

A warm migration reports the phase it is in, and inside the long phases it reports the disk being worked on, the data transferred, the live throughput and an estimate of the time left. Before v1.4.7 the two longest phases (pre-zeroing a thick target and the copy itself) showed an indeterminate bar, so a job that was progressing normally was indistinguishable from a stalled one.

Phase	What is happening
Planning	Reading the source configuration and deciding whether CBT can be used
Enabling CBT	Setting the Changed Block Tracking flag on the source VM
Preparing target disks	Allocating the target volumes, and pre-zeroing them when the target storage requires it
Full copy	The first full pass, with the source VM still running on the CBT path
Delta sync	Each subsequent incremental pass, narrowing the remaining delta
Awaiting cutover decision	The pipeline is holding, waiting for the operator to confirm the cutover
Shutting down the source VM	Clean guest shutdown before the last delta
Waiting for the source to power off	The shutdown was asked for and the source has not confirmed it yet, see Waiting for the source to power off
Cutover	Final delta, target VM creation and disk attachment
Verifying	Post-cutover checks
Converting disks	Optional post-migration qcow2 conversion, when it was requested

The percentage is on a fixed scale, so it is comparable between runs: preparing the target disks covers 0 to 10, the full copy 10 to 80, the delta passes 80 to 95, and the cutover, verification and attach the last 5. Opening the job from the tasks bar adds a detail line under the bar reading the phase, the disk being worked on, the data transferred, the throughput and the estimated time left.

A run held for a manual cutover is the one exception to that scale: it has no last pass to aim at, so the bar parks at 90 for as long as the hold lasts instead of creeping to 95 and stalling there for hours. See Choosing the cutover moment.

Pre-zeroing only concerns thick storage

LVM-Thin, ZFS and Ceph RBD hand back volumes that are already zeroed, so the Preparing target disks phase is short on those targets. On a thick LVM target the zeroing pass is mandatory and writes the full declared capacity of every disk, which can take hours on a multi-terabyte VM. The job log names the disk and its size when it starts, the phase reports the throughput as Zeroing: <n> MB/s while it runs, and a log line records each disk as it advances. If the storage array refuses the write-zeroes offload, the job says so and streams the zeros in parallel ranges instead.

The checksum fallback has a scan phase of its own

On the checksum path the job first reads each disk in full on both sides. During that phase it reports progress but no throughput, and the log states plainly that nothing is being copied yet. Each disk's share of the bar is split between the scan and the copy that follows it.

Choosing the Cutover Moment

A warm migration ends with a short cutover: the source guest is shut down, a last delta is copied, and the target VM is created and started. Who decides when that happens is a per-migration choice, made in the Migrate to Proxmox VE dialog with the Automatic cutover switch, which is on by default.

Automatic cutover (the default)

The switch on, the run cuts over by itself as soon as the projected downtime fits the downtime budget. The projection is recomputed after every delta pass from the bytes that pass moved and the throughput it achieved, plus a fixed allowance for the guest shutdown and the boot on the target.

The budget is settable in the same dialog, right under the switch, and only appears while the cutover stays automatic, since a run held for the operator ignores it. It is a slider paired with an exact seconds field:

• the slider walks a curated scale (30 s, 1 min, 2 min, 5 min, 10 min, 15 min, 30 min, 1 h, 2 h, 6 h, 12 h, 24 h), fine where the decision is actually made and coarse beyond;
• the field beside it takes any exact number of seconds, for a maintenance slot that sits between two stops of the slider;
• the accepted range is 30 s to 24 h, which is the range the API enforces, and an out-of-range value blocks the Migrate button instead of being refused after the job exists;
• leaving the field empty keeps the pipeline default of 300 s.

If the projection never fits the budget, the run does not cut over silently with a large downtime. After five delta passes it escalates to an operator decision: the job parks in Awaiting cutover decision and the job log states the projection, the budget and the two ways out. That gate expires after two hours, and the job then fails rather than holding a VDDK session open for ever.

Manual cutover

Turn Automatic cutover off and nothing but you ends the run. The migration keeps issuing delta passes, paced at one per minute so a converged source does not snapshot vCenter in a tight loop, and it has no expiry: it waits as long as your maintenance window needs. Every pass refreshes the projection, so the downtime shown at the moment you click is the real one and not an estimate from an hour ago.

A held run stays in the Delta sync phase rather than moving to Awaiting cutover decision, and every surface that shows a migration status labels it Waiting for cutover all the same.

The hold is a single-VM option

The Automatic cutover switch and the downtime budget appear in the single-VM migrate dialog only. A batch held for the operator would need one cutover click per VM and would keep as many VDDK sessions open as there are VMs, so a bulk migration always uses the automatic cutover with the default budget.

Where the controls are

The switchover and cancel controls are one and the same component in two places, so they cannot drift apart:

• in the Migrate to Proxmox VE dialog, while it is open on the run you started;
• in the VM panel of the source VM, in the Migration to Proxmox VE card, next to the source-to-target flow. That card carries the status chip, a line naming what the run is waiting for, the estimated downtime, and the buttons that resolve the wait: Cutover now, Force power off, Choose system and Cancel migration.

Cutover now appears as soon as a delta pass has produced an estimate, and asks for a confirmation stating the downtime to expect. Cancelling a run whose target already holds a copy asks for its own confirmation, see the cancellation question in Troubleshooting.

Waiting for the Source to Power Off

The cutover asks the guest to shut down cleanly through VMware Tools, then waits for vSphere to confirm a powered-off state. Before v1.4.8 that wait was five minutes of complete silence: no status change, no log line, no action. A guest that refused the request cost the entire transfer, which on a large VM meant hours.

The wait is now a step of its own, Waiting for the source to power off:

• it announces itself in the job log, saying whether the shutdown request was refused outright or simply not honoured yet;
• it restates the time left every minute;
• its budget is 30 minutes, not five, and it is still bounded so an unattended job fails cleanly instead of pinning a VDDK session and a transfer snapshot for ever;
• it offers a Force power off button, in the migrate dialog and in the VM panel.

The hard power off is never automatic. It stops the source as if it had lost power, which makes the final delta crash-consistent, so it stays the operator's decision and its confirmation says exactly that before firing. Shutting the guest down from inside stays the better option whenever it is available.

A host that refuses the hard power off too, which is what an ESXi licence restriction does, is logged and the wait continues: the operator can still shut the guest down from within. Before, that refusal crashed the job.

The checksum fallback waits the same way

The checksum block-diff fallback shuts the source down before copying anything, not at cutover. It goes through the same step, the same 30 minute budget and the same Force power off action. One difference matters: on the CBT path a completed copy already exists on the target and is kept if the wait elapses, while on the fallback path nothing has been copied yet, so the volumes are freed.

vSphere faults now name what was refused

<faultstring> alone is a generic vCenter wrapper, and an incident could report nothing better than A general system error occurred: Undeclared fault while the concrete fault sat in the detail block ProxCenter was discarding. A SOAP error now reads as the fault string, the concrete fault type and any localized message vSphere returned, separated by |, so the job log carries what vSphere refused rather than the wrapper around it.

vSphere Snapshot Waits

Every warm pass creates a transfer snapshot on the source VM and removes it afterwards, and the removal is what makes vCenter merge the delta back into the base disk. Before v1.4.7 all three snapshot helpers polled their vSphere task with the same fixed 120 second loop, and two of them simply returned when it elapsed. A large VM therefore hit two distinct failures: a removal was reported as done while vCenter was still consolidating, and the next pass then asked for a snapshot on a VM that could not take one and failed with Snapshot creation timed out after 120s, sometimes after a copy that had run for hours.

ProxCenter now follows each vSphere task to completion, with budgets sized for real workloads, and it always raises an error rather than reporting an unfinished task as done. Before each pass it also waits out any consolidation still in flight on the source VM.

Operation	Budget
Create a transfer snapshot	30 minutes
Remove a snapshot whose merge a later pass depends on	4 hours
Wait out a consolidation already in flight	4 hours
Remove the last snapshot of a run, or clean up after a failure	15 minutes
Create the cutover snapshot	5 minutes
Consolidate during cutover	2 minutes

These budgets are fixed in the product; there is no setting to change them. The cutover budgets are deliberately short because the source VM is already powered off at that point and every extra wait is guest downtime. When a budget does elapse, the vSphere task keeps running on the vCenter side; ProxCenter stops waiting and fails the job with the operation, the object and the budget named in the error.

Transfer snapshots are named and swept

Warm transfer snapshots are created with a proxcenter-warm- name prefix. If a job fails, cleanup resolves them by name and removes any that remain on the source VM, so a snapshot that vCenter created after a timed-out request cannot be left growing on a production VM unnoticed. The waits are also sliced so a job stays cancellable while it is waiting on vCenter.

Prerequisites

• Source hypervisor credentials with permission to read VM metadata and export disks. See Source hypervisor privileges for the exact vCenter and ESXi role to grant.
• Target Proxmox API credentials with permission to create VMs and write to the target storage.
• SSH access to the target Proxmox node for import and conversion operations.
• Enough temporary storage and network bandwidth for full disk transfers.
• VirtIO drivers available for Windows guests when using VirtIO disk or network devices.
• For warm migration, the target Proxmox node must run Proxmox VE 9 and needs the VMware VDDK runtime installed once. See Warm migration node setup.

For large migrations, validate one representative VM before scheduling a bulk migration window.

Source hypervisor privileges

ProxCenter never modifies the source VM. It authenticates to the source hypervisor, reads the VM configuration and inventory, and exports the disks. The account you use therefore needs read access plus the right to export a VM. The exact requirements differ slightly between a standalone ESXi host and a vCenter.

vCenter

vCenter migrations use the canonical NFC transport: ProxCenter asks vCenter to open an export lease (the ExportVm and ExportSnapshot API) and streams the disks over it. This requires the vApp > Export privilege. When it is missing, vCenter rejects the export with SOAP error 500: Permission to perform this operation was denied, and the migration stops at the "Initiating NFC export lease" step.

The simplest least-privilege setup is to clone the built-in Read-only role, add the privileges below, then assign the resulting role to your migration user at the datacenter level, propagated to child objects so it covers both the VMs and their datastores.

Privilege	Required for
vApp > Export	Opening the NFC export lease. Mandatory, this is the privilege that triggers the SOAP 500 above when absent.
Virtual machine > Provisioning > Allow read-only disk access	Reading the disk data over the lease
Virtual machine > Provisioning > Allow virtual machine download	Downloading the disk and descriptor files
Virtual machine > Interaction > Power Off	Offline migration powers the source VM off before export
Virtual machine > Snapshot management > Create snapshot	Warm migration creates a transfer snapshot
Virtual machine > Snapshot management > Remove snapshot	Warm migration removes the transfer snapshot after cutover
Read-only (built-in role, used as the base)	Authentication and reading VM configuration and inventory

The built-in Administrator role already includes all of these, so an administrator account works without any extra configuration. The table above is only needed when you want a dedicated, least-privilege migration account.

Standalone ESXi

A direct ESXi migration downloads the disks over the host datastore API rather than through an NFC lease. A user in the host Administrator role works out of the box. For a restricted account, grant read access to the VM and its datastore, plus Virtual machine > Interaction > Power Off for offline migration.

Pipeline Stages

Each migration goes through these sequential stages:

1. Download

The VM disk is downloaded from the source hypervisor. For ESXi, this uses the VMware VDDK / HTTP file access. For XCP-ng, the disk is exported via the XAPI export interface.

2. Convert

The downloaded disk is converted to a Proxmox-compatible format using qemu-img convert. VMDK files (ESXi) and VHD files (XCP-ng) are converted to qcow2 or raw format depending on the target storage type.

3. Import

The converted disk is imported into Proxmox using qm disk import, which uploads the disk to the selected target storage and associates it with a new or existing VM.

4. Configure

The imported VM is configured with the original settings: CPU count, memory, network interfaces, and boot order. The boot disk is set automatically so the VM is ready to start.

info

For EFI-based VMs, ProxCenter automatically handles the EFI disk allocation. The data disk may be assigned to disk-1 instead of disk-0 since disk-0 is used for the EFI disk.

Guest hardware mapping. On the direct ESXi pipelines (cold and warm) and on the XCP-ng pipeline, the target hardware is derived from the source configuration:

Setting	Value on the migrated VM
Machine type	q35
Firmware	ovmf when the source VM boots UEFI, seabios otherwise
Disk controller	virtio-scsi-single, for every guest
Boot disk slot	sata0 for Windows guests and for UEFI guests, scsi0 otherwise
Data disks	SCSI, on the VirtIO SCSI controller
Network card	e1000 for Windows guests, virtio otherwise (a source E1000 or E1000e card stays e1000)
MAC address	Preserved from the source NIC
QEMU guest agent	Enabled

Why the boot disk lands on SATA

A raw block copy of a Windows disk carries no boot-start driver for the emulated LSI 53C895A controller, so before v1.4.7 every BIOS-firmware Windows guest stopped at first boot with INACCESSIBLE_BOOT_DEVICE. AHCI (SATA) is inbox and boot-start in every supported Windows, so the boot disk is now placed on sata0 while the data disks stay on the VirtIO SCSI controller, where they appear as soon as the VirtIO drivers are installed inside the guest. UEFI guests already followed this rule, because OVMF cannot enumerate an LSI controller. No option to set: the decision is taken from the detected guest OS and firmware.

vCenter, Hyper-V and Nutanix sources migrated offline take the virt-v2v route instead, which performs its own hardware mapping and injects the VirtIO drivers into Windows guests. A warm migration always uses the mapping above, including when the source is a vCenter.

Changing the machine type afterwards. Migrated VMs are created with the q35 machine type. When a guest is pinned to the older i440fx chipset, change it from the Machine Type row of the VM's Hardware > System panel, where the option reads pc (i440fx). ProxCenter sends that machine as pc, which is the spelling qemu-server accepts; until v1.4.7 the select sent the literal i440fx and Proxmox rejected it with Parameter verification failed / machine.type: value does not match the regex pattern, so in practice only q35 could be saved. A machine string carrying a version pin (pc-i440fx-9.2+pve1) or extra keys (viommu, aw-bits, enable-s3, enable-s4) is handled as well: the pin is preserved while the family stays the same, and dropped only when you switch family, because a pin is family specific.

Warm Migration Node Setup

Before the first warm migration to a Proxmox node, that node needs the VDDK runtime. The dialog probes the selected node and shows "Target node is not ready for warm migration" with the list of missing components until all of them are present. This is a one-time setup per node, and ProxCenter can carry it out for you.

The warm path needs four components on the Proxmox node:

Component	Source	Notes
nbdkit	Debian main	Available on a stock Proxmox node.
nbd-client	Debian main	Available on a stock Proxmox node.
nbdkit-plugin-vddk	Debian contrib / non-free	Not enabled by default on Proxmox. Enable the repositories first.
Broadcom VDDK (libvixDiskLib.so*)	Installed by ProxCenter	Proprietary Broadcom SDK. Broadcom withdrew its public download in August 2026, so ProxCenter ships it to Enterprise subscribers and installs it on the node.

Network access to the ESXi hosts (TCP 443 and 902)

Warm migration copies disk data with the VMware VDDK in NBD transport mode, which uses the NFC (Network File Copy) protocol. The target Proxmox node must reach each source ESXi host on both TCP 443 (authentication and management) and TCP 902 (the NFC data channel that carries the disk blocks).

Port 443 alone is not enough. Authentication and the node readiness check will pass, the target disks will be allocated, and the migration will only fail later at the VixDiskLib_Open step against the ESXi host, when VDDK opens the NFC data channel. Open TCP 902 from the Proxmox node to every ESXi host before starting a warm migration.

1. Let ProxCenter prepare the node

In the Migrate to Proxmox VE dialog, choose Warm Migration and select the target node. When the node is not ready, the readiness alert lists what is missing and offers Prepare the node. Confirm, and ProxCenter performs the whole preparation over SSH:

• installs nbdkit and nbd-client from the Debian repositories
• adds /etc/apt/sources.list.d/proxcenter-nonfree.list to enable the Debian contrib and non-free components, then installs nbdkit-plugin-vddk
• downloads the VDDK into /usr/lib/vmware-vix-disklib (about 96 MB on disk) and creates the library symlink the Proxmox nbdkit expects
• loads the nbd kernel module with max_part=0, now and at every boot

It takes a couple of minutes, and the alert turns green when it is done. Running it again on a prepared node is harmless: every step is skipped when it is already satisfied, and nothing is re-downloaded.

The Proxmox node needs outbound HTTPS to ghcr.io for the download, the same requirement as the ProxCenter high-availability images. The registry credentials stay on the ProxCenter server, which hands the node a short-lived, download-only token; the Enterprise installer configures them, so there is nothing to type.

Prepare the node is missing from the dialog

Two distinct causes hide the automated action.

The node runs Proxmox VE 8. The readiness alert then states the requirement instead of listing missing components: warm migration needs Proxmox VE 9, and such a node cannot be prepared at all, since Debian 12 does not package the nbdkit VDDK plugin.

The ProxCenter container does not hold the registry token. The action appears only when GHCR_TOKEN reaches the frontend container. An installation upgraded to v1.4.8 by pulling the images alone does not have it: the compose file passes its environment through an explicit environment: list, and the line that carries the token was added by that same release. The readiness alert then lists what the node is missing and links to the manual path below, with no automated action offered. Re-run the standard Enterprise install command to fix it, as described in Updating ProxCenter: it refreshes the compose file, writes the token, and preserves your secrets, your customised URLs and your data.

Why ProxCenter ships the VDDK

The VDDK is a proprietary Broadcom SDK. Broadcom withdrew its public download in August 2026: the developer-portal link returns a 404 and the kit is no longer listed in the public SDK catalogue, so a new customer cannot obtain it there. ProxCenter therefore ships the runtime to Enterprise subscribers, unmodified and with its Broadcom license notice, and installs it on the nodes that need it.

2. Or prepare the node by hand

Use this path when the Proxmox node has no outbound access to the registry, or when your policy requires you to place the runtime yourself. Run everything as root on each target node.

nbdkit and nbd-client, from the standard Debian repositories:

apt update
apt install nbdkit nbd-client

On a node without a Proxmox subscription, apt update exits with a 401 on the enterprise.proxmox.com repository. That is harmless here, since these packages come from the Debian repositories.

The nbdkit VDDK plugin, which lives in Debian non-free. Enable contrib and non-free in the node's apt sources, then install it:

. /etc/os-release
echo "deb http://deb.debian.org/debian ${VERSION_CODENAME} contrib non-free non-free-firmware" \
  > /etc/apt/sources.list.d/proxcenter-nonfree.list
apt update
apt install nbdkit-plugin-vddk

The Broadcom VDDK. It is not in any package repository, and since August 2026 it is no longer a public download. Obtain the Linux x86_64 archive from Broadcom through your own entitlement: a support case opened with the account that carries your vSphere subscription, your backup software vendor, or a copy your organisation already holds. Any VDDK 9.x release works, and Broadcom supports 9.x against vSphere 7.0.x and 8.0.x.

Then install the runtime libraries under /usr/lib/vmware-vix-disklib, so that libvixDiskLib.so* ends up in /usr/lib/vmware-vix-disklib/lib64/:

mkdir -p /usr/lib/vmware-vix-disklib
tar xzf VMware-vix-disklib-*.tar.gz -C /usr/lib/vmware-vix-disklib --strip-components=1
ldconfig

VDDK 9.x library name

The nbdkit shipped with Proxmox loads the libvixDiskLib.so.8 library name. With VDDK 9.x, create the matching symlink (VDDK 8.0.x ships .so.8 directly and needs none):

cd /usr/lib/vmware-vix-disklib/lib64
ln -sf libvixDiskLib.so.9 libvixDiskLib.so.8
ldconfig

The strongest single check that the plugin and the library agree:

nbdkit vddk libdir=/usr/lib/vmware-vix-disklib --dump-plugin

It prints the plugin's version block with no error. A complaint about a missing libvixDiskLib.so.8 means the symlink is absent.

3. Prevent LVM from auto-activating guest volume groups

Required when migrating Linux guests that use LVM (most enterprise Linux templates). During a warm migration the guest disk is attached to the Proxmox node as an NBD device. If the node's LVM scans it, it auto-activates the guest's volume group on the host and pins the NBD device: the migration can no longer release it afterwards, nbd-client -d and rmmod nbd both fail, and the device stays wedged until the node is rebooted.

Tell LVM to ignore NBD devices on the target node. Edit /etc/lvm/lvm.conf and, in the devices { } section, set:

global_filter = [ "r|/dev/nbd.*|", "a|.*|" ]

Then reboot the node. The reboot both applies the filter and clears any device that is already wedged. If you prefer not to reboot, run vgchange -an <guest-vg> for the activated guest volume group and pvscan --cache after editing the file.

Why this is safe on Proxmox

Proxmox's own LVM and LVM-Thin storage lives on physical disks, never on /dev/nbd*, and warm migration reads the guest disk as a raw device rather than through LVM. The filter only stops LVM from touching the transient NBD devices used during migration.

4. Reselect the node

Back in the Migrate to Proxmox VE dialog, reselect the target node. The readiness check runs again and, once every component is detected, shows "Target node is ready for warm migration" and enables the migration button.

What the readiness check verifies

ProxCenter confirms nbdkit and nbd-client are on PATH, that nbdkit-vddk-plugin.so exists under /usr/lib or /usr/lib64, and that libvixDiskLib.so* exists under the VDDK library directory (/usr/lib/vmware-vix-disklib/lib64 by default).

Starting a Migration

Migration has no page of its own: a source hypervisor is declared as a connection, and it then appears in the inventory alongside your Proxmox clusters.

1. Declare the source in Settings > Connections, with the Add ESXi button and its equivalents for the other source types (ESXi or vCenter, XCP-ng, Hyper-V, Nutanix). ProxCenter connects and reads its inventory.
2. Open Infrastructure > Inventory. The sources are listed in the MIGRATIONS section of the tree, at the bottom, grouped by hypervisor type and showing the host and VM counts.
3. Expand a source to reach its VMs, or click the MIGRATIONS header itself for the migration dashboard, which lists past and running migration jobs.
4. Select one or more VMs and click Migrate to Proxmox. Several VMs open the bulk dialog, see Bulk Migration.
5. Choose the migration mode, then the target Proxmox connection, node, and storage.
6. Configure the options (VM name, VMID, network bridge, and the ones described in Migration Options).
7. Start the migration, and follow it from the tasks bar, the migration dashboard or the Task Center.

The Target Storage list

The Target Storage selector is filled by asking the selected Proxmox node to enumerate its storages. Proxmox walks every declared backend before answering, so a datacenter that declares many PBS targets legitimately needs 20 seconds or more, well past the 8 second budget ProxCenter used to apply to every call. The field then rendered empty and greyed out, with no reason given, and the Migrate button never enabled.

That read now takes a longer budget of its own, and the field says which of three things is happening:

• Loading storage list..., with a spinner, while the node is answering;
• Could not read the storage list: followed by the reason the server returned and a Retry link, when the read failed;
• No storage on this node accepts disk images, when the node genuinely exposes none.

Both budgets are settings, see Timeouts and gates. Raising the slow one is the right answer for a datacenter with many PBS storages; the short one governs the polling ProxCenter does everywhere else and should stay short.

A read that times out no longer counts towards the node-failover circuit breaker either. A host that answers slowly has answered, so a busy but healthy cluster is no longer reported as having every node unreachable.

The Target VMID

Target VMID is optional: left empty, Proxmox allocates the next free id on the target cluster. When you type one, the dialog checks it against the target cluster itself while you type and reports available, taken or invalid next to the field, and the Migrate button stays disabled on the last two.

The same rule now applies to the other dialogs that create a guest. Proxmox only requires a VMID to be unique inside its own cluster, and neither a clone, a create nor a migration ever crosses a connection. With two clusters connected, Clone, Create VM and Create LXC used to be fed the merged inventory of every connection, so an id already used on the second cluster was refused on the first: cloning a template could become outright impossible, because the dialog suggested an id and then rejected it. Availability and the suggested next id are now computed on the connection the guest is created on.

MSP and vDC tenants keep their cross-cluster rule. A tenant VMID range is an explicit contract rather than a Proxmox constraint, and it stays enforced server side on the create, clone and template-deploy routes.

Migration Options

Beyond the target selection, a few options in the Migrate to Proxmox VE dialog change what the pipeline does. Most appear in the single-VM dialog and in the bulk dialog; the two cutover options are single-VM only, as noted below.

Option	Shown when	Default	Effect
Temporary Storage	Offline migrations only	Preselected from the node preflight	Where virt-v2v and the direct-ESXi pipeline write their temporary files. /tmp on a Proxmox node is often a small tmpfs, so pinning the multi-gigabyte work to a real filesystem avoids a mid-migration "no space left on device". The helper text shows the free space of the selected mount and turns into an error when it holds less than twice the source disk size.
Root filesystem (advanced)	Offline migrations that use virt-v2v	Empty (automatic selection)	Names the system to convert on a guest that has more than one. Left empty, ProxCenter picks it automatically, and only asks when the choice is genuinely ambiguous, see Guests with several bootable systems. The value is a device name exactly as virt-v2v reported it in the job log, for example /dev/system/root.
Automatic cutover	Warm migrations, single-VM dialog only	On (a switch)	On, the run switches over by itself once the projected downtime fits the budget. Off, it keeps replicating and waits for you, see Choosing the cutover moment.
Downtime budget	Warm migrations with Automatic cutover on, single-VM dialog only	300 s	The projected downtime the run accepts before it cuts over on its own. A slider on a curated scale, paired with an exact seconds field, over the 30 s to 24 h range the API enforces.
Convert disks to qcow2 after migration (enables Proxmox snapshots)	The selected target storage is a thick LVM storage	Off (a toggle)	After the migration completes, each disk is rewritten to qcow2 in the background, live, while the VM runs. This restores the ability to take Proxmox snapshots on a thick LVM target, whose volumes are allocated raw.

The last three sit at the bottom of the Target -- Proxmox VE panel, under Start VM after migration, in that order. Each carries a ? icon with the full explanation.

The qcow2 conversion is a full disk rewrite

It can take hours on a multi-terabyte disk and it temporarily uses double the space on the target storage. There is no downtime, the VM keeps running while it happens, but do not schedule it on a storage that is already close to full. The job reaches the Converting disks phase once the VM itself is migrated and usable.

Why the qcow2 option only appears on thick LVM

LVM-Thin cannot hold a qcow2 image, and ZFS and Ceph RBD snapshot natively, so the option is hidden on those targets. Directory and NFS targets already receive qcow2 images. Thick LVM is the only case where the migrated volume is raw and therefore has no snapshot support until it is converted. The option is re-checked against the selected storage when the migration is launched, so a toggle left on for an earlier LVM pick cannot leak into a run against a storage it does not apply to, and the server re-validates that the storage really defaults to qcow2 (an LVM storage with snapshot-as-volume-chain) before converting anything.

The conversion never fails the migration

When the conversion is skipped or does not complete, the migration is still a success: the VM is migrated and usable, its disks are simply still raw. The job log says which case applied, and the reasons it can decline are named there: the storage does not default to qcow2, there are no raw data disks to convert, or the free space left on the target is below the size of the largest disk to convert (the conversion transiently needs a second full copy of the disk). You can convert a disk later by hand with Move disk on the same storage, choosing the qcow2 format.

Temporary storage does not apply to warm migration

The Temporary Storage selector, and the free-space check attached to it, are only shown for offline migrations. On the warm path nbdkit streams the disk data from VMware straight into the target block device and nothing large ever lands on the node's temporary filesystem. Until v1.4.7 the selector was shown in warm mode too, where it compared the free space of /tmp against twice the source disk size and reported "Insufficient space" on a migration that needed none.

Guests with Several Bootable Systems

virt-v2v inspects the source disks to find the operating system it must convert. When it finds more than one, its default behaviour (--root ask) is to print a numbered list and wait for an answer on standard input. ProxCenter launches the conversion detached, with no console attached, so that question has to be answered without a prompt: left to itself the process read end of file and died with virt-v2v: error: exception: End_of_file, on a vCenter source only after the disks had been transferred in full.

This situation is not limited to dual-boot machines. A SUSE or openSUSE guest using btrfs with snapper is affected by design: every snapshot subvolume is inspected as a separate operating system, so a single installed system can be reported as a dozen candidates. The guest that surfaced this listed sixteen.

The conversion never prompts. It runs with its standard input closed, so a prompt fails immediately and deterministically instead of depending on when the SSH channel happens to close. That holds on every input path: direct ESXi, vCenter over NFC, Hyper-V, Nutanix.

What ProxCenter does with the list. It reads the candidate list back from the failed run, discards the btrfs snapshot subvolumes, and if exactly one real system remains it retries the conversion once, straight away, with that system pinned. Nothing to do, and nothing is transferred twice: the disks are already on the Proxmox node at that point, and the partial output of the first attempt is removed so it cannot be attached as a stray extra disk. The job log names the candidates and the system it picked.

ProxCenter never falls back to "convert the first one". The virt-v2v manual states the root ordering is not meaningful, and converting a read-only snapshot subvolume would inject the VirtIO drivers and rebuild the initramfs in the wrong place, producing a VM that does not boot.

When the choice is genuinely ambiguous. If two or more real systems remain, ProxCenter does not guess. The job parks on the Awaiting system choice step, keeps the disks it has already downloaded, and a Choose system button appears in the migrate dialog and in the Migration to Proxmox VE card of the VM panel. It opens a list with one entry per system found, each with the description virt-v2v reported, and picking one resumes the conversion immediately without transferring the disks again.

The pause is bounded: after two hours by default the job gives up and releases the temporary space it was holding on the node. That budget is a setting, see Timeouts and gates.

Cancelling a parked job stops it for real. Until v1.4.8 the cancel route did not signal the virt-v2v pipeline, so the row changed state while the conversion kept waiting on the gate.

You can also decide up front with the Root filesystem (advanced) field described in Migration options. The value must be one of the device names the job log reported, for example /dev/system/root on an LVM guest or /dev/sda2 on a plain disk; it is validated against the candidate list rather than merely sanitized, because it reaches a command line on the Proxmox node. An entry that points inside .snapshots is a read-only snapshot and is never the right target.

Older failures

Before this behavior existed, such a migration failed with virt-v2v: error: exception: End_of_file. A job that ended that way can simply be started again.

Timeouts and Gates

Three settings govern how long ProxCenter waits, and they are the ones the migration paths above refer to. All three are optional environment variables of the ProxCenter frontend container, all three take milliseconds, and leaving one empty keeps its default. An unusable value is ignored with a warning in the server log rather than applied.

Variable	Default	What it governs
PVE_TIMEOUT_MS	8000 (8 s)	The budget for a regular Proxmox API call. This is what the polling everywhere in the product relies on, so keep it short.
PVE_SLOW_READ_TIMEOUT_MS	30000 (30 s)	The budget for the reads that make Proxmox enumerate every declared backend, the migration Target Storage list first among them. Raise it on a datacenter declaring many PBS targets.
V2V_ROOT_CHOICE_TIMEOUT_MS	7200000 (2 h)	How long a cold migration parked on Awaiting system choice waits for an operator before it gives the node's temporary storage back.

The two Proxmox budgets are passed through by all three stacks (Community, Enterprise and high availability). The virt-v2v gate reaches the Enterprise and high-availability stacks only, since migration is an Enterprise feature. See Installation for where to set them.

The waits inside a warm migration are not settings: the vSphere snapshot budgets and the 30 minute power-off budget are fixed in the product, and the downtime budget is a per-migration option of the dialog rather than an environment variable.

Bulk Migration

You can select multiple VMs and migrate them in a single batch. Migrations run sequentially to avoid overloading the network and storage. The Task Center shows progress for each VM individually.

tip

For large migrations, consider running them during off-peak hours. Each VM migration involves downloading the full disk image, which can take significant time depending on disk size and network bandwidth.

Cross-Cluster Migration

ProxCenter tracks progress for offline cross-cluster VM moves between Proxmox environments. Progress updates are reported in the UI so operators can distinguish long-running disk transfer from stalled operations.

When migrating to another cluster, you can target a specific VMID on the destination. VLAN tags on migrated network interfaces are preserved when the target bridge supports the same network design.

Pre-migration checks

Moving a guest between Proxmox nodes or clusters is driven from the VM's Migrate dialog, which runs a set of checks before it lets the move start. Two of them are new in v1.4.7.

CPU type on the destination cluster (cross-cluster tab). The pre-check reads the QEMU capabilities of the target node and compares them with the VM's configured CPU type. When the type is not reported by the target, the check fails with CPU type "<name>" is not available on target node "<node>". Custom CPU models get their own explanation, because they are cluster-local: a custom- model is defined in /etc/pve/virtual-guest/cpu-models.conf on each cluster, so a model that exists on the source is invisible to the destination unless it was defined there too. The check tells you to define the same model on the target cluster or to switch the VM to a built-in CPU type before migrating. If the capabilities cannot be read at all, the result is a warning rather than a blocking error. host and max are not checked, since they are resolved by the destination node itself.

Custom CPU models are also offered in the CPU type selects, so a VM already using one no longer shows an empty field when you open its hardware settings.

HA resource affinity rules (node selection). When the cluster defines HA affinity rules, the node list flags every node that would violate a negative ("keep separated") rule with a red shield icon and the tooltip "Negative HA affinity with <peers>". Selecting such a node shows a conflict panel:

Situation	Severity	What ProxCenter does
The peer that must stay separated is running on the selected node	Error, PVE will reject this migration: ...	The migrate button is disabled, since the HA manager would refuse the move anyway
The peer is assigned to that node but not running	Warning, ... The HA manager may still reject this migration.	The migration stays available, at your own risk
The VM is in a positive affinity rule ("kept together")	Information	A separate panel names the peers the HA manager will migrate along with this VM

The recommended node also skips any node holding a running peer that must stay separated. The check reads the cluster's HA rules and HA status, and it fails open: a guest that is not HA managed, a Proxmox version without resource affinity rules, or an unreadable rules list produce no conflict and no block.

vSAN Support

ProxCenter supports migrating VMs from ESXi hosts that use VMware vSAN storage. The migration pipeline handles the vSAN object retrieval transparently -- no special configuration is needed beyond providing valid ESXi credentials with read access to the datastore.

Storage Considerations

The target storage type affects the import behavior:

Storage Type	Disk Format	Volume Naming
Local (directory)	qcow2	local:VMID/vm-VMID-disk-N.qcow2
NFS	qcow2	nfs-storage:VMID/vm-VMID-disk-N.qcow2
LVM / LVM-Thin	raw	lvm-thin:vm-VMID-disk-N
ZFS	raw	zfs-pool:vm-VMID-disk-N
Ceph RBD	raw	ceph:vm-VMID-disk-N

On a file-based target (directory, NFS, CIFS, GlusterFS, BTRFS) the converted disk is written straight onto the target storage and adopted as a volume in place, instead of being copied a second time during import. You no longer need to plan for twice the converted size while a migration runs. Block targets (LVM, LVM-Thin, ZFS, Ceph RBD) already streamed into a pre-allocated volume and are unchanged.

Keep pve-qemu-kvm current on target nodes

The single-write path for qcow2 targets relies on QEMU. A data-loss regression in the qcow2 write path shipped briefly in pve-qemu-kvm 11.0.0-1 and 11.0.0-2 and is fixed from 11.0.3 onward. On an affected build the converted disk can end up with a zeroed boot sector, so the guest fails to start with a "No bootable device" message even though the migration reports success. Keep pve-qemu-kvm up to date on your Proxmox target nodes with apt update && apt full-upgrade, and check the installed build with apt-cache policy pve-qemu-kvm.

Troubleshooting

Migration stuck at "Import" stage The qm disk import command can take a long time for large disks. Check the Task Center for the detailed log output.

VM does not boot after migration Verify the boot order is set correctly. For EFI VMs, ensure the OVMF BIOS is selected in the VM hardware settings. Since v1.4.7 the boot disk of a Windows or UEFI guest is placed on sata0 automatically, so the INACCESSIBLE_BOOT_DEVICE stop that BIOS-firmware Windows guests used to hit at first boot no longer needs a manual controller change. See Guest hardware mapping. A guest migrated before v1.4.7 keeps whatever controller it was created with, so move its boot disk to SATA by hand if it still fails to start.

Network not working after migration (interface renamed, no IP) After migration a Linux guest often renames its network interface, for example from ens192 to enp6s18, and comes up without an IP. This is expected behavior, not a ProxCenter bug: systemd derives "predictable" interface names from the PCI address and card model, not from the MAC address. VMware presents a VMXNET3 card, which the guest names ens192. Proxmox has no VMXNET3, so ProxCenter converts the card to VirtIO on a q35 machine; the card lands at a different PCI address and the guest names it enp6s18. The guest's existing configuration still refers to the old name, so nothing binds to the new interface.

ProxCenter preserves the source NIC's MAC address on the migrated VM, so both fixes below are reliable and any DHCP reservation keyed on the MAC keeps working.

Option A, point the config at the new name (simplest for a single VM). Run ip -br link in the guest to find the new name, then update the network configuration:

• Debian / Ubuntu (ifupdown): edit /etc/network/interfaces, replace ens192 with the new name, then systemctl restart networking.
• Netplan: edit /etc/netplan/*.yaml, replace the interface name, then netplan apply.
• RHEL / NetworkManager: rename /etc/sysconfig/network-scripts/ifcfg-ens192 to match the new device and set DEVICE=, or use nmcli con mod.

Option B, keep the old name (good for a fleet or scripted configs). Pin the name to the preserved MAC with a systemd link file. Create /etc/systemd/network/10-net-persist.link:

[Match]
MACAddress=aa:bb:cc:dd:ee:ff

[Link]
Name=ens192

Rebuild the initramfs (Debian / Ubuntu: update-initramfs -u, RHEL: dracut -f) and reboot. The interface comes back as ens192 and the original configuration applies unchanged.

Static IP after migration

A migrated VM keeps its own in-guest network configuration; ProxCenter does not push a static IP into the guest after migration. Set static addressing inside the guest using either option above.

For Windows guests, the direct ESXi and XCP-ng pipelines attach an e1000 card instead of a VirtIO one, because Windows has an inbox driver for it and a raw disk copy carries no VirtIO driver. The offline vCenter, Hyper-V and Nutanix route converts through virt-v2v, which installs the VirtIO drivers inside the guest; make sure the VirtIO driver media is available as described in Prerequisites.

"Target node is not ready for warm migration" The selected node is missing one or more warm-migration components (nbdkit, nbd-client, nbdkit-plugin-vddk, or the Broadcom VDDK), or runs Proxmox VE 8, which cannot carry them. Prepare a Proxmox VE 9 node as described in Warm migration node setup, then reselect the node in the dialog. This requirement applies to warm migration only: offline migration installs its open-source tooling automatically and does not need the VDDK.

Warm migration fails with VixDiskLib_Open ... Unknown error returned by server The target Proxmox node cannot reach the source ESXi host on TCP 902. Warm migration authenticates to vCenter over 443, but the VDDK reads the disk blocks directly from the ESXi host over the NFC protocol on TCP 902. When 902 is blocked, authentication, the node readiness check and target disk allocation all succeed, and the migration fails only at the full-copy step with VixDiskLib_Open naming the ESXi host rather than vCenter. Open TCP 443 and 902 from the Proxmox node to every source ESXi host, as described in Warm migration node setup.

Warm migration fails with "nbd: nbd0 already in use" or a wedged NBD device A previous warm migration of a Linux/LVM guest left an NBD device pinned on the target node: the host auto-activated the guest's LVM volume group on it, so nbd-client -d returns success without freeing it and rmmod nbd reports the module is in use (lsof shows nothing, because the holders are LVM / device-mapper, not open files). Prevent this by setting the LVM global_filter described in step 3 of Warm migration node setup; reboot the node to clear a device that is already wedged.

Warm migration fails with "Snapshot creation timed out after 120s" This was a fixed 120 second deadline on the vSphere snapshot tasks and it is gone since v1.4.7. On a large VM the deadline was reached while vCenter was still consolidating the previous delta, and the failure typically landed minutes after a full copy that had already run for hours. Snapshot tasks are now followed to completion with realistic budgets, see vSphere snapshot waits. If you still see a snapshot budget elapse, the message names the operation, the object and the budget: the vSphere task itself keeps running on the vCenter side, so check its state there before retrying.

A migration is still shown as running after ProxCenter was restarted Migrations run inside the ProxCenter server process, so a restart, an upgrade or a crash used to leave the job row non-terminal and the task bar showing a dead migration as in progress forever. On start-up ProxCenter now fails those jobs with:

Migration interrupted: the ProxCenter server running this job stopped (restart, upgrade or crash). It did not complete and can be retried.

The job ends up in the failed state, which the retry action accepts, so you can relaunch it. A job that belongs to another running instance is only swept once it has been silent for 12 hours, which is what keeps the sweep from killing a live migration on a peer replica in a high availability deployment.

A warm migration failed or was cancelled: is the copied target lost? No. Since v1.4.7 cleanup keeps every target volume that already holds a completed copy pass and logs each volume it deliberately kept, so a full, bootable target survives a failure or a cancellation. Volumes that never received a finished copy are still freed, so a retry does not accumulate multi-terabyte leftovers. Cancelling a job whose target already holds a copy now asks for confirmation first and states plainly that the copied volume stays on the storage and has to be removed by hand if you do not want it, that a copy still in progress is discarded, and that the source VM is never modified.

The Target Storage field is empty and Migrate stays disabled The node did not answer the storage listing in time. The field now says so, with the reason and a Retry link, instead of rendering an empty locked selector. A datacenter that declares many PBS targets needs 20 seconds or more to answer, so raise PVE_SLOW_READ_TIMEOUT_MS above its 30 second default rather than the general Proxmox budget, see Timeouts and gates. If the message names a permission or a backend error instead of a timeout, fix that first: ProxCenter is repeating what Proxmox returned.

A failed migration destroyed a VM that already existed on the target Fixed in v1.4.8, and worth knowing if you hit it on an earlier version. The VMID is reserved before the guest exists, so a failure between the reservation and the create made the cleanup path issue a delete on a VMID this job had never created. In the harmless case Proxmox answered Configuration file does not exist and the job advised running qm destroy on a VMID holding nothing. In the damaging case, a VMID you supplied yourself was already taken, the create failed with "already exists", and the cleanup then purged the pre-existing guest holding that id. Destruction now happens only once Proxmox has accepted the create call for this job, in all three pipelines that create a target VM: the direct-ESXi one, the XCP-ng one and virt-v2v. Typing a VMID that the dialog already reports as taken is refused before the job starts, which is the other half of the protection.

warning

Migration requires SSH access to the target Proxmox node for disk import operations. Make sure the SSH connection is configured in Settings > Connections.

Enterprise Feature

The Migration feature is available in the Enterprise edition.

Permissions

Permission	Description
vm.migrate	Start a migration, read a migration job, cancel it, run the node preflight and the warm-migration node preparation, request the cutover, force the source power off, and choose the root filesystem of a parked conversion. Every migration route requires it
connection.view	Read the target node's storage, node and bridge lists that fill the migrate dialog. Checked on the node, so a scoped role only sees its own perimeter
tasks.view	Follow a migration from the Task Center and open its logs there

The target VM is created on Proxmox with the credentials of the target connection, so no separate ProxCenter permission governs the write itself. What the Proxmox API token needs is described in Prerequisites.