Les migrations sont pour de nombreuses équipes informatiques un moyen de réduire les coûts et de reprendre le contrôle. Dans cet article, je montre comment migrer VMware vers Proxmox — en mettant l’accent sur la conversion des disques, le mappage réseau et l’optimisation des performances. L’objectif est de fournir une procédure d’exploitation reproductible pour les administrateurs, les system engineers et les opérateurs, incluant des stratégies de vérification, de sécurité et de retour en arrière.
Kurzüberblick und Voraussetzungen
Avant de commencer, définissez les objectifs, le budget de downtime, la capacité de stockage et les fonctionnalités requises (par ex. instantanés, Thin Provisioning, marquage VLAN). Définitions : VMDK est le format de disque VMware ; Proxmox utilise KVM/QEMU comme hyperviseur (KVM = Kernel Virtual Machine), les VM Proxmox sont administrées via „qm“. Les backends de stockage tels que local‑lvm (LVM‑Thin) ou ZFS ont des propriétés différentes qui influencent le choix entre raw et qcow2, le mode de cache et les stratégies d’instantanés.
Risiken, Vorbedingungen und Vorchecks
Risques majeurs et vérifications avant démarrage :
- Treiber: Windows‑VMs nécessitent des pilotes VirtIO pour le réseau et le SCSI ; sans eux, la VM ne démarre pas.
- Datenkonsistenz: Les bases de données exigent un quiesce (mise en pause dirigée) ou des sauvegardes cohérentes ; sans vérification, des incohérences de données sont possibles.
- Netzwerk‑Mapping: Les concepts DVSwitch / Portgroup doivent être cartographiés vers des bridges Proxmox et des tags VLAN.
- Storage‑Spezifika: ZFS, local‑lvm, NFS ou iSCSI se comportent différemment en matière d’instantanés et de sous‑provisionnement.
- Überwachung: Déployer les agents de monitoring, l’alerte et des baselines avant la migration.
Migrations‑Workflow: Analyse bis Produktion
Une approche robuste se compose d’une inventaire, d’une migration test, de la conversion des disques, du mappage réseau, des tests fonctionnels et de la bascule en production. Chaque VM doit disposer d’une stratégie de retour documentée — cela réduit la pression décisionnelle lors du cutover.
Inventarisierung und Priorisierung
Recensez CPU, RAM, disposition des disques, nombre de NICs, appartenance VLAN, état des VMware‑Tools et système d’exploitation invité. Priorisez selon la criticité métier et le risque : serveurs de contrôle, bases de données et contrôleurs de domaine en priorité dans un environnement de test.
Backup, Quiesce und Snapshot‑Strategie
Réalisez des sauvegardes complètes et validez les processus de RESTauration. Pour les bases de données relationnelles, utilisez les mécanismes de sauvegarde natifs ou des instantanés basés sur VSS (Windows Volume Shadow Copy Service). Les Linux‑DBs devraient idéalement être sauvegardées avec fsfreeze ou par des dumps garantissant la consistance transactionnelle.
Disk‑Conversion: Methoden, Vor‑ und Nachteile
Pour convertir des VMDK vers Proxmox, plusieurs méthodes établies existent. Choisissez en fonction des exigences opérationnelles, des attentes de performance et du niveau d’automatisation souhaité.
qm importdisk — pragmatisch und Proxmox‑nah
qm importdisk importe une VMDK directement dans un volume de stockage Proxmox (p. ex. local‑lvm ou ZFS) et crée le volume avec un nom conforme à Proxmox. Avantage : les métadonnées Proxmox sont correctement établies et vous évitez des opérations manuelles sur le stockage. Inconvénient : pour des VMDK segmentés (split‑VMDKs) ou des contrôleurs VMware spécifiques, un pré‑traitement est nécessaire.
qemu-img — flexibel und kontrolliert
qemu‑img peut lire et convertir presque tous les formats de disque (vmdk → raw/qcow2). Il est adapté si vous souhaitez qcow2 pour les instantanés ou raw pour des périphériques bloc directs. qemu‑img peut toutefois nécessiter des temps d’exécution plus longs et une charge CPU plus élevée ; planifiez des fenêtres de transfert en conséquence.
Typische Fallen bei Disk‑Conversion
- Split‑VMDKs : lors de l’export VMware, les disques peuvent être répartis en plusieurs fichiers (.vmdk, -s001.vmdk) ; ceux‑ci doivent être consolidés dans vCenter ou transférés dans leur intégralité.
- Fichiers verrouillés : les exportations basées sur des snapshots peuvent verrouiller des fichiers ; effectuez les exportations lorsque les snapshots de la VM sont cohérents.
- Thin provisioning : les disques virtuels peuvent avoir une taille virtuelle supérieure à l’occupation réelle — veillez à la capacité du stockage cible.
Exemples pratiques : conversion et import
Exemple : transférer un VMDK via SCP et utiliser 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
Alternativ qemu‑img nutzen, um raw zu erzeugen:
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
Cartographie réseau : VMware vSwitch → Proxmox Bridges
VMware fait souvent la distinction entre vSwitch standard et Distributed vSwitch (DVSwitch). Les portgroups et les policies définissent le marquage VLAN et l’attribution des uplinks. Dans Proxmox, les Linux‑bridges (vmbrX) constituent le mécanisme principal. Concepts clés : trunk (plusieurs VLANs sur un même uplink), access port (un VLAN par uplink) et bridge_vlan_aware (bridge qui laisse passer les tags VLAN vers les VM).
Configuration des bridges et marquage VLAN
Si plusieurs VLANs transitent par le même uplink, activez bridge_vlan_aware et taguez les interfaces VM. Exemple : VM avec le VLAN 200 sur vmbr0 :
# Setzt eine VM-Netzkarte mit VLAN-Tag
qm set 100 --net0 virtio,bridge=vmbr0,tag=200
Si votre interface physique utilise du bonding ou LACP, vérifiez la configuration du switch et le MTU (par ex. Jumbo Frames). En cas de problèmes, tcpdump, ethtool et la surveillance du trafic VLAN sont utiles.
Tuning des performances : I/O et réseau
Après migration, des goulots d’étranglement I/O ou réseau apparaissent souvent. Ci‑dessous des mesures concrètes, pourquoi elles aident et quand elles peuvent échouer.
Tuning I/O : cache, iothreads et virtio-scsi
Les paramètres importants dans Proxmox/QEMU sont le mode de cache (p. ex. none, writeback), les iothreads (threads I/O séparés) et le contrôleur utilisé (virtio‑scsi vs. ide). Pourquoi : cache=none entraîne du Direct I/O et contourne le cache système de l’hôte, ce qui, en combinaison avec un stockage bien configuré (p. ex. ZFS avec SLOG), apporte cohérence et faibles latences. Inconvénient : la charge CPU augmente et les performances d’écriture peuvent chuter si le stockage ne dispose pas d’accélérateurs.
# 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
Les iothreads sont pertinents pour des VM à forte charge I/O parallèle (p. ex. bases de données). Ils peuvent échouer si le scheduler de l’hôte est sous pression CPU — dans ce cas vérifiez le CPU‑pinning ou limitez le nombre d’iothreads.
Tuning réseau : multiqueue, offloads et MTU
Virtio‑Net offre le multiqueue (plusieurs files Rx/Tx), ce qui réduit la latence en cas de fort débit de paquets. Activez les pilotes adéquats côté VM et appliquez les options qm :
# Beispiel: VM-Netzkarte mit 4 Queues
qm set 100 --net0 virtio,model=virtio,bridge=vmbr0,queues=4
Les offloads (TSO, GSO, GRO) réduisent la charge CPU, mais peuvent provoquer des problèmes en cas de matériel de commutation défaillant. Testez avec ethtool et iperf3 ; si des pertes de paquets ou du réordonnancement apparaissent, désactivez les offloads problématiques.
# 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 et contrôle des SLA
Effectuez des mesures de référence avant/après avec fio (I/O) et iperf3 (réseau) pour détecter les régressions de performance. Documentez les latences P50/P95/P99 et les IOPS par VM. Automatisez la collecte des métriques via Prometheus/Telegraf et configurez des alertes en cas d’écarts.
Dépannage : cas concrets et séquence de vérification
Windows ne démarre pas après le passage à VirtIO
Cause : pilotes VirtIO manquants dans le guest. Solution : utiliser temporairement une NIC émulée (e1000) et un contrôleur IDE/LSI, démarrer, installer localement les pilotes VirtIO (VirtIO‑ISO) puis revenir en configuration VirtIO. Si la VM est hors ligne, montez l’ISO VirtIO et installez les pilotes via DISM ou par l’interface graphique.
# Beispiel: VirtIO-Treiber per DISM (Windows-PE/Offline)
Dism /Image:C:mount /Add-Driver /Driver:D:viostor /Recurse
iSCSI se bloque après l’import
Vérifiez le statut multipath, les sessions iscsi et l’authentification CHAP. Causes fréquentes : discordance MTU ou ACLs sur le SAN.
iscsiadm -m session -P 3
multipath -ll
journalctl -u iscsid
Migration de masse : automatisation et contrôle du débit
Pour des dizaines de VM, automatisez l’inventaire, le transfert, l’import et la configuration. Concepts importants : scripts idempotents, journalisation, mécanismes de retry et limitation de débit (rate‑limiting) pour ne pas surcharger les backends de stockage. Testez sur un échantillon et effectuez des basculements échelonnés.
# Beispiel: vereinfachtes Rate‑Limited SCP in Bash (Pseudo)
for f in /exports/*.vmdk; do
scp "$f" root@proxmox:/tmp/
sleep 10 # Rate limiting
done
Stratégie de rollback et runbook
Définissez des options de retour claires : maintenir la source comme fallback hors ligne jusqu’à l’acceptation, tester les procédures de RESTauration, planifier le failover DNS ou de passerelle. Définissez responsabilités, fenêtres temporelles et critères d’abandon (p. ex. déviation de performance > X% ou services indisponibles après Y minutes).
Checklist finale pour le cutover
- Sauvegarde disponible et RESTauration testée
- Réseau : VLANs, MTU, routage et règles de pare‑feu vérifiés
- Performances : mesures de référence fio/iperf3 documentées
- Sécurité : CHAP/ACLs et droits d’accès vérifiés
- Monitoring : agents actifs, tableaux de bord ajustés
- Plan de rollback documenté et testé
Conclusion
L’objectif, migrer de VMware vers Proxmox, est maîtrisable avec une planification structurée. qm importdisk réduit les erreurs manuelles, bridge_vlan_aware permet un mapping VLAN propre, et un tuning ciblé du stockage et du réseau garantit la performance. Plus important qu’une chaîne d’outils particulière est la validation : mesurer, tester et disposer d’un runbook propre avec options de retour. Ainsi vous gardez le contrôle et minimisez les risques lors du basculement en production.
FAQ
Consultez la section FAQ ci‑dessous pour des réponses rapides sur OVA vs. qm importdisk, problèmes de démarrage avec VirtIO, qcow2 vs raw et autres questions pratiques.
Migrer de VMware vers Proxmox : aspects opérationnels et d’architecture
Outre la simple conversion des disques et le mapping des réseaux, l’architecture cible détermine de manière significative la sécurité opérationnelle et les coûts à long terme. Ici, je décris les décisions clés d’architecture et d’exploitation, les risques typiques en exploitation de cluster et les étapes de vérification concrètes qui vous aident à rendre les migrations reproductibles et réversibles.
Quorum de cluster, ségrégation réseau et fencing
Les clusters Proxmox utilisent corosync pour la coordination. Prévoyez au moins trois nœuds pour un HA en production ; avec deux nœuds, vous aurez besoin d’un Quorum‑Tie‑Breaker (p. ex. QDevice). Sans quorum suffisant, vous vous exposez à des arrêts automatiques de services, au split‑brain ou à des basculements indésirables.
# Quorum‑Status prüfen
pvecm status
# Cluster‑Logs ansehen
journalctl -u corosync -n 200
Le fencing (STONITH) empêche que deux nœuds n’écrivent simultanément sur la même Storage‑LUN. Pour du shared‑Storage (iSCSI, FC), un fencing opérationnel est essentiel. Implémentez un Out‑of‑Band‑Fencing via IPMI/Redfish ou le contrôleur SAN, et testez les scénarios de fencing en laboratoire.
Architecture de stockage : alignement, cache & cohérence
Veillez à l’alignement des blocs et à la combinaison des modes de cache hôte avec les fonctions du stockage (Dedup, Compression). Exemple : ZFS‑Compression et les qcow2‑Snapshots peuvent s’influencer mutuellement ; en cas d’I/O intensif, le format raw sur local‑lvm est souvent plus stable. Vérifiez si votre storage utilise des write‑back Caches et si des Battery‑Backed‑Units (BBU) sont présentes — sinon, des risques de perte de données existent en cas de coupure électrique.
Intégration des sauvegardes et validation des RESTores
La dernière ligne de défense est la vérification du RESTore : automatisez des runs de RESTore dans un environnement isolé et contrôlez la cohérence applicative (intégrité des bases de données, démarrage des services, validité des certificats). Utilisez Proxmox Backup Server (PBS) ou des solutions externes, et vérifiez la compatibilité des backups avec vos objectifs de rétention et de RTO.
Supervision, alerting et SLI/SLO
Collectez des métriques pour CPU‑Steal, IOWait, latences P95/P99 et réseau‑dropouts. Des baselines avant la migration sont impératives : documentez P50/P95‑IOPS et les latences, afin que les écarts après le cutover soient mesurables. Les alerts ne doivent pas se limiter à signaler des seuils, elles doivent renvoyer vers des runbooks clairement définis.
Intégration dans l’équipe d’exploitation : secrets, accès API et automatisation
Gérez centralement et avec versioning les SSH‑Keys, Proxmox‑API‑Tokens et les Storage‑Credentials (Vault, HashiCorp, Ansible Vault). Les playbooks automatisés doivent être idempotents, produire des sorties de logging claires et inclure des logiques de retry/timeout pour lisser les pics de transfert.
# 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
Critères d’acceptation et rollback d’urgence
Définissez des critères d’acceptation clairs : démarrages de services réussis, mesures dans des écarts acceptables et tests de RESTore concluants. Maintenez les Original‑VMs en Read‑Only‑Fallback jusqu’à ce qu’un SLA journalier ou hebdomadaire sans incident soit vérifié. Documentez les responsabilités, les fenêtres temporelles et les canaux de communication dans le Cutover‑Runbook.
Ces compléments opérationnels et architecturaux réduisent les surprises après la migration et rendent « VMware nach Proxmox migrieren » planifiable et auditable — essentiel pour une exploitation productive fiable et pour l’intégration aux processus IT et aux SLAs existants.
Pour ce sujet, la conversion de Vmdk est également importante. L’article replace ces aspects de façon compréhensible et montre ce qui compte au quotidien.