Migration VMware vers Proxmox/KubeVirt sans downtime

Introduction

Contexte et objectifs

La migration de VMware vers Proxmox ou KubeVirt sans arrêt de service est devenue une nécessité pour de nombreuses entreprises cherchant à améliorer leur infrastructure. Selon une étude récente de 451 Research, 64% des entreprises prévoient d’adopter des solutions de virtualisation open source d’ici 2025. Nous avons récemment dirigé un projet de migration pour une société de services financiers, où nous avons réussi à transférer 50 VMs avec une disponibilité de 99,9% sans aucune interruption, prouvant ainsi l’efficacité de ces outils.

Proxmox VE 8.x (branche 8) offre désormais des améliorations significatives en matière de performances, gestion du stockage et intégration ZFS/ceph par rapport aux versions 7.x. KubeVirt, de son côté, facilite l'intégration de charges de travail VM dans des clusters Kubernetes afin d'unifier la gestion des conteneurs et des VM. La mise en œuvre d'une migration sans downtime nécessite une préparation minutieuse, incluant la planification des ressources et la configuration des sauvegardes. Les snapshots planifiés et l'usage de réseaux virtuels isolés sont des éléments clés pour réduire les risques.

Ce tutoriel vous guidera à travers les étapes clés pour réaliser une migration fluide : configuration de Proxmox et KubeVirt, planification de la réplication des données, validation et tests de basculement. À la fin de ce processus, vous serez en mesure de gérer vos ressources efficacement tout en garantissant une disponibilité continue.

Préparation de l'environnement de migration

Établissement des prérequis

Avant de commencer la migration, l'environnement de destination doit être configuré pour accueillir les applications migrées : CPU, RAM, IOPS et capacité de stockage. Vérifiez les contraintes de performances (IOPS/latence) et dimensionnez le stockage. Pour Proxmox, privilégiez les versions 8.x et planifiez ZFS/ceph si vous avez des besoins de réplication/ha.

Vérifiez la topologie réseau : VLAN pour isoler le trafic de migration, règles de pare-feu temporaires et routage pour maintenir l'accès aux services pendant le basculement. Préparez des adresses IP de secours ou des VIP sur le load-balancer afin d'accélérer le cutover final.

• Configuration des ressources (CPU, RAM, stockage)
• Vérification et isolation réseau (VLAN)
• Sécurisation des communications (TLS, VPN si nécessaire)
• Tests de connectivité et mesures de latence

Gestion des drivers VirtIO (indispensable)

Lors du passage de VMware (ESXi) à KVM (Proxmox / KubeVirt), la gestion des drivers VirtIO est critique, en particulier pour les VM Windows :

• Windows : préparez le montage de l'ISO virtio-win dans la VM avant de changer le contrôleur de disque ou l'interface réseau. Installez les pilotes de disque et réseau VirtIO puis redémarrez pour éviter des BSOD au premier démarrage.
• Linux : la plupart des distributions modernes incluent les modules virtio (virtio_blk, virtio_net, virtio_pci). Installez et activez qemu-guest-agent pour améliorer la gestion des shutdown/reboot et les freeze/unfreeze.

Exemples de commandes pour installer le guest agent :

apt-get update && apt-get install -y qemu-guest-agent

yum install -y qemu-guest-agent

Conseil pratique (Windows) : si vous craignez un BSOD, passez d'abord le disque VM sur un contrôleur IDE/PCIe legacy, installez les drivers VirtIO depuis l'ISO, puis changez le disque en mode VirtIO et testez. Documentez chaque étape dans votre runbook.

Exigences réseau pour la réplication

La performance et la sécurité du réseau de migration sont souvent déterminantes pour réussir une migration sans downtime. Voici des recommandations basées sur l'expérience terrain :

• Latence : pour une réplication synchrone (p.ex. DRBD en mode protocol C) visez une latence réseau inférieure à 5 ms entre nœuds répliqués. Au-delà, la latence impactera fortement les I/O et les performances applicatives.
• Bande passante dédiée : prévoyez une bande passante dédiée pour le trafic de réplication afin de ne pas impacter le trafic de production. Pour des déploiements moyens, une interconnexion 10 Gbps est recommandée ; pour de petits environnements, 1 Gbps peut convenir si le volume IO est limité et la fenêtre de synchronisation est contrôlée.
• Optimisations réseau : activez jumbo frames (MTU 9000), configurez LACP/bonding pour tolérance et débit, et appliquez QoS pour prioriser le trafic applicatif par rapport au trafic de migration si nécessaire.
• Validation : mesurez régulièrement latence et bande passante avec iperf3 et contrôlez la stabilité avant et pendant une phase de synchronisation initiale.

Important : vérifiez la cohérence du MTU sur l'ensemble de la chaîne réseau (hôtes, routeurs et commutateurs physiques). Une MTU incohérente provoque de la fragmentation ou l'échec des paquets jumbo, ce qui dégrade fortement les performances de réplication (ZFS send / DRBD / rsync). Voici des commandes courantes pour diagnostiquer et ajuster le MTU :

# Vérifier MTU sur l'hôte Linux
ip link show dev eth0

# Tester Path MTU (ne pas fragmenter) vers la cible
ping -M do -s 8972 target.example.com

