Dans mes deux premiers articles, je parlais d'une IA qui audite mon infrastructure, puis d'une IA avec qui je construis des applications. Cette fois, le sujet est plus terre à terre, mais c'est l'un des chantiers dont je suis le plus fier : migrer toute la virtualisation d'une infrastructure financière, d'un hyperviseur propriétaire vers Proxmox, en production, sans jamais arrêter la salle de marché.
Voici pourquoi, comment, et surtout les pièges, parce que c'est là que se cache le vrai travail.
Pourquoi toucher a un hyperviseur qui marche ?
C'est la première question qu'on m'a posée. La virtualisation tournait, elle était stable. Pourquoi prendre le risque ? Trois raisons.
La première, le coût. Les licences propriétaires me coûtaient chaque année plusieurs dizaines de milliers de francs. L'abonnement Proxmox, c'est quelques centaines d'euros. Sur la durée, ce n'est plus une ligne de budget, c'est un argument.
La deuxième, l'indépendance. Quand votre couche de virtualisation appartient à un seul éditeur, c'est lui qui décide des prix, du rythme, des fonctionnalités, et du moment où votre version devient fin de support. Dans une petite équipe, cette dépendance est un risque silencieux.
La troisième est la plus importante, et c'est le fil de ce blog : l'open-source, c'est du texte. Une config Proxmox, ce sont des fichiers. Donc versionnables dans Git, lisibles par une IA, auditables, reproductibles. Un hyperviseur propriétaire, c'est une boîte noire avec laquelle ni Git, ni mon agent IA ne peuvent vraiment travailler. En passant à Proxmox, je ne changeais pas juste de logiciel : je rendais mon infrastructure compréhensible par mes outils.
Le decor : deux sites, une poignee de serveurs, une vingtaine de machines
Pour comprendre la suite, il faut le décor.
D'un côté, le data center principal : trois serveurs récents (deux processeurs, beaucoup de RAM chacun) sous hyperviseur propriétaire, qui portaient l'essentiel des machines critiques, dont les contrôleurs de domaine, les firewalls virtualisés, et les serveurs de données de marché.
De l'autre, un second site, avec un vieux cluster Proxmox sur du matériel en fin de vie, qui hébergeait une douzaine de services internes : monitoring, dépôts Git, portails, briques applicatives. L'objectif n'était donc pas seulement de quitter le propriétaire. C'était aussi de consolider les deux mondes sur un cluster Proxmox neuf, et de ne garder sur le second site qu'un nœud minimal comme site de secours. Deux chantiers en un, et toujours la même règle : rien ne s'arrête.
Premiere etape : faire le menage
La meilleure migration, c'est celle qu'on n'a pas à faire.
Avant de toucher à quoi que ce soit, j'ai passé l'inventaire au crible. Sur la vingtaine de machines, plusieurs étaient éteintes depuis des mois, obsolètes, ou remplacées par autre chose : un vieux serveur de gestion, des templates, un connecteur d'annuaire migré ailleurs, des serveurs applicatifs décommissionnés. Chaque machine supprimée avant la migration, c'est une machine de moins à migrer, à tester, à documenter. Le périmètre a fondu avant même la première bascule. C'est l'étape la moins technique et la plus rentable.
La contrainte : la salle de marche ne s'arrete jamais
Pas question de tout éteindre un week-end et de prier. Sur une infra de trading, le big bang est interdit.
La méthode a donc été un roulement. Je consolide les machines sur moins d'hôtes pour en libérer un complètement. Je réinstalle cet hôte en Proxmox. Je crée le cluster. Je migre les machines une par une vers le nouveau monde, puis je libère l'hôte suivant, et je recommence.
La question qui fait peur, c'est la capacité : est-ce qu'un seul hôte tient la charge des autres pendant qu'on les vide ? J'ai fait le calcul avant, pas pendant. Huit machines actives consolidées représentaient environ 80 Go de RAM pour 128 disponibles, et de la marge sur les cœurs. Ça passait. On ne consolide pas à l'aveugle : on consolide quand les chiffres disent que ça tient. À chaque instant, le service tournait en parallèle sur l'ancienne ou la nouvelle plateforme. Le desk n'a rien vu.
Trois facons de faire passer une machine
Faire migrer une VM d'un hyperviseur à un autre n'est pas une opération unique. Selon la machine, j'ai utilisé trois approches.
La conversion. Pour les serveurs Windows classiques, j'éteins la machine, je convertis son disque virtuel au format de Proxmox (qemu-img convert), je recrée une VM en KVM avec contrôleur et carte réseau VirtIO, puis j'installe les pilotes VirtIO au démarrage pour que Windows voie son disque et son réseau. Sans ces pilotes, l'installeur ne voit ni disque ni carte : c'est le piège classique. Pour un serveur de trading critique, l'opération se fait hors des heures de marché, et seulement si son pair en haute disponibilité est sain.
La reconstruction en conteneur. Pour les services Linux, je n'ai pas converti : j'ai reconstruit. Un conteneur LXC léger, l'application réinstallée proprement, les données réimportées. C'est plus de travail que de copier un disque, mais on gagne en densité, on laisse derrière soi des années de cruft accumulé, et on obtient une machine propre, documentée, reproductible.
Le cas du contrôleur de domaine. Celui-là, on ne le convertit jamais. Cloner un Active Directory par copie de disque, c'est risquer un USN rollback : l'annuaire repart sur un état antérieur et corrompt silencieusement la réplication, parfois des semaines plus tard. La bonne méthode est plus longue mais c'est la seule propre : monter un contrôleur neuf, le promouvoir, laisser l'annuaire se répliquer, vérifier qu'il n'y a aucune erreur, transférer les rôles FSMO, puis rétrograder l'ancien et reprendre son adresse. Aucune copie de disque dans toute la chaîne.
Le piege que je n'avais pas vu venir : le stockage partage
Voilà l'erreur qui m'a coûté le plus de temps, et la leçon que je retiens le plus.
Mes deux premiers nœuds Proxmox attaquaient le même volume sur la baie de stockage, en iSCSI multichemin. Sur le papier, c'était du stockage partagé : la migration à chaud entre nœuds devait fonctionner. Sauf que non. Le volume était formaté en LVM thin, et Proxmox refuse de considérer un LVM thin comme réellement partageable : chaque nœud garde sa propre vue des métadonnées, en local. Les deux nœuds voient le même disque physique mais chacun croit en être le seul maître. Dès qu'on tente une migration à chaud, les métadonnées se désynchronisent et l'opération avorte avec une erreur de transaction.
J'ai donc tout rebasculé sur du NFS partagé, avec les disques en qcow2 : là, la migration à chaud fonctionne enfin, pour les VM comme pour les conteneurs. Le LVM iSCSI a été décommissionné une fois la bascule terminée.
Et la vraie cible, à terme, c'est du stockage distribué (Ceph) sur trois nœuds : plusieurs disques NVMe par serveur regroupés en pool répliqué trois fois, sur un réseau dédié à 25 Gbit/s. Plus aucune baie unique comme point de défaillance, et la migration à chaud des conteneurs en prime. C'est l'étape d'après.
Migrer treize services en deux jours
Pour les services du second site, pas de conversion de disque : j'ai utilisé la sauvegarde comme véhicule de migration. Le serveur de sauvegarde Proxmox produit déjà une image de chaque conteneur. La migration devient triviale : sauvegarde sur l'ancien site, copie de l'image vers le nouveau cluster, restauration sur le stockage partagé, et le conteneur repart, à l'identique, ailleurs. En deux jours, treize services y sont passés : monitoring, métriques, logs, SIEM, dépôts Git, exécuteur d'intégration continue, proxy, briques de données de marché.
Un piège m'attendait quand même : un conteneur restauré en mode privilégié à partir d'une sauvegarde non privilégiée se retrouve avec son /etc en permissions trop restrictives. Des services refusent alors de lire leur propre configuration et plantent au démarrage, sans message clair. Le correctif tient en une commande, encore faut-il savoir la chercher.
Les petites miseres (que personne ne documente)
Un plan de migration tient sur une page. Ce qui ne tient pas sur une page, c'est la liste des petites choses qui cassent. Quelques exemples vécus :
- L'agrégat réseau (LACP). Le lien refusait de transmettre le trafic, la table d'adresses du switch restait vide malgré une négociation annoncée correcte. La solution, contre-intuitive : retirer l'agrégat, valider sur un seul lien, le remettre, puis redémarrer l'hôte pour que la négociation se fasse proprement au boot.
- Le double facteur qui bloque le cluster. L'authentification à deux facteurs sur le compte d'administration faisait échouer l'ajout d'un nœud, avec une erreur peu parlante. Il a fallu la désactiver temporairement, joindre le nœud, puis la réactiver.
- Les conteneurs Linux. Le gestionnaire de paquets qui ne résout plus le DNS dans un conteneur privilégié, des services système qui échouent parce qu'ils réclament des espaces de noms indisponibles, une ouverture SSH rallongée de vingt-cinq secondes par un service de session qui tourne dans le vide.
- Les petits gains, aussi. Activer la déduplication mémoire entre machines, ajuster la tendance du système à utiliser le swap : des détails qui, mis bout à bout, font tenir plus de machines sur le même fer.
Tout pointe vers l'ancienne adresse
Migrer une machine change son adresse IP. Et vous découvrez alors combien d'autres systèmes avaient cette adresse écrite en dur quelque part.
Après la bascule, une série d'alertes est passée au rouge. Rien de cassé en réalité : c'était le monitoring qui interrogeait encore les anciennes adresses. La source de données du tableau de bord pointait vers l'ancienne IP du serveur de métriques, donc toutes les alertes tombaient en erreur. Une règle de pare-feu n'autorisait un flux que depuis l'ancienne IP. Les cibles de supervision n'avaient pas suivi le déménagement.
La leçon : une migration n'est pas finie quand la machine redémarre ailleurs. Elle est finie quand tout ce qui la référence a été mis à jour : le réseau, le DNS, le monitoring, les règles de sécurité, les sauvegardes. C'est la moitié invisible du travail.
L'incident, parce qu'il faut etre honnete
Quelques semaines après, un volume de stockage s'est rempli à ras bord. En cascade, une quinzaine de machines sont passées en erreur d'entrée/sortie. Symptôme déroutant : les VM Windows répondaient au ping mais tous leurs ports étaient morts, un zombie réveillé à moitié ; les conteneurs Linux basculaient en lecture seule.
La récupération a suivi un ordre précis, et l'ordre compte : agrandir le volume d'abord, puis relancer les VM, puis redémarrer les conteneurs par lots, puis réparer les permissions abîmées au passage. Vouloir relancer les machines avant d'avoir réglé le stockage, c'est repartir dans le mur.
La leçon, évidente après coup : un volume de stockage doit avoir une marge et un agrandissement automatique, plus une purge automatique des vieux instantanés. Je le savais en théorie. Pas sur ce volume-là. On ne tire jamais ces leçons sur les volumes des autres.
Le bilan
Aujourd'hui, une vingtaine de machines tournent sur le nouveau cluster open-source, réparties entre conteneurs légers et VM. Les licences propriétaires ont disparu du budget, et un nœud reste sur le second site comme secours. Mais le vrai gain n'est pas le coût.
Le vrai gain, c'est que ma couche de virtualisation est devenue du texte : versionnée dans Git, supervisée par une stack open-source que j'ai bâtie à côté, sauvegardée avec des instantanés immuables qui sont ma première ligne de défense contre un ransomware, et surtout compréhensible par mes outils, y compris mon agent IA. Une petite équipe possède désormais sa virtualisation, au lieu de la louer et d'attendre le support d'un éditeur quand quelque chose cloche à 9 h un jour de marché.
C'est le même fil que mes articles précédents. L'open-source et l'automatisation ne sont pas une lubie d'ingénieur. Pour une équipe réduite dans un environnement exigeant, c'est ce qui fait la différence entre subir son infrastructure et la maîtriser.
Et si un éditeur vous explique que sa boîte noire est la seule option sérieuse pour de la production critique : trois serveurs, une salle de marché qui n'a jamais cligné, et un budget de licences divisé par cent disent le contraire.