Migrations are a means for many IT teams to reduce costs and regain control. In this article I show how to migrate VMware to Proxmox — with a focus on disk conversion, network mapping and performance tuning. The objective is a reproducible operational path for administrators, system engineers and operators, including verification, security and rollback strategies.
Overview and prerequisites
Before you start, document objectives, downtime budget, storage capacity and required features (e.g. snapshots, thin provisioning, VLAN tagging). Terms: VMDK is the VMware disk format; Proxmox uses KVM/QEMU as the hypervisor (KVM = Kernel Virtual Machine), Proxmox VMs are managed via „qm“. Storage backends such as local-lvm (LVM-Thin) or ZFS have different characteristics that affect the choice of raw vs. qcow2, cache mode and snapshot strategies.
Risks, prerequisites and prechecks
Key risks and checks before starting:
- Drivers: Windows‑VMs require VirtIO drivers for network and SCSI; if these are missing the VM will not boot.
- Data consistency: Databases require quiesce (directed pause) or consistent backups; without verification there is a risk of inconsistent data.
- Network mapping: DVSwitch/portgroup concepts must be mapped to Proxmox bridges/VLAN tags.
- Storage specifics: ZFS, local-lvm, NFS or iSCSI behave differently with respect to snapshots and underprovisioning.
- Monitoring: Deploy monitoring agents, alerting and baselines before the migration.
Migration workflow: analysis to production
A robust approach is divided into inventory, test migration, disk conversion, network mapping, functional tests and production cutover. Each VM needs a documented rollback strategy — this reduces decision pressure during cutover.
Inventory and prioritization
Collect CPU, RAM, disk layout, number of NICs, VLAN memberships, VMware Tools status and guest OS. Prioritize by business relevance and risk: controller servers, databases and domain controllers first in a test environment.
Backup, quiesce and snapshot strategy
Create full backups and validate RESTore procedures. For relational DBs use native backup mechanisms or VSS‑based snapshots (Windows Volume Shadow Copy Service). Linux‑DBs should ideally be protected with fsfreeze or transaction‑safe dumps.
Disk conversion: methods, pros and cons
When converting VMDK to Proxmox there are several established approaches. Choose based on operational requirements, performance expectations and automability.
qm importdisk — pragmatic and Proxmox‑native
qm importdisk imports a VMDK directly into a Proxmox storage volume (e.g. local-lvm or ZFS) and creates the volume with a Proxmox‑compliant name. Advantage: Proxmox metadata are set cleanly and you avoid manual storage operations. Disadvantage: For split VMDKs or special VMware controllers pre‑processing is required.
qemu-img — flexible and controlled
qemu‑img can read and convert almost any disk format (vmdk → raw/qcow2). It is ideal if you need qcow2 for snapshots or raw for direct block devices. However, qemu‑img can result in longer runtimes and higher CPU usage; plan transfer windows accordingly.
Typical pitfalls in disk conversion
- Split VMDKs: In the VMware export disks can be split into multiple files (.vmdk, -s001.vmdk); these must be consolidated in vCenter or transferred completely.
Practical Examples: Conversion and Import
Example: transfer VMDK via SCP and use qm importdisk:
# Auf Quell‑Host: VMDK exportieren/packen
scp /tmp/source.vmdk root@proxmox:/tmp/
# Auf Proxmox: Import in Storage local-lvm für VMID 100
qm importdisk 100 /tmp/source.vmdk local-lvm
# Anschließend VM konfigurieren
qm set 100 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-100-disk-0
Alternatively, use qemu-img to generate a raw image:
qemu-img convert -p -O raw source.vmdk /var/lib/vz/images/100/vm-100-disk-0.raw
# dann qm set mit format raw
qm set 100 --virtio0 /var/lib/vz/images/100/vm-100-disk-0.raw
Network Mapping: VMware vSwitch → Proxmox Bridges
VMware often separates standard vSwitch and Distributed vSwitch (DVSwitch). Portgroups and policies define VLAN tagging and uplink assignment. In Proxmox, Linux-Bridges (vmbrX) are the primary mechanism. Key concepts: trunk (multiple VLANs over one uplink), access port (one VLAN per uplink) and bridge_vlan_aware (a bridge that passes VLAN tags to VMs).
Bridge Configuration and VLAN Tagging
If multiple VLANs run over the same uplink, enable bridge_vlan_aware and tag VM interfaces. Example: VM with VLAN 200 on vmbr0:
# Setzt eine VM-Netzkarte mit VLAN-Tag
qm set 100 --net0 virtio,bridge=vmbr0,tag=200
If your physical interface uses bonding or LACP, check switch configuration and MTU (e.g. Jumbo Frames). For issues, tcpdump, ethtool and inspecting VLAN traffic help.
Performance Tuning: I/O and Network
After migration, I/O or network bottlenecks often become apparent. Here are concrete measures: why they help and when they can fail.
I/O Tuning: Cache, iothreads and virtio-scsi
Important parameters in Proxmox/QEMU are cache mode (e.g. none, writeback), iothreads (separate I/O threads) and the controller used (virtio-scsi vs. ide). Why: cache=none results in Direct I/O and bypasses the host filesystem cache, which in combination with well-configured storage (e.g. ZFS with SLOG) provides consistency and good latency. Downside: CPU load increases and write performance can drop if the storage lacks accelerators.
# Beispiel: VM 100 mit iothreads aktivieren und virtio-scsi
qm set 100 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-100-disk-0,cache=none
qm set 100 --iothread 1
Iothreads are useful for VMs with high parallel I/O load (e.g. databases). They can fail when the host scheduling system is under CPU pressure—then check CPU pinning or limit the number of iothreads.
Network Tuning: multiqueue, offloads and MTU
Virtio-Net offers multiqueue (multiple Rx/Tx queues), which reduces latency at high packet rates. Enable proper drivers on the VM side and set qm options:
# Beispiel: VM-Netzkarte mit 4 Queues
qm set 100 --net0 virtio,model=virtio,bridge=vmbr0,queues=4
Offloads (TSO, GSO, GRO) reduce CPU overhead but can cause problems with faulty switch hardware. Test with ethtool and iperf3; if packet loss or reordering occurs, disable problematic offloads.
# Offloads prüfen / deaktivieren
ettool -k eth0
ethtool -K eth0 tso off gso off gro off
iPerf3 Test (Server auf Proxmox, Client remote):
iperf3 -s
iperf3 -c -P 8 -t 60
Validation, monitoring and SLA control
Perform before/after baselines with fio (I/O) and iperf3 (network) to detect performance regressions. Document P50/P95/P99 latencies and IOPS per VM. Automate metrics via Prometheus/Telegraf and create alerts on deviations.
Troubleshooting: concrete cases and verification sequence
Windows does not boot after VirtIO switch
Cause: missing VirtIO drivers in the guest. Solution: temporarily use an emulated NIC (e1000) and IDE/LSI controller, boot, install the VirtIO drivers locally (VirtIO‑ISO) and then switch back. If offline, mount the VirtIO‑ISO and install drivers via DISM or the GUI.
# Beispiel: VirtIO-Treiber per DISM (Windows-PE/Offline)
Dism /Image:C:mount /Add-Driver /Driver:D:viostor /Recurse
iSCSI hangs after import
Check multipath status, iscsi sessions and CHAP authentication. Common causes are MTU mismatch or ACLs on the SAN.
iscsiadm -m session -P 3
multipath -ll
journalctl -u iscsid
Mass migration: automation and rate control
For dozens of VMs automate inventory, transfer, import and configuration. Key concepts: idempotent scripts, logging, retry mechanisms and rate‑limiting to avoid overloading storage backends. Test on a sample and perform staged cutovers.
# Beispiel: vereinfachtes Rate‑Limited SCP in Bash (Pseudo)
for f in /exports/*.vmdk; do
scp "$f" root@proxmox:/tmp/
sleep 10 # Rate limiting
done
Rollback strategy and runbook
Define clear fallback options: keep the source as an offline fallback until acceptance, test RESTore procedures, plan DNS or gateway failover. Assign responsibilities, time windows and abort criteria (e.g. Performance‑Abweichung > X% oder Dienste nicht verfügbar nach Y Minuten).
Final cutover checklist
- Backup vorhanden und RESTore getestet
- Netzwerk: VLANs, MTU, Routing und Firewall‑Rules geprüft
- Leistung: fio/iperf3‑Baselines dokumentiert
- Sicherheit: CHAP/ACLs und Zugriffsrechte geprüft
- Monitoring: Agenten aktiv, Dashboards angepasst
- Rollback‑Plan dokumentiert und getestet
Conclusion
The goal, migrating VMware to Proxmox, is manageable with structured planning. qm importdisk reduces manual errors, bridge_vlan_aware enables clean VLAN‑mapping, and targeted storage and network tuning secures performance. More important than a specific tool chain is validation: measure, test and a clean runbook with fallback options. This way you retain control and minimize risks during the production cutover.
FAQ
See the FAQ section below for quick answers on OVA vs. qm importdisk, boot issues with VirtIO, qcow2 vs. raw and other practical questions.
Migrating VMware to Proxmox: operational and architectural aspects
Beyond the pure conversion of disks and the mapping of networks, the target architecture decisively determines operational reliability and long‑term costs. Here I outline important architectural and operational decisions, typical risks in cluster operation and concrete verification steps that help you make migrations reproducible and reversible.
Cluster‑Quorum, Netzwerksegregation und Fencing
Proxmox‑Cluster verwenden corosync zur Koordination. Planen Sie mindestens drei Knoten für produktives HA; bei zwei Knoten benötigen Sie ein Quorum‑Tie‑Breaker (z. B. QDevice). Ohne ausreichendes Quorum droht: automatische Service‑Stops, Split‑Brain oder ungewollte Failovers.
# Check quorum status
pvecm status
# View cluster logs
journalctl -u corosync -n 200
Fencing (STONITH) verhindert, dass zwei Knoten gleichzeitig an derselben Storage‑LUN schreiben. Bei shared‑Storage (iSCSI, FC) ist ein funktionierendes Fencing essenziell. Implementieren Sie Out‑of‑Band‑Fencing per IPMI/Redfish oder SAN‑Controller, und testen Sie Fencing‑Szenarien im Labor.
Storage‑Architektur: Alignment, Cache & Konsistenz
Achten Sie auf Block‑Alignment und auf die Kombination von Host‑Cache‑Modi mit Storage‑Funktionen (Dedup, Compression). Beispiel: ZFS‑Compression und qcow2‑Snapshots können sich gegenseitig beeinflussen; bei heavy I/O ist raw auf local‑lvm oft stabiler. Validieren Sie, ob Ihr Storage write‑back Caches nutzt und ob Battery‑Backed‑Units (BBU) vorhanden sind — sonst drohen Datenverlustrisiken bei Stromausfall.
Backup‑Integration und RESTore‑Validierung
Die letzte Sicherheitslinie ist die RESTore‑Prüfung: Automatisieren Sie RESTore‑Runs in einer isolierten Umgebung und prüfen Sie Anwendungskonsistenz (Datenbankintegrität, Dienste starten, Zertifikate gültig). Nutzen Sie Proxmox Backup Server (PBS) oder externe Lösungen, und verifizieren Sie die Kompatibilität der Backups mit Ihren Retentions‑ und RTO‑Zielen.
Monitoring, Alerts und SLI/SLO
Richten Sie Metriken für CPU‑Steal, IOWait, P95/P99‑Latenzen und Netzwerk‑Dropouts ein. Baselines vor der Migration sind Pflicht: dokumentieren Sie P50/P95‑IOPS und Latenzen, damit Abweichungen nach dem Cutover messbar sind. Alerts sollten nicht nur Schwellwerte melden, sondern klar definierte Runbooks verlinken.
Integration ins Betriebsteam: Secrets, API‑Zugriff und Automatisierung
Verwalten Sie SSH‑Keys, Proxmox‑API‑Tokens und Storage‑Credentials zentral und versionsgesichert (Vault, HashiCorp, Ansible Vault). Automatisierte Playbooks müssen idempotent sein, klare Logging‑Ausgaben liefern und Retry/Timeout‑Logiken enthalten, um Transfer‑Spitzen zu dämpfen.
# Example pattern (Ansible): idempotent task structure
- name: Import VMDK into Proxmox
community.general.proxmox:
api_host: pve1.example.local
vmid: 100
state: present
register: result
Abnahmekriterien und Notfall‑Rollback
Definieren Sie klare Abnahmekriterien: erfolgreiche Dienststarts, Messwerte innerhalb akzeptabler Abweichung und erfolgreiche RESTore‑Tests. Halten Sie die Original‑VMs solange im Read‑Only‑Fallback bereit, bis ein Tages‑ oder Wochen‑SLA ohne Vorfälle verifiziert ist. Dokumentieren Sie Verantwortlichkeiten, Zeitfenster und Kommunikationswege im Cutover‑Runbook.
Diese betrieblichen und architektonischen Ergänzungen reduzieren Überraschungen nach dem Wechsel und machen „migrating VMware to Proxmox“ planbar und auditierbar — entscheidend für verlässlichen Produktivbetrieb und für die Integration in bestehende IT‑Prozesse und SLAs.
Für dieses Thema sind auch VMDK‑Konvertierungen wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.