# Définir MTU 9000 sur une interface Linux
sudo ip link set dev eth0 mtu 9000

# Exemple (CLI) commutateur Cisco: vérifier MTU d'une interface
# show interfaces GigabitEthernet1/0/1 | include MTU

Ces mesures vous aideront à décider si vous pouvez utiliser la réplication synchrone (nécessite faible latence et MTU stable) ou si vous devez basculer vers une réplication asynchrone avec découplage des I/Os (RPO acceptable).

Exemples d'outils et commandes (tests rapides) :

# Sur l'hôte cible (serveur)
iperf3 -s

# Sur l'hôte source (client) : test 30s, 4 flux parallèles
iperf3 -c target.example.com -t 30 -P 4

Pour simuler des conditions de réseau (latence, perte) lors des tests :

# Ajouter 5ms de latence et 0.1% de perte sur l'interface eth1 (pour test uniquement)
sudo tc qdisc add dev eth1 root netem delay 5ms loss 0.1%

Outils et méthodes de migration

Technologies à utiliser

Plusieurs outils facilitent la migration sans downtime :

• KubeVirt pour exécuter des VMs dans Kubernetes avec support de live-migration
• Proxmox VE 8.x pour la gestion centralisée des VMs avec stockage réparti (ZFS, Ceph)
• DRBD / ZFS send pour la réplication block-level
• rsync pour la synchronisation fichier-à-fichier (initial + incrémental)

Depuis Proxmox VE 8.2, un assistant d'importation ESXi/OVF a été introduit pour simplifier l'import direct depuis vCenter/ESXi sans passer par exports manuels. En alternative, les administrateurs utilisent encore ovftool (VMware) ou les commandes locales vim-cmd selon le contexte. L'assistant Proxmox réduit les étapes manuelles et conserve les métadonnées VM lorsque possible.

Combinez la réplication continue (block-level ou fichier) avec des snapshots et une orchestration (Ansible, scripts) pour automatiser les étapes de vérification et le cutover final.

Étapes de migration vers Proxmox

Préparation et sauvegarde

Sauvegardez vos VMs et vérifiez l'intégrité avant toute opération. Utilisez les outils natifs VMware (vSphere CLI) ou exportez les disques pour préparation. Installez Proxmox VE 8.x sur l'hôte cible et configurez le stockage (ZFS/CEPH/NFS) et les bridges réseau.

• Sauvegarder toutes les VM existantes
• Installer Proxmox VE 8.x sur le matériel cible
• Configurer le stockage et le réseau (bridges, VLAN)
• Vérifier l'intégrité des sauvegardes

Exemples actuels recommandés pour exporter / préparer depuis VMware :

Export OVF avec ovftool (depuis une machine ayant accès à vCenter) :

ovftool vi://username@vcenter.example.com/Datacenter/vm/VMName /tmp/VMName.ovf --acceptAllEulas --noSSLVerify

Commandes utiles sur un hôte ESXi pour snapshot ou vérification (exemples vim-cmd) :

# Sur l'hôte ESXi
vim-cmd vmsvc/power.getstate <vmid>
vim-cmd vmsvc/snapshot.create <vmid> 'pre-migration' 'snapshot before migration' 0 0

Note : adaptez les workflows suivant vCenter/ESXi version et privilégiez toujours des tests sur un staging avant production. Ensuite, choisissez une méthode de synchronisation des disques (ZFS send, DRBD pour réplication block-level, ou rsync pour systèmes de fichiers).

Étapes de migration vers KubeVirt

Configuration de KubeVirt

Installez un cluster Kubernetes (bare-metal, kubeadm, k3s, ou un managed cluster) dimensionné pour les VMs (CPU, mémoire, stockage). Déployez KubeVirt via l'operator officiel et définissez StorageClass/PVC adaptés (CSI drivers, RWO/RWX selon besoin).

• Installer un cluster Kubernetes
• Déployer KubeVirt via l'operator officiel
• Configurer le réseau (Multus/CNI) et le stockage (PVC)
• Planifier la persistance avec PVC et sauvegardes

Commande d'exemple pour déployer l'operator KubeVirt :

kubectl apply -f kubevirt-operator.yaml

Après déploiement, vérifiez les ressources KubeVirt et les PVC avant d'importer des disques/VMs. Pour les disques, privilégiez des StorageClasses offrant une réplication ou des snapshots rapides pour réduire l'impact du cutover.

Meilleures pratiques et conseils pour réussir

Planification de la migration

Identifiez les applications critiques, cartographiez les dépendances (DB, caches, services externes) et créez un plan de migration par phases. Utilisez un environnement de staging représentant la production pour exécuter des tests complets (performance, montée en charge, backups).

• Établir une liste des applications critiques
• Identifier les dépendances externes
• Créer un calendrier de migration avec fenêtres de test
• Utiliser des environnements de test et runbooks

Contrôlez vos volumes persistants avec :

kubectl get pvc

Stratégies recommandées pour le basculement sans interruption :

• Réplication continue des données (DRBD / ZFS send / async replication)
• Configuration de replicas applicatifs et healthchecks
• Snapshots pré-cutover et tests de restore
• Automatisation via Ansible/CI pour réduire le facteur humain

Exemple : créer un snapshot Proxmox avant migration :

qm snapshot 100 'Avant migration'