01Adresses matérielles : conserver ou renouveler
Proxmox VE attribue par défaut une nouvelle adresse MAC à chaque carte. C'est propre, et cela casse quatre choses.
| Ce qui s'accroche à la MAC | Conséquence | Décision |
|---|---|---|
| Réservation DHCP | La machine change d'adresse IP | Conserver, ou mettre à jour le bail |
| Licence applicative | Le logiciel se désactive | Conserver, sans hésiter |
| Filtrage par MAC sur le réseau | Trafic bloqué | Conserver, ou mettre à jour la règle |
| Journalisation et corrélation | Historique rompu | Renouveler, et documenter |
Notre pratique : conserver l'adresse MAC d'origine par défaut, sauf raison contraire explicite. Cela réduit le nombre de variables le jour de la bascule, et une variable de moins un samedi soir vaut mieux qu'une convention de nommage élégante.
Conserver l'adresse MAC impose que la machine source ne soit jamais rallumée sur le réseau. Deux machines avec la même adresse sur le même VLAN produisent une panne intermittente que l'on met des heures à comprendre. Retirez la carte réseau de la machine VMware, ou décochez sa connexion au démarrage, avant même de commencer l'import.
02DNS, TTL et dépendances externes
Si la machine conserve son adresse IP, le DNS n'a rien à faire. Si elle en change, la durée de vie des enregistrements devient le facteur limitant de la bascule.
- Abaisser les TTL 48 heures avant, à 300 secondes, sur tous les enregistrements concernés. Un TTL de 24 heures découvert le jour J transforme une bascule de vingt minutes en une journée d'incohérences.
- Recenser les dépendances externes : règles de pare-feu périmétrique, listes blanches d'adresses chez des partenaires, certificats liés à un nom, tunnels VPN site à site, enregistrements SPF si la machine émet du courrier.
- Remonter les TTL une fois la recette prononcée, pas avant.
03Le déroulé minuté de la fenêtre
Le document tient sur une page par lot. Chaque ligne porte une heure prévue, une action, un responsable et un critère de réussite vérifiable. Voici le squelette que nous réutilisons.
| Horaire | Action | Critère de réussite |
|---|---|---|
| J-2 | TTL DNS abaissés, gel des changements sur le lot | Confirmé par l'équipe réseau |
| J-1 | Sauvegarde complète de la source, hors instantané | Sauvegarde vérifiée, pas seulement terminée |
| H-30 | Point de départ, équipe au complet, accès vérifiés | Tous les intervenants joignables |
| H+0 | Arrêt applicatif propre, puis arrêt du système | Services arrêtés dans l'ordre documenté |
| H+10 | Carte réseau de la source déconnectée définitivement | Aucune réponse au ping sur l'ancienne machine |
| H+15 | Lancement de l'import | Progression visible, débit conforme à l'estimation |
| H+X | Réglages post-import appliqués par script | Trace de sortie sans erreur |
| H+X | Premier démarrage, accès console ouvert | Système démarré, adresse IP correcte |
| H+X | Agent invité installé, services applicatifs démarrés | Recette technique du chapitre 05 |
| H+X | Recette fonctionnelle par le propriétaire du service | Validation nominative écrite |
| H+X | Sauvegarde PBS immédiate de la machine migrée | Première sauvegarde réussie |
| Fin | Communication de clôture | Message envoyé, incidents notés |
Fixez à l'avance l'heure au-delà de laquelle, si la machine n'est pas en service, on applique le plan de repli. Cette heure se décide à froid, quelques jours avant, jamais à deux heures du matin par une équipe qui a envie d'y arriver. C'est la ligne la plus importante du document.
04Ordre d'allumage et dépendances
Un lot ne se rallume pas dans l'ordre où il a été importé, mais dans l'ordre des dépendances. L'ordre type, à adapter au parc.
- Services d'infrastructure : annuaire, DNS interne, DHCP, temps.
- Bases de données et stockage applicatif.
- Serveurs applicatifs et files de messages.
- Serveurs frontaux, répartiteurs de charge, mandataires inverses.
- Postes de rebond et outils d'administration.
# ordre de demarrage et delai avant la machine suivante qm set 110 --onboot 1 --startup order=1,up=60 # annuaire qm set 120 --onboot 1 --startup order=2,up=90 # base de donnees qm set 130 --onboot 1 --startup order=3,up=30 # serveur applicatif qm set 140 --onboot 1 --startup order=4 # frontal
Ce réglage ne sert pas qu'au jour J : il détermine aussi le comportement du cluster après une coupure électrique générale. C'est le bon moment pour le poser proprement, pendant que les dépendances sont fraîches dans les esprits.
05Le plan de repli
Le repli d'une migration est le plus simple qui soit, à condition d'avoir respecté une règle : ne rien détruire côté VMware. La machine source est intacte, éteinte, sa carte réseau déconnectée.
- Éteindre la machine migrée côté Proxmox VE.
- Reconnecter la carte réseau de la machine source.
- Rallumer la source, vérifier le service.
- Consigner ce qui a bloqué, tant que le souvenir est précis.
Le repli prend une dizaine de minutes. Sa seule difficulté est de conserver la cohérence des données : si la machine migrée a produit des écritures utiles avant l'échec, il faut les reprendre à la main. C'est précisément pourquoi la recette fonctionnelle intervient avant de rouvrir le service aux utilisateurs.
Une équipe qui n'a jamais replié est une équipe qui pousse toujours jusqu'au bout, y compris quand il aurait mieux valu s'arrêter. Nous considérons un repli propre comme un bon résultat de fenêtre : le service est rendu, l'incident est compris, et la fenêtre suivante partira avec une cause identifiée.
06Communiquer pendant la fenêtre
- Un canal unique pour la fenêtre, connu de tous, où passe l'ensemble des échanges.
- Un point d'étape à intervalle régulier, même sans nouveauté. Le silence inquiète plus que les mauvaises nouvelles.
- Une personne qui décide et une seule, désignée avant le début. Le repli se décide, il ne se négocie pas.
- Un message de clôture précisant ce qui est en service, ce qui reste à surveiller, et à qui s'adresser lundi matin.
À la fin de la fenêtre, les machines tournent. Cela ne veut pas encore dire que la migration est réussie : il reste à le prouver, à le mesurer, et à décider quand on éteint vSphere. C'est l'objet du dernier chapitre.
Une migration VMware a cadrer, a executer ou a securiser
Nous accompagnons les sorties de VMware vers Proxmox VE, du cadrage et de l'audit de l'existant jusqu'a la recette et a la formation des equipes. Nous intervenons aussi en renfort ponctuel sur les lots les plus sensibles d'une migration deja engagee.