Microsoft Fabric et Power BI : bâtir une plateforme Data gouvernée

Une migration VMware vers Proxmox ne se résume jamais à convertir des disques virtuels puis à redémarrer les machines sur un nouvel hyperviseur. Dans une infrastructure de production, le risque se situe surtout autour des VM : réseaux, stockage, dépendances applicatives, sauvegardes, pilotes, méthodes d’administration, supervision et procédures de reprise.

Pour une DSI, le sujet dépasse donc largement le remplacement d’une plateforme. La migration modifie les mécanismes de haute disponibilité, les habitudes d’exploitation et parfois l’architecture elle-même. Une VM qui démarre sur Proxmox n’est pas nécessairement prête à reprendre son rôle en production. Elle doit encore communiquer sur les bons VLAN, retrouver ses performances, être sauvegardée, supervisée et intégrée dans un scénario de reprise cohérent.

L’objectif de cet article est de poser les contrôles qui comptent réellement avant la bascule : inventaire, compatibilité des invités, architecture cible, méthode d’import, tests, retour arrière et conduite du changement. C’est à ce niveau que se joue la différence entre une conversion technique réussie et une migration de production maîtrisée.

Le transfert du fichier VMDK attire naturellement l’attention, car il matérialise la migration. Pourtant, les incidents les plus coûteux surviennent souvent après l’import. Un serveur démarre, mais sa carte réseau a changé. Une réservation DHCP ne correspond plus à son adresse MAC. Une application refuse de fonctionner parce qu’elle identifie un nouveau matériel. Un serveur Windows ne voit pas son disque avec le contrôleur choisi. Une VM protégée par BitLocker réclame une clé de récupération après la disparition de son vTPM.

Ces écarts restent gérables lorsqu’ils sont recensés avant la fenêtre de bascule. Ils deviennent beaucoup plus difficiles à traiter lorsque plusieurs services attendent le même DNS, le même annuaire ou la même base de données. La première vigilance consiste donc à raisonner par chaîne de service et non par liste de VM.

Le bon indicateur n’est pas seulement le nombre de machines importées. Il faut mesurer la capacité à remettre un service complet en fonctionnement, avec ses flux, ses accès d’administration, sa sauvegarde et sa supervision.

L’inventaire doit aller plus loin que les caractéristiques visibles dans vCenter. Pour chaque VM, il faut relever le système invité, le mode BIOS ou UEFI, le contrôleur de disque, le type de carte réseau, les snapshots, les disques indépendants, les règles d’affinité, les réservations de ressources, les périphériques attachés et les fonctions particulières comme le passthrough ou le vTPM.

Cette lecture technique doit être reliée aux dépendances applicatives. Un serveur de fichiers tolère parfois une interruption simple. Un contrôleur de domaine, un serveur DNS, une base transactionnelle ou une appliance réseau imposent un ordre de redémarrage et des vérifications plus strictes. La documentation des flux entrants et sortants permet aussi d’éviter qu’une VM apparaisse fonctionnelle alors qu’un port, un VLAN ou une route manque sur la cible.

Les pages LOGIQE consacrées à la virtualisation VMware et aux environnements virtualisés rappellent que l’hyperviseur s’inscrit dans une architecture plus large. Cet inventaire doit enfin distinguer les VM migrables telles quelles, celles qui demandent une adaptation et celles qu’il vaut mieux reconstruire proprement sur la plateforme cible.

Avant l’export, il faut ramener chaque VM dans un état aussi lisible que possible. Les snapshots anciens doivent être consolidés après contrôle, car ils alourdissent les transferts et compliquent la lecture de l’état réel des disques. Les sauvegardes doivent être vérifiées indépendamment de la migration. Une copie exploitable de la VM source ne remplace pas une sauvegarde cohérente de l’application.

Sur Windows, l’anticipation des pilotes VirtIO évite une partie des échecs de démarrage et des performances dégradées. Le contrôleur de stockage et le modèle de carte réseau choisis sur Proxmox doivent correspondre aux pilotes présents dans l’invité. VMware Tools devra ensuite être retiré au bon moment, puis remplacé par les composants utiles à l’exploitation sous KVM, notamment le QEMU Guest Agent lorsque son usage est pertinent.

Le mode de démarrage mérite un contrôle séparé. Une VM installée en BIOS ne doit pas être transformée implicitement en UEFI pendant l’import. Secure Boot, chiffrement de disque et vTPM demandent une stratégie explicite. La documentation officielle de migration vers Proxmox VE signale notamment que l’état du vTPM VMware ne peut pas être transféré tel quel. Les clés de récupération doivent donc être disponibles avant toute opération sur une VM chiffrée.

