Le migrazioni sono per molti team IT uno strumento per ridurre i costi e riconquistare il controllo. In questo articolo mostro come migrare VMware verso Proxmox — con focus su Disk‑Conversion, Netz‑Mapping e Performance‑Tuning. L’obiettivo è un percorso operativo riproducibile per amministratori, ingegneri di sistema e operatori, comprensivo di strategie di verifica, sicurezza e rollback.
Kurzüberblick und Voraussetzungen
Prima di iniziare, definite obiettivi, budget di downtime, capacità di storage e funzionalità necessarie (es. Snapshots, Thin Provisioning, VLAN‑Tagging). Terminologia: VMDK è il formato disco di VMware; Proxmox utilizza KVM/QEMU come hypervisor (KVM = Kernel Virtual Machine), le Proxmox‑VMs sono gestite tramite „qm“. I Storage‑Backends come local‑lvm (LVM‑Thin) o ZFS hanno caratteristiche diverse che influenzano la scelta di raw vs. qcow2, Cache‑Mode e strategie di Snapshot.
Risiken, Vorbedingungen und Vorchecks
Rischi essenziali e verifiche prima di iniziare:
- Treiber: Windows‑VMs richiedono i driver VirtIO per rete e SCSI; in loro assenza la VM non si avvia.
- Datenkonsistenz: i database richiedono Quiesce (sospensione mirata) o backup coerenti; senza verifica si rischiano dati incoerenti.
- Netzwerk‑Mapping: i concetti DVSwitch‑/Portgroup devono essere mappati su Proxmox‑Bridges e VLAN‑Tags.
- Storage‑Spezifika: ZFS, local‑lvm, NFS o iSCSI si comportano in modo diverso rispetto a Snapshots e Underprovisioning.
- Überwachung: predisporre Monitoring‑Agenten, Alerting e Baselines prima della migrazione.
Migrations‑Workflow: Analyse bis Produktion
Un approccio robusto si articola in Inventarisierung, Testmigration, Disk‑Conversion, Netz‑Mapping, Funktionstests e Produktionsumschaltung. Ogni VM richiede una strategia di Rückfalldocumentata — questo riduce la pressione decisionale durante il Cutover.
Inventarisierung und Priorisierung
Rilevate CPU, RAM, Disk‑Layout, numero di NIC, appartenenze VLAN, VMware‑Tools‑Status e Gast‑OS. Prioritizzate in base alla rilevanza per il business e al rischio: Controller‑Server, Datenbanken e Domain‑Controller prima in un ambiente di test.
Backup, Quiesce und Snapshot‑Strategie
Eseguite backup completi e validate i processi di RESTore. Per i DB relazionali utilizzate i meccanismi di backup nativi o snapshot basati su VSS (Windows Volume Shadow Copy Service). Linux‑DBs dovrebbero idealmente essere protetti con fsfreeze o dump transazionalmente sicuri.
Disk‑Conversion: Methoden, Vor‑ und Nachteile
Nella conversione da VMDK a Proxmox esistono diversi metodi consolidati. Scegliete in base ai requisiti operativi, alle esigenze di pRESTazione e al livello di automazione.
qm importdisk — pragmatisch und Proxmox‑nah
qm importdisk importa una VMDK direttamente in un Proxmox‑Storage‑Volume (es. local‑lvm o ZFS) e crea il volume con un nome conforme a Proxmox. Vantaggio: i Proxmox‑Metadaten vengono impostati correttamente e si evitano operazioni manuali sullo storage. Svantaggio: con Split‑VMDKs o controller VMware speciali è necessaria una preelaborazione.
qemu-img — flexibel und kontrolliert
qemu‑img può leggere e convertire quasi tutti i formati disco (vmdk → raw/qcow2). È ideale quando servono qcow2 per Snapshots o raw per dispositivi a blocchi diretti. qemu‑img può però implicare tempi di esecuzione più lunghi e un maggiore utilizzo della CPU; pianificate di conseguenza le finestre di trasferimento.
Typische Fallen bei Disk‑Conversion
- Split‑VMDKs: nell’export VMware i dischi possono essere suddivisi in più file (.vmdk, -s001.vmdk); questi devono essere consolidati nel vCenter o trasferiti per intero.
- Locked Files: Gli export basati su snapshot possono bloccare i file; eseguite gli export quando gli snapshot della VM sono coerenti.
- Thin Provisioning: I dischi virtuali possono avere una dimensione virtuale maggiore rispetto all’occupazione reale—prestate attenzione alla capacità dello storage di destinazione.
Esempi pratici: conversione e importazione
Esempio: trasferire VMDK via SCP e usare 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
In alternativa usare qemu-img per generare raw:
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
Mappatura rete: VMware vSwitch → Proxmox Bridges
VMware spesso distingue tra Standard‑vSwitch e Distributed vSwitch (DVSwitch). Portgroup e policy definiscono il VLAN‑tagging e l’assegnazione degli uplink. In Proxmox le Linux‑Bridges (vmbrX) costituiscono il meccanismo principale. Concetti importanti: trunk (più VLAN su uno stesso uplink), access port (una VLAN per uplink) e bridge_vlan_aware (bridge che lascia passare i tag VLAN alle VM).
Configurazione delle bridge e VLAN tagging
Se più VLAN passano sullo stesso uplink, attivate bridge_vlan_aware e taggate le interfacce delle VM. Esempio: VM con VLAN 200 su vmbr0:
# Setzt eine VM-Netzkarte mit VLAN-Tag
qm set 100 --net0 virtio,bridge=vmbr0,tag=200
Se l’interfaccia fisica usa bonding o LACP, verificate la configurazione dello switch e l’MTU (es. Jumbo Frames). In caso di problemi sono utili tcpdump, ethtool e la visualizzazione del traffico VLAN.
Ottimizzazione delle prestazioni: I/O e rete
Dopo la migrazione spesso emergono colli di bottiglia a livello I/O o di rete. Qui misure concrete, perché funzionano e quando possono fallire.
Ottimizzazione I/O: cache, iothreads e virtio-scsi
I parametri importanti in Proxmox/QEMU sono il cache‑mode (es. none, writeback), gli iothreads (thread I/O separati) e il controller usato (virtio‑scsi vs. ide). Perché: cache=none abilita Direct I/O e aggira la cache del filesystem dell’host, il che, in combinazione con uno storage ben configurato (es. ZFS con SLOG), garantisce consistenza e basse latenze. Svantaggio: aumenta il carico CPU e la velocità di scrittura può diminuire se lo storage non ha acceleratori.
# 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
Gli iothreads sono utili per VM con elevata concorrenza I/O (es. database). Possono non dare benefici se il sistema di scheduling dell’host è sotto pressione CPU — in quel caso verificate il CPU pinning o limitate il numero di iothreads.
Ottimizzazione rete: multiqueue, offload e MTU
Virtio‑Net supporta multiqueue (più code Rx/Tx), che riduce la latenza con alte velocità di pacchetti. Attivate i driver appropriati lato VM e impostate le opzioni qm:
# Beispiel: VM-Netzkarte mit 4 Queues
qm set 100 --net0 virtio,model=virtio,bridge=vmbr0,queues=4
Gli offload (TSO, GSO, GRO) riducono il carico CPU, ma possono causare problemi con switch difettosi. Testate con ethtool e iperf3; se si manifestano perdita di pacchetti o reordering, disattivate gli offload problematici.
# 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
Validierung, Monitoring und SLA‑Kontrolle
Eseguire baseline prima/dopo con fio (I/O) e iperf3 (rete) per rilevare regressioni delle performance. Documentare latenze P50/P95/P99 e IOPS per VM. Automatizzare le metriche tramite Prometheus/Telegraf e configurare alert in caso di scostamenti.
Troubleshooting: konkrete Fälle und Prüfsequenz
Windows non si avvia dopo il passaggio a VirtIO
Causa: driver VirtIO mancanti nel guest. Soluzione: usare temporaneamente una NIC emulata (e1000) e controller IDE/LSI, avviare, installare localmente i driver VirtIO (VirtIO‑ISO) e poi ripristinare. Se offline, montare la VirtIO‑ISO e installare i driver tramite DISM o tramite interfaccia grafica (GUI).
# Beispiel: VirtIO-Treiber per DISM (Windows-PE/Offline)
Dism /Image:C:mount /Add-Driver /Driver:D:viostor /Recurse
iSCSI si blocca dopo l’import
Verificare multipath status, iscsi sessions e autenticazione CHAP. Cause frequenti sono MTU‑mismatch o ACL sullo SAN.
iscsiadm -m session -P 3
multipath -ll
journalctl -u iscsid
Migrazione di massa: automazione e controllo della velocità
Per decine di VM automatizzare inventario, trasferimento, import e configurazione. Concetti chiave: script idempotenti, logging, meccanismi di retry e rate‑limiting per non sovraccaricare i backend di storage. Testare su un campione e effettuare cutover graduati.
# Beispiel: vereinfachtes Rate‑Limited SCP in Bash (Pseudo)
for f in /exports/*.vmdk; do
scp "$f" root@proxmox:/tmp/
sleep 10 # Rate limiting
done
Strategia di rollback e Runbook
Definire opzioni di fallback chiare: mantenere la sorgente come fallback offline fino all’accettazione, testare le procedure di RESTore, pianificare failover DNS o del gateway. Assegnare responsabilità, finestre temporali e criteri di abort (es. scostamento delle performance > X% o servizi non disponibili dopo Y minuti).
Checklist finale per il cutover
- Backup disponibile e ripristino testato
- Rete: VLAN, MTU, routing e regole del firewall verificate
- PRESTazioni: baseline fio/iperf3 documentate
- Sicurezza: CHAP/ACL e permessi di accesso verificati
- Monitoring: agent attivi, dashboard aggiornati
- Piano di rollback documentato e testato
Conclusione
Lo scopo, migrare VMware a Proxmox, è gestibile con una pianificazione strutturata. qm importdisk riduce gli errori manuali, bridge_vlan_aware consente un mapping VLAN pulito e un tuning mirato di storage e rete garantisce le performance. Più importante di una specifica tool‑chain è la validazione: misurare, testare e disporre di un Runbook chiaro con opzioni di fallback. In questo modo si mantiene il controllo e si minimizzano i rischi durante il cutover in produzione.
FAQ
Vedere la sezione FAQ qui sotto per risposte rapide su OVA vs. qm importdisk, problemi di boot con VirtIO, qcow2 vs. raw e altre domande pratiche.
Migrazione da VMware a Proxmox: aspetti operativi e architetturali
Oltre alla mera conversione dei dischi e al mapping delle reti, l’architettura di destinazione determina in modo significativo la sicurezza operativa e i costi a lungo termine. Di seguito delineo decisioni architetturali e operative importanti, rischi tipici nell’esercizio di cluster e passaggi di verifica concreti che aiutano a rendere le migrazioni riproducibili e reversibili.
Quorum del cluster, segregazione di rete e fencing
I Proxmox‑Cluster utilizzano corosync per la coordinazione. Pianificate almeno tre nodi per un HA in produzione; con due nodi è necessario un Quorum‑Tie‑Breaker (p. es. QDevice). Senza quorum sufficiente si rischiano: arRESTi automatici dei servizi, split‑brain o failover indesiderati.
# Quorum‑Status prüfen
pvecm status
# Cluster‑Logs ansehen
journalctl -u corosync -n 200
Il fencing (STONITH) evita che due nodi scrivano contemporaneamente sulla stessa Storage‑LUN. Con shared‑Storage (iSCSI, FC) un fencing funzionante è essenziale. Implementate out‑of‑band fencing via IPMI/Redfish o controller SAN e testate gli scenari di fencing in laboratorio.
Architettura dello storage: allineamento, cache e consistenza
PRESTate attenzione all’allineamento dei blocchi e alla combinazione tra modalità di host‑cache e funzionalità dello storage (Dedup, Compression). Esempio: ZFS‑Compression e qcow2‑Snapshots possono influenzarsi a vicenda; sotto carichi I/O intensi il formato raw su local‑lvm risulta spesso più stabile. Verificate se lo storage utilizza cache write‑back e se sono presenti Battery‑Backed‑Units (BBU) — altrimenti si rischiano perdite di dati in caso di interruzione di alimentazione.
Integrazione dei backup e validazione del ripristino
L’ultima linea di difesa è la verifica del RESTore: automatizzate run di RESTore in un ambiente isolato e controllate la consistenza applicativa (integrità del database, avvio dei servizi, validità dei certificati). Utilizzate Proxmox Backup Server (PBS) o soluzioni esterne e verificate la compatibilità dei backup con i vostri obiettivi di retention e RTO.
Monitoraggio, alert e SLI/SLO
Configure metriche per CPU‑Steal, IOWait, latenze P95/P99 e cadute di rete. Baseline prima della migrazione sono obbligatorie: documentate P50/P95 IOPS e latenze, in modo che le deviazioni dopo il cutover siano misurabili. Gli alert non dovrebbero limitarsi a segnalare soglie, ma collegare runbook chiaramente definiti.
Integrazione nel team operativo: segreti, accesso API e automazione
Gestite centralmente e versionate SSH‑Keys, Proxmox‑API‑Tokens e credenziali dello storage (Vault, HashiCorp, Ansible Vault). I playbook automatizzati devono essere idempotenti, produrre output di log chiari e includere logiche di retry/timeout per attenuare picchi di trasferimento.
# Beispiel‑Pattern (Ansible): idempotente Task‑Struktur
- name: Importiere VMDK nach Proxmox
community.general.proxmox:
api_host: pve1.example.local
vmid: 100
state: present
register: result
Criteri di accettazione e rollback di emergenza
Definite criteri di accettazione chiari: avvio dei servizi riuscito, valori misurati entro deviazioni accettabili e test di RESTore superati. Mantenete le VM originali in fallback in sola lettura fino a quando uno SLA giornaliero o settimanale senza incidenti non sia verificato. Documentate responsabilità, finestre temporali e canali di comunicazione nel runbook del cutover.
Questi accorgimenti operativi e architetturali riducono le sorprese dopo la migrazione e rendono „migrare da VMware a Proxmox“ pianificabile e verificabile — cruciale per un esercizio produttivo affidabile e per l’integrazione nei processi IT e negli SLA esistenti.
Anche la conversione dei Vmdk è importante per questo tema. L’articolo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.