Did you know that vCenter-based transfers can be 5–10× slower than pulling directly from a host? This gap reshapes how we plan migration and downtime for critical servers.
We introduce the new import wizard that lets teams move a virtual machine from ESXi storage straight through the web UI. The feature arrived with pve-manager 8.1.8 and the pve-esxi-import-tools package—so version checks matter.
From adding ESXi under Datacenter → Storage → Add → ESXi to selecting target storage, CPU, and bridges, the process is guided and traceable. Advanced options let us map disks, change controllers, and align NIC models for smooth post-migration performance.
Practical advice: power down source machines when possible, note network settings, and address TPM‑encrypted disks before you run an import. For slow links, use live‑import sparingly—it’s useful to reduce downtime but can stream data while the VM powers on.
Key Takeaways
- Direct host imports are far faster than vCenter-based transfers—plan accordingly.
- The new tool centralizes storage selection and disk mapping for clearer outcomes.
- Perform readiness checks—versions, storage capacity, and network proximity.
- Use live‑import to cut downtime; choose offline import for reliability on slow links.
- Local teams in Malaysia benefit from lower cost and easier procurement with open solutions.
Why migrate VMware ESXi virtual machines to Proxmox VE today
For Malaysian organisations, converting vmware proxmox workloads to an open stack reduces vendor lock‑in and lowers long‑term costs. We see clear gains in control, predictable total cost of ownership, and local procurement flexibility.
Cost and control. Open licensing under AGPLv3 removes OEM constraints while optional subscriptions provide enterprise support. This mix gives teams budget certainty and support options that match their risk profile.
Flexible storage and governance. A unified GUI, CLI, and API connect clusters to multiple storage backends — NFS/CIFS, ZFS, LVM, and Ceph — letting you align performance and cost to business tiers.
What the new import wizard changes versus older migration methods
The new import wizard centralises selection, per‑disk mapping, NIC choices, and monitoring in one flow. Compared with manual SSH copy and qm importdisk steps, it cuts human error and saves time.
| Aspect | Manual method | New flow | Benefit |
|---|---|---|---|
| Steps | Copy VMDK, convert, attach | Select VM, map disks/NICs, run | Fewer commands, less guesswork |
| Storage options | Dependent on scripts | NFS, ZFS, LVM, Ceph | Match performance to cost |
| Speed | varies via vCenter or host | Direct host connections faster | Lower downtime for servers and data |
| Auditability | Manual logs | Central task monitoring | Clearer documentation and trace |
Pre‑migration checklist: make sure Proxmox version and environment are ready
We start with a short readiness pass to reduce risk and keep downtime predictable. Follow these checks in order so the migration window runs smoothly.
Verify repositories and updates
Point repositories to pve-no-subscription or pvetest so the ESXi option appears in the UI. Ensure the pve-manager is at least 8.1.8 and libpve-storage-perl is 8.1.3 or newer.
Run the package command to install pve-esxi-import-tools if needed, then reboot the proxmox host to make the option visible.
Confirm storage targets and disk formats
Size target storage to match the source footprint plus headroom. Choose formats by policy — qcow2 on file storage for snapshots, block storage for performance.
Map hot datasets to faster tiers and verify free capacity before you proceed.
Network readiness and bandwidth
Check Linux bridges (vmbr), VLAN tagging, and prefer same Layer‑2 between hosts. Aim for 10 GbE links — they shorten transfer windows versus vCenter paths.
Prepare source VMs and security
Power down source vms, uninstall VMware Tools where appropriate, and note static IPs and DNS entries for Windows guests.
Handle MAC changes via DHCP reservations or set the target NIC MAC to match. Disable vTPM‑backed full‑disk encryption and secure keys before migration.
| Check | Action | Why it matters |
|---|---|---|
| Repositories | Use pve-no-subscription/pvetest | Exposes ESXi storage option in UI |
| Version | pve-manager ≥ 8.1.8; reboot host | Pulls required tools and UI support |
| Storage | Size + choose qcow2 or block | Snapshots vs performance SLA |
| Network | vmbr, VLANs, 10 GbE preferred | Faster, more reliable transfers |
Keep backups and a rollback plan in mind. For an installation primer, see our installation guide.
Proxmox ESXi import wizard: step‑by‑step how‑to
Add the remote host as a storage endpoint—this single step lets the UI show all machines ready for transfer.
Follow Datacenter → Storage → Add → ESXi, then enter the host FQDN or IP, username, and password.
You can skip certificate verification if the server uses a self‑signed cert.
Add ESXi storage in the management UI
One‑time credentials let the system enumerate all vms on the source host.
Select the new storage entry to reveal the datastore and the VM list.
If the storage option is missing, verify repository settings, updates, and reboot the proxmox host.
Select target compute, storage, and network
Launch the Import dialog and define VM ID, sockets, cores, and memory.
Set the CPU type to match cluster policy for live mobility and give the machine a clear name.
Pick default storage and the default bridge so networking and disk placement match your VLAN and tiering strategy.
Run the task and monitor progress
Advanced options let us change SCSI controller type and NIC models before starting.
We launch the task, watch live logs, and verify throughput in the task view.
On success, the server appears in inventory ready for boot and validation.
“Watch live logs during transfer — transparent status shortens the change window and reduces surprises.”
Maintain a short validation checklist: boot test, network reachability, and application health.
Use direct host connections for speed; reserve vCenter only when necessary.
| Step | Action | Why it matters | Tip |
|---|---|---|---|
| Add storage | Datacenter → Storage → Add → ESXi | Lists available vms and datastores | Skip cert check for self‑signed if needed |
| Configure compute | Set VM ID, CPU, memory | Ensures cluster mobility and correct resources | Match CPU type to cluster policy |
| Set target | Choose default storage and bridge | Places disks and network in right tier/segment | Align bridge with VLAN plan |
| Monitor | Watch task logs until completion | Confirms throughput and success | Run boot checks before declaring done |
Advanced import options that save time and reduce rework
Fine‑grained options reduce post‑cutover fixes by placing each disk and NIC where it belongs.
In the Advanced tab we pick per‑disk storage targets and can skip legacy devices. This ensures the right storage tier for every workload.
Per‑disk placement, controllers, and skipped devices
We map each disk to performance or capacity storage up front. That avoids later migration of heavy volumes.
Changing controllers to VirtIO SCSI during the import improves IO and lowers latency. We also disable unused devices to keep the guest lean.
Mapping network interfaces and hardware models
For servers with multiple interfaces, we assign each interface to the correct bridge. We pick models—VirtIO for efficiency or vmxnet3 for compatibility—per interface to match application needs.
Attach an ISO to install drivers or tools at first boot
We can mount an ISO as a CD drive during the process. That lets the target VM load drivers and management tools on first boot—saving manual steps.
“Align disk, controller, and NIC choices during migration to cut follow‑up work and reduce risk.”
| Option | What we set | Benefit |
|---|---|---|
| Per‑disk storage | Choose performance or capacity | Right cost/performance for data |
| Controllers | Switch to VirtIO SCSI | Better throughput, lower latency |
| Network models | VirtIO or vmxnet3 per NIC | Balance efficiency and compatibility |
| ISO attach | Install drivers/tools on boot | Faster stabilization and fewer tickets |
Live‑import to minimize downtime: what it is and when to use it
Live‑import powers the target VM once enough disk blocks arrive so services can start while remaining data continues to stream. This reduces visible downtime for users and speeds the cutover process for time‑sensitive workloads.
How live‑import powers on early while data continues to stream
The process copies initial volumes needed to boot, then brings the server online. Background transfers finish the remaining blocks while the guest runs on the target.
Important: the source VM must be powered off during the transfer. Plan a short outage window and notify stakeholders in advance.
Bandwidth cautions and when to avoid live‑import
Bandwidth is the gating factor—prefer 10 GbE or same Layer‑2 networks for predictable throughput. On slow or unstable links, the whole operation can fail and partial data will be discarded, forcing a retry.
- Test live‑import on noncritical VMs to validate performance.
- Confirm target storage and disk throughput so the guest stays responsive.
- Monitor the task closely and have a fallback plan—schedule time for a full offline transfer if needed.
“Use live‑import selectively for services where minutes matter; choose offline transfers when reliability outweighs speed.”
Manual migration path: importing VMware ESXi VMs without the wizard
When the UI path is unavailable, a manual file transfer lets us move VMs reliably using SSH and CLI tools.
Enable SSH on the host (vSphere Client → Host → Configure → Services → SSH → Start). Then locate the VM datastore path so we copy the correct files.
Copy VMDK files and prepare the source
Use scp to transfer both the descriptor .vmdk and the -flat.vmdk. Missing either file breaks conversion.
- scp -v root@<ESXi_IP>:/vmfs/volumes/<datastore>/<vm>/disk.vmdk /var/lib/vz/
- Copy the matching -flat.vmdk as well for integrity.
Convert and attach the disk on the target
Run the qm importdisk command to convert and place the disk on chosen storage:
qm importdisk <VMID> /var/lib/vz/disk.vmdk <target_storage>
The disk shows as “Unused Disk” in the VM. Attach it as SATA or SCSI based on guest drivers. Then set the boot order to the new disk and start the machine.
“Follow the order: copy, convert, attach, then boot — this prevents configuration drift and supports repeatable migration.”
| Action | Why | Tip |
|---|---|---|
| Enable SSH | Allows secure file transfer from source | Start service via Host → Configure → Services |
| Copy both VMDK files | Descriptor + data ensure conversion | Use verbose scp for progress and checksums |
| qm importdisk | Converts disk and stores it on target storage | Pick storage tier to match workload |
| Attach and boot | Sets VM to run from converted disk | Adjust SATA/SCSI and boot order before start |
Guest optimization after import: CPU, disk, and network best practices
After migration, tuning guest settings makes the difference between a quiet success and early trouble tickets. We focus on simple changes that improve I/O, networking, and observability for Malaysian teams.
VirtIO SCSI, IO threads, and discard for thin‑provisioned storage
Switch disks to a single VirtIO SCSI controller and enable IO threads to increase parallelism and reduce latency under load.
Enable discard so thin back ends reclaim freed blocks and lower ongoing storage costs. Validate disk alignment, queue depth, and scheduler for heavy I/O workloads.
VirtIO NICs, bridges (vmbr), and MAC/DHCP strategy
Use VirtIO NICs for efficiency and map each interface to the correct bridge and VLAN to preserve segmentation.
Keep or update DHCP reservations—document the address target nic mapping and any mac address target changes to avoid IP drift.
QEMU guest agent and memory ballooning for better observability
Install the QEMU guest agent and enable memory ballooning to improve shutdowns, IP reporting, and memory telemetry.
These tools help us monitor vms, tune capacity, and reduce tickets for troubleshooting hardware or device naming issues—especially for windows guests where driver staging may be required.
Windows and Linux specifics to keep in mind
Successful migrations hinge on handling device drivers and boot modes for each machine. We focus here on the key steps that cut validation time and reduce rework.
Windows: drivers, IP cleanup, and boot mode
Pre‑stage VirtIO drivers for storage and NICs so the guest finds controllers on first boot. Attach a driver ISO if you cannot preinstall—remove it after stability is confirmed.
Clean hidden NICs in Device Manager to avoid a duplicate IP warning from leftover adapters. Reapply the intended static IP and check DNS entries.
Match boot mode to the OS: use SeaBIOS for legacy and OVMF for UEFI. The correct choice prevents boot path and loader issues that block a virtual machine from starting.
Linux: initramfs and device naming
Ensure VirtIO modules are included in initramfs before cutover. If the target kernel lacks those drivers, rebuild initramfs so the system recognizes the new device on boot.
Block device names may change — sda can become vda. Update fstab and bootloader configs to reflect the new names and avoid a failed boot.
- Verify time sync and integration tools early to stabilise services.
- Test storage mounts, permissions, and SELinux/AppArmor contexts after first boot.
- Capture before/after documentation for audits and future runs.
“Handle OS drivers and boot choices upfront to speed validation and reduce downtime.”
Troubleshooting and performance tips for importing VMware ESXi VMs
Issues during VM moves usually point to a small set of environment or version gaps. We start with quick checks so teams in Malaysia can restore progress and keep maintenance windows tight.
Missing storage option, repositories, and host reboot
If the ESXi storage option is missing, verify repository settings and apply updates. Point to pve-no-subscription or pvetest, confirm pve-manager ≥ 8.1.8 and libpve-storage-perl ≥ 8.1.3, install the required tools, then reboot the proxmox host so the feature registers.
vCenter vs direct host: speed and planning
Prefer direct host transfers for throughput — vCenter paths can be 5–10× slower. For large batches, plan staggered jobs to avoid saturating storage and network links.
Common failures and practical checks
Ensure the source VM is powered off before starting. Certificate errors are frequent with self‑signed certs — use skip verification per policy. Validate network capacity; slow links cause timeouts and failed tasks.
- Select storage by workload: NFS/CIFS with qcow2 for snapshots, block storage for raw performance.
- For clusters, use Ceph and plan placement groups to meet SLAs.
- Use Proxmox Backup Server for deduplicated backups and fast live‑restore.
| Issue | Likely cause | Fix |
|---|---|---|
| Missing ESXi option | Repo or package version | Point repos, run updates, install tools, reboot host |
| Slow transfer | Using vCenter or congested network | Use direct host, increase bandwidth, stagger jobs |
| Task failure | Source powered on / cert or low link | Power off source, skip cert check if allowed, test network |
“Keep a concise runbook: repositories, versions, package presence, and known error messages — it speeds resolution under pressure.”
Conclusion
Start small, validate, then scale — this keeps downtime low and confidence high during migration. We recommend you adopt the new wizard for most vmware proxmox moves because it reduces steps and clarifies device mapping.
Make sure Proxmox is on the right repositories and make sure proxmox version checks pass before you schedule work. Confirm storage capacity, disk placement, and network bandwidth — these basics unlock a smooth migration.
Use live‑import only after testing representative servers. Post‑migration, standardize on VirtIO SCSI, enable IO threads and the QEMU agent to stabilise workloads. We see this path delivering cost control and better operational autonomy for Malaysian environments.
Need help? We provide planning and execution services to help you migrate proxmox, validate outcomes, and optimise long‑term solutions.
FAQ
What are the primary benefits of migrating VMware ESXi virtual machines to Proxmox VE today?
Moving workloads delivers lower licensing costs, greater operational control, and open‑source flexibility. For Malaysian organisations and similar enterprises, it also enables consolidated management, faster innovation cycles, and vendor independence while supporting standard enterprise storage and networking integrations.
How does the new import tool change migration compared to older methods?
The new tool automates VM discovery, per‑disk placement, and network mapping. It reduces manual disk handling and controller rewiring, shortens migration time, and provides progress monitoring and live‑import options that weren’t available in earlier, manual workflows.
What Proxmox versions and packages must we verify before starting?
Confirm pve‑manager is updated to at least 8.1.8 and that the ESXi import utilities package is installed. Ensure repositories are reachable and apply outstanding updates to avoid compatibility gaps during the transfer.
How should we prepare storage targets and free space on the host?
Identify the target storage type—LVM, ZFS, Ceph, NFS—and confirm available capacity for each VM disk. Verify disk formats and thin‑provisioning settings, and plan per‑disk placement to avoid I/O hotspots and unexpected space exhaustion.
What network checks are required before migration?
Validate bridges and VLAN configurations on the target host, confirm Layer‑2 proximity where possible, and test bandwidth and latency. Map source NICs to target bridges and prepare MAC reservations or DHCP rules to reduce post‑migration disruption.
Do source VMs need preparation before export?
Yes—power down or snapshot per the chosen workflow. Remove or update VMware Tools, uninstall vendor‑specific drivers where recommended, and handle vTPM or encrypted disks ahead of transfer to avoid import failures.
How do we add an ESXi storage target in the management interface?
From Datacenter → Storage → Add, choose the ESXi option and supply host credentials plus datastore path. The system will enumerate available virtual machines and expose disks for selection—no manual datastore parsing required when configured correctly.
What steps are involved when selecting VMs and target settings?
Choose the source VMs, set the destination storage for each disk, pick CPU and memory allocations, and assign a default bridge for networking. Review controller types and disk formats before initiating the transfer.
How do we monitor the transfer and verify completion?
Use the task log in the web UI to watch progress and check individual job status. Verify guest boot and run post‑migration checks—network reachability, disk integrity, and guest agent responsiveness—before decommissioning the source VM.
What advanced options reduce rework during migration?
Use per‑disk target selection to balance I/O, skip unused devices, and remap controllers to preferred types. You can also map multiple NICs to specific bridges and select VirtIO or vmxnet3 models to match performance goals.
When should we use an ISO during the transfer?
Attach an ISO to install drivers or tools such as VirtIO during the first boot. This is particularly useful for Windows guests that require additional drivers for storage and network adapters to boot correctly after migration.
What is live‑import and when is it appropriate?
Live‑import powers the VM early while disk streaming continues in the background—minimizing downtime. Use it for tolerant workloads with sufficient network bandwidth and when minimal interruption is critical.
Are there risks or cautions with live‑import?
Yes—live transfers demand high bandwidth and consistent throughput. Slow or unstable links increase migration time and risk data inconsistency; avoid live modes over constrained WANs or when source VMs have heavy disk churn.
How do we migrate without the automated tool?
Enable SSH on the source host, locate datastore paths, and copy VMDK files to the target. Use the command‑line import utilities to convert and register disks (for example, qm importdisk) and attach them as SATA or SCSI to new guest definitions.
What post‑migration optimisations should we apply?
Configure VirtIO SCSI with IO threads and enable discard for thin‑provisioned backends. Switch NICs to VirtIO, assign proper bridges, and use MAC reservations. Install the guest agent and tune memory ballooning to improve performance and observability.
What Windows‑specific tasks are essential after transfer?
Install VirtIO drivers, remove stale IP and DHCP leases, and confirm the correct boot mode—SeaBIOS or OVMF—so the OS boots reliably. Validate device drivers and run activation or licensing checks if required.
What should Linux guests verify after migration?
Rebuild initramfs if new storage drivers are needed, check device naming changes (for example, /dev/vdX vs /dev/sdX), and ensure fstab entries use UUIDs to avoid boot failures caused by altered device paths.
What common causes lead to import failures and how do we address them?
Failures often stem from powered‑on sources, certificate mismatches, insufficient privileges, or slow network links. Power down or snapshot sources, validate credentials and certificates, and retry over faster, stable links.
How does importing via vCenter compare to direct host transfer?
vCenter‑based imports can enumerate many VMs quickly and centralise credentials, but direct host transfers may be faster for single‑host scenarios. Choose the path that fits scale, network layout, and administrative access.
What storage choices scale best for mass migration?
NFS/CIFS is simple to set up; LVM and ZFS offer strong local performance; Ceph provides horizontal scaling across clusters. Balance throughput, latency, and cost—select the backend that meets your performance SLAs for many concurrent imports.
How do we handle MAC addresses and DHCP reservations during migration?
Preserve or assign MAC addresses deliberately to avoid DHCP conflicts. Update DHCP reservations and DNS records before powering guests to ensure consistent networking and minimal downtime during cutover.
Where can we find documentation and command references for these processes?
Consult the official administration guides and the import tool’s command‑line reference for exact commands and flags. Keep the environment docs—kernel versions, storage drivers, and network topology—handy for troubleshooting.
Comments are closed.