Une équipe prépare un pilote sur une VM Windows peu critique. L’import réussit, le système démarre et le test est déclaré concluant. Le week-end de bascule, un serveur applicatif utilisant BitLocker réclame sa clé de récupération, puis une seconde VM démarre sans réseau parce que son ancienne réservation DHCP repose sur l’adresse MAC VMware. Enfin, un applicatif métier considère le nouveau matériel virtuel comme une modification de licence.

Aucun de ces problèmes n’est exceptionnel.

Leur accumulation transforme toutefois une fenêtre de maintenance raisonnable en diagnostic sous pression.

Un pilote utile doit donc représenter les vraies difficultés du parc : système ancien, plusieurs disques, VLAN spécifique, base de données, chiffrement, forte volumétrie ou dépendance à un équipement physique.

Une VM importée n’est validée que lorsque son service, ses flux, sa sauvegarde et sa supervision fonctionnent sur l’architecture cible.

Le réseau constitue l’une des principales sources d’écart entre VMware et Proxmox.

Les port groups, vSwitch distribués, VLAN, trunks, bonds, MTU et règles de sécurité doivent être traduits dans l’architecture cible. Cette traduction ne doit pas commencer pendant la migration. Les bridges Linux ou la couche SDN retenue doivent déjà être testés, y compris pour les réseaux de management, de stockage, de migration et de sauvegarde.

Le stockage demande le même niveau de préparation.

Le choix entre ZFS, LVM-thin, Ceph ou un stockage partagé dépend de la volumétrie, des performances, du nombre de nœuds, du niveau de redondance et des objectifs de reprise. Reproduire mécaniquement le datastore VMware conduit rarement à la meilleure architecture. Il faut mesurer les IOPS, la latence, les pics d’activité et les temps de restauration attendus.

La plateforme Proxmox VE apporte plusieurs briques intégrées, mais la haute disponibilité n’existe réellement que si le cluster, le quorum, le stockage, le réseau et le mécanisme de fencing ont été conçus ensemble.

L’article LOGIQE sur la virtualisation d’infrastructure avec Proxmox complète cette lecture par les enjeux de résilience et d’exploitation.

Proxmox propose un mécanisme d’import intégré depuis ESXi ainsi que des méthodes reposant sur des fichiers OVF, OVA ou VMDK. Le choix dépend du volume à transférer, de la version source, du stockage VMware, des snapshots et de la fenêtre d’arrêt disponible. Une méthode confortable sur quelques VM peut devenir trop lente ou trop fragile à l’échelle d’un parc.

Certains cas imposent une préparation particulière. Les VM présentes sur vSAN, les disques chiffrés, les datastores comportant certains caractères spéciaux ou les chaînes de snapshots peuvent limiter l’import direct ou en dégrader fortement les performances. L’accès via vCenter peut aussi être moins performant qu’une connexion maîtrisée au bon hôte ESXi. Ces contraintes doivent être testées sur l’environnement réel, avec la version de Proxmox retenue.

L’export OVF reste une voie utile lorsqu’un transfert direct ne convient pas. Broadcom documente la syntaxe et les conditions d’utilisation de son OVF Tool pour ESXi et vCenter. Quelle que soit la méthode, la DSI doit chronométrer l’export, la conversion, l’import et les contrôles post-démarrage. C’est ce temps complet qui détermine la fenêtre de coupure, pas la seule vitesse de copie.

Le pilote doit être choisi pour sa représentativité.

Une petite VM Linux autonome confirme seulement que le chemin d’import fonctionne. Elle ne valide ni un Windows ancien, ni une application dépendante d’un dongle, ni une base de données volumineuse, ni les performances du stockage cible.

Un bon lot pilote rassemble plusieurs profils : une VM Windows avec pilotes et services, une VM Linux, un serveur possédant plusieurs disques, une charge sensible à la latence et une application traversant plusieurs VLAN. Les tests couvrent le démarrage, les performances, les flux, la synchronisation horaire, le DNS, les sauvegardes, la supervision et les opérations courantes d’administration.

Il faut également tester un redémarrage complet après l’import. Certaines anomalies apparaissent seulement au second boot, lorsque les services appliquent leur configuration définitive ou que les anciens composants VMware ont été retirés.

Une bascule de production demande un ordre précis, des critères de décision et un responsable identifié pour chaque validation. Avant l’arrêt, les équipes doivent figer les changements, confirmer la dernière sauvegarde exploitable et vérifier les accès d’urgence. Après l’import, chaque service suit une fiche de recette courte : démarrage, réseau, application, données, authentification, supervision et sauvegarde.

Le retour arrière doit disposer de son propre seuil de déclenchement. Sans heure limite, une équipe peut prolonger les corrections jusqu’à rendre le retour sur VMware impossible dans la fenêtre prévue. La source doit rester intacte et isolée tant que la cible n’est pas validée. Il faut aussi éviter qu’une ancienne et une nouvelle VM utilisent simultanément la même identité réseau ou écrivent dans les mêmes données.

La bascule doit enfin s’articuler avec le plan de reprise d’activité. La migration modifie les procédures de restauration, les emplacements de sauvegarde et les gestes d’exploitation. Ces documents doivent être mis à jour avant la clôture du projet.

LOGIQE aborde une migration VMware vers Proxmox comme une transformation d’infrastructure. Le travail commence par l’analyse du parc, des versions, des dépendances applicatives, des contraintes de disponibilité et des performances réellement observées. Cette base permet de définir l’architecture cible, le stockage, les réseaux, le cluster, la sauvegarde et la supervision avant le premier transfert.

La phase de migration repose ensuite sur des lots cohérents, une méthode d’import validée, des recettes techniques et métier et un plan de retour arrière praticable. LOGIQE accompagne aussi l’adaptation des procédures d’exploitation : droits d’administration, mises à jour, capacité, alertes, sauvegardes, restauration et documentation.

Cette articulation entre équipes techniques et métiers évite de déclarer une migration terminée sur la seule base d’un démarrage réussi. Elle permet de vérifier que les services critiques fonctionnent dans leurs conditions réelles et que les équipes savent exploiter la nouvelle plateforme dans la durée.

Le cadrage doit produire des décisions concrètes : quelles VM migrer, reconstruire ou retirer ; quelle architecture retenir ; quelle fenêtre de coupure accepter ; quels tests conditionnent la poursuite du projet. L’expérience d’un intégrateur aide à arbitrer entre la reproduction de l’existant et la correction de ses fragilités.

Après la bascule, l’accompagnement couvre la stabilisation, la mesure des performances et la montée en compétence des administrateurs. La page dédiée aux infrastructures système LOGIQE présente cette approche globale, depuis l’architecture jusqu’à l’exploitation. Proxmox devient alors une plateforme administrée avec des règles claires, plutôt qu’un nouvel outil ajouté au SI.

Le succès ne se mesure pas au nombre de VMDK convertis. Il se mesure lorsque les services ont retrouvé leurs performances, que les sauvegardes sont restaurables, que les alertes remontent et que l’équipe maîtrise les opérations courantes comme les incidents.

Une migration VMware vers Proxmox peut réduire certaines dépendances et redonner de la latitude à la DSI. Elle reste toutefois un projet d’architecture. Plus l’environnement est critique, plus le pilote, la documentation et le retour arrière doivent être traités avec rigueur. La décision de basculer peut alors s’appuyer sur des preuves techniques plutôt que sur une simple comparaison de fonctionnalités ou de licences.

Peut-on migrer directement une VM VMware vers Proxmox ?

Oui. Proxmox propose notamment un import depuis ESXi et accepte des formats comme OVF, OVA ou VMDK. La méthode dépend de la version source, du stockage, des snapshots, du chiffrement et de la fenêtre d’arrêt.

Faut-il arrêter les VM pendant une migration VMware vers Proxmox ?

La bascule finale impose généralement une période d’arrêt pour garantir la cohérence des données. Sa durée doit être mesurée lors du pilote, en incluant l’import et toute la recette applicative.

Quels sont les principaux risques pour une VM Windows ?

Les pilotes de stockage et de réseau, le mode BIOS ou UEFI, BitLocker, le vTPM, les changements d’adresse MAC, les licences liées au matériel et les anciens composants VMware demandent une vérification spécifique.

Les snapshots VMware sont-ils repris dans Proxmox ?

Il ne faut pas bâtir le projet sur leur reprise. Les snapshots anciens ralentissent ou compliquent souvent l’import. Ils doivent être inventoriés, consolidés lorsque c’est possible et couverts par une sauvegarde vérifiée.

Comment réduire le risque lors de la bascule ?

Il faut tester un lot représentatif, documenter les critères de validation, conserver une source VMware intacte, fixer une heure limite de retour arrière et faire valider les services par leurs responsables.

Pourquoi faire accompagner la migration par un intégrateur ?

Un intégrateur relie la conversion des VM à l’architecture cible, au réseau, au stockage, à la sauvegarde, au PRA et aux contraintes métier. Cette vision réduit les angles morts après le redémarrage technique.