Quel outil de migration faut-il choisir ? La question est séduisante, mais elle inverse l’ordre des priorités. Une migration serveur vers Proxmox VE réussit d’abord grâce à un inventaire exhaustif, à une restauration testée de la machine source, à une fenêtre de bascule maîtrisée et à un déclencheur de rollback écrit. L’outil d’import ou de live-import ne vient qu’après. Sans restauration source validée et rollback défini, aucune signature ne devrait être donnée.

Ce guide heure par heure montre pourquoi la question de l’outil est mal posée, comment bâtir l’inventaire et les prérequis, puis comment choisir en dernier import complet, live-import, restauration, clone, OVF ou import disque. Vous suivrez le test de restauration de la source, la conception de la sauvegarde (backup) et du cluster Proxmox VE pendant la migration, ainsi que le planning de J-7 à J+7 : préparation, mesure, gel, point go/no-go, H0 avec synchronisation finale, bascule, validation, recette et clôture formelle. Nous traiterons aussi les seuils de rollback, les risques des pilotes et du matériel sur les sources physiques, et ce qu’il faut signer ou non. Les techniques P2V et V2V documentées pour Proxmox VE serviront de cadre, sans remplacer le plan de retour arrière.

Pourquoi la question « quel outil de migration ? » est mal posée

Une migration de serveur physique vers Proxmox VE ne se gagne pas sur l’assistant d’import retenu. Elle se gagne, ou se perd, sur quatre livrables écrits : un inventaire validé, une restauration testée de la machine source, une fenêtre de bascule contractualisée et un déclencheur de rollback signé.

C’est une position d’auteur, assumée comme telle. L’outil est la variable la plus substituable du projet : il se met à jour, se corrige, se remplace. Une fenêtre d’arrêt sous-dimensionnée ou un retour arrière jamais préparé ne se rattrapent pas après coup, quand la production est à l’arrêt et que personne ne sait encore qui a l’autorité de dire stop.

Un choix technique qui reste ouvert

Le wiki Proxmox classe les migrations en P2V et V2V et documente plusieurs chemins : import complet, live-import, restauration depuis sauvegarde, clone, import OVF, import disque, et « attach disk & move disk » pour une interruption minimale. Aucun de ces chemins n’est la réponse en soi ; c’est l’état réel de la source qui tranche, pas la disponibilité d’un bouton dans l’interface.

Le scénario d’échec courant

Une prestation signée au lendemain d’une démonstration d’import à chaud. Machine source jamais restaurée. Durée d’indisponibilité estimée de mémoire. Aucun seuil de retour écrit noir sur blanc, donc aucun critère pour arrêter les frais à H0+2 sans négocier à chaud.

Cet article livre un modèle horaire réutilisable, de J-7 à la clôture, les critères de go/no-go et la liste des points à obtenir avant toute signature.

Inventaire et prérequis : le document qui décide du périmètre

L’inventaire fixe le périmètre contractuel : ce qu’il omet n’existera pas le jour de la bascule.

Inventaire matériel et logiciel. Modèle exact du serveur, firmware, mode de démarrage (UEFI ou BIOS), contrôleur RAID et niveau de cache, version du système, noyau en place, versions applicatives et moteurs de base de données. Vérifier la compatibilité de l’hôte : Proxmox VE repose sur Debian avec un noyau personnalisé, à valider par un démarrage réel.

Dépendances à cartographier. Résolution DNS, appartenance à l’annuaire (Proxmox VE accepte Active Directory, LDAP ou PAM), montages réseau, tâches planifiées, certificats, licences liées au matériel (dongles, clés USB, licences OEM), adresses IP ou MAC réellement figées côté firewall ou DHCP.

Deux familles de données. Le chaud (écritures actives, bases, journaux) se synchronise dans la fenêtre ; le froid (archives, médias, images applicatives) se copie des semaines avant. La durée d’arrêt se dérive de volumes mesurés.

Dimensionnement de la cible. CPU, RAM, stockage du cluster Proxmox VE, marge pour la perte d’un nœud, débit réel du stockage partagé. Prévoir au moins 2 Go pour l’hôte, plus environ 1 Go de RAM par To sous ZFS ou Ceph, et retenir que ZFS et Ceph excluent un contrôleur RAID matériel. Les tests de performance se font avant la bascule. Le dimensionnement engage un arbitrage économique à trancher tôt : Serveur virtuel privé ou cloud public : le vrai calcul TCO pour une PME de 20 à 100 postes.

Critères de sortie. Liste des services avec ordre de démarrage, tests de recette, durée d’indisponibilité acceptée par le métier, nom du valideur.

Import complet et live-import : des options à choisir en dernier

L’inventaire validé, les chemins d’import ne se choisissent pas à l’intuition. Le guide « Migrate to Proxmox VE » du wiki Proxmox recense les méthodes disponibles : import complet de VM, live-import, restauration depuis sauvegarde Proxmox VE, clone, import OVF, import disque, puis attach disk & move disk pour une interruption minimale. Ce guide a été rédigé avec une source VMware en tête, mais son auteur indique que la plupart des sections s’appliquent aux autres hyperviseurs. Il faut donc le lire comme un cadre de référence, pas comme une procédure propre à un éditeur.

L’import complet convient à une source peu sollicitée ou déjà arrêtée. Le live-import réduit l’indisponibilité, mais exige une source saine, un réseau stable et une bande passante dimensionnée ; il impose en particulier une synchronisation finale dont la durée doit être mesurée à froid avant de figer la fenêtre.

Prérequis communs à prévoir : accès API ou SSH à la source, version de source prise en charge, espace temporaire suffisant sur le stockage cible, et horodatage systématique de chaque étape pour reconstituer la chronologie en cas d’incident. Un cadre de migration posé avec un partenaire IT externe évite de découvrir ces manques pendant la fenêtre. C’est l’état de la machine source qui décide du chemin retenu, pas la disponibilité d’un assistant dans l’interface ; le choix se fait après l’inventaire et le test de restauration décrits dans la section suivante.

Restauration, clone, OVF et import disque : ce que chacun impose

Une fois les imports complets et live-import écartés, quatre chemins restent, et leurs contraintes n’ont presque rien en commun.

Restauration depuis sauvegarde. Souvent le chemin le plus contrôlable : elle réutilise une chaîne déjà éprouvée et transforme la migration en exercice de restauration, donc en événement répétable et chronométrable. Attention toutefois à la dépendance ainsi créée : si cette chaîne s’arrête à un NAS local, elle ne couvre pas le sinistre simultané, comme expliqué dans pourquoi un NAS local ne suffit pas sans copie offsite vérifiée.

Clone. Pertinent en V2V, entre hôtes ou entre stockages. Sur une source physique, la conversion reste de toute façon à faire : le clone n’apporte alors aucune valeur.

Import OVF et import disque. Formats vmdk, qcow2, raw : ces chemins conviennent aux machines déjà exportées ou aux disques récupérés. Prérequis non négociable, un stockage intermédiaire assez rapide, faute de quoi la recopie allonge directement la fenêtre d’arrêt.

attach disk & move disk. Documenté par le wiki Proxmox, il limite l’interruption au basculement du disque et au test de démarrage, ce qui le rend particulièrement adapté aux gros volumes qu’on ne peut pas recopier deux fois dans la nuit.

Pilotes, à régler avant tout import. Une source Windows XP ou 2003 exige l’activation des pilotes IDE standards (wiki Proxmox), sans quoi la VM risque de ne pas redémarrer après conversion. Tout passage ultérieur à VirtIO impose d’injecter les pilotes dans l’image source au préalable.

Ces chemins choisis, reste à vérifier la source elle-même.

Le test de restauration de la machine source, avant toute bascule

Aucun chemin d’import ne dispense de l’étape suivante, et celle-ci n’est pas négociable : on ne planifie pas la bascule d’une machine que l’on n’a pas déjà restaurée au moins une fois. Le test se mène sur une cible isolée, réseau coupé, hors du cluster de production.

Réalisé ainsi, il valide la chaîne complète, sauvegarde, restauration, démarrage et services applicatifs, et fournit la seule mesure fiable du temps de reprise. C’est cette durée chronométrée, jamais une estimation, qui dimensionne la fenêtre d’indisponibilité et alimente le plan de retour arrière.

Le wiki Proxmox décrit la méthode Clonezilla en CD live comme rapide, fiable et indépendante du système d’exploitation, à condition de préparer la machine source au préalable. Cette préparation est systématiquement sous-estimée : elle consomme les heures de fenêtre, pas la copie.

Le compte rendu du test documente :

démarrage sans intervention manuelle ;
cohérence des données, horodatages, comptages et totaux de contrôle ;
accès fonctionnel aux périphériques et aux licences ;
absence d’erreur bloquante dans les journaux ;
durée réelle de bout en bout.

Les écarts se consignent enfin noir sur blanc : ce qui a échoué, ce qui a été contourné, ce qui reste accepté, par qui et à quelle date.

Le plan de bascule s’appuie alors sur une mesure vérifiée, pas sur une espérance. Reste à concevoir, avant la bascule, la sauvegarde cible et le cluster qui hébergeront la machine.

Sauvegarde Proxmox VE backup et cluster Proxmox VE cluster : à concevoir pendant la migration

Une fois la restauration de la source chronométrée, la question n’est plus de savoir si l’on sait revenir, mais si l’on saura revenir dans les délais. C’est ici que la sauvegarde et la haute disponibilité entrent dans le plan de migration, et non dans un lot ultérieur. Le guide « Migrate to Proxmox VE » du wiki Proxmox intègre d’ailleurs une section Backup et une section High Availability dans ses concepts, ce qui confirme cette lecture.

Chaîne de sauvegarde cible sur Proxmox VE

Concevez la chaîne cible avant la bascule : un serveur de sauvegarde dédié ou un espace réservé sur un NAS Synology, avec déduplication, vérification des sauvegardes et politique de rétention écrites. Tant qu’un rollback reste possible, les sauvegardes de la machine source doivent rester exploitables : aucun effacement du dernier cycle complet avant la clôture, et donc jamais pendant la fenêtre de bascule.

Cluster Proxmox VE et gel des versions

Prévoyez au moins trois nœuds pour disposer d’un quorum utilisable, plus un réseau de cœur dédié. N’activez pas la haute disponibilité sur les VM le jour de la bascule : un redémarrage automatique pendant la fenêtre fait perdre la maîtrise des opérations. Surveillez enfin les régressions de noyau. Le roadmap de Proxmox Backup Server 4.1 signale des anomalies avec le noyau 6.17, des sauvegardes qui se bloquent sur certaines configurations et des problèmes de démarrage possibles sur certains serveurs Dell PowerEdge. La parade tient en deux gestes : figer les versions validées et lire les notes de version avant la bascule.

Ces engagements gagnent à être contractualisés dès la prise en charge, comme le décrit la mécanique d’un onboarding IT externalisé et de ses 30 premiers jours avec un nouveau prestataire informatique. Reste à transformer ces décisions en tableau horaire.

De J-7 à H-4 : préparer, mesurer, figer

Après la validation de la chaîne de sauvegarde et du cluster, la fenêtre se prépare à froid, de J-7 à H-4 : c’est la phase de gel et de mesure.

Geler la source. À partir de J-7, plus de mise à jour du noyau ni des paquets, plus d’installation applicative. Notez versions de noyau, paquets, firmware et mode de démarrage (UEFI ou BIOS). La machine du jour J doit être exactement celle qui a passé le test de restauration.
Première copie des données froides. Lancez la copie complète des volumes non actifs (archives, médias, images applicatives), vérifiez chaque lot par somme de contrôle, puis relevez les mesures de référence : temps de démarrage, temps de restauration, latence disque, pics CPU et mémoire. Ces valeurs chiffrées, et non des estimations, calibrent la fenêtre.
Tableau horaire nominatif. Une ligne par tâche, un responsable nommé en face, une heure de début et de fin. Diffusez-le au métier, au support et aux fournisseurs. Un plan gardé dans un carnet personnel ne survit pas au premier écart, comme le rappelle ce qui se passe réellement pendant les 72 heures critiques d’une migration.
Accès hors bande. Testez IPMI, iDRAC, console série, comptes d’urgence et basculez sur un canal de communication unique avant H0. Une console injoignable pendant la fenêtre la consomme entièrement.
Point d’entrée du rollback. Fixez dès maintenant l’image conservée de la source, son emplacement exact, la durée de restitution mesurée au test et la personne habilitée à déclencher le retour. Sans ces quatre éléments, le retour reste une intention.

Ces mesures alimentent le point go/no-go de H-4.

De H-4 à H-1 : fenêtre rapprochée et point go/no-go intermédiaire

À H-4, la machine source est gelée et les mesures de référence sont prises. Il reste à verrouiller la fenêtre, puis à décider sur des faits.

1. Annonce écrite de la fenêtre. Diffusez aux utilisateurs, au support et aux fournisseurs l’heure de début, l’heure de fin contractuelle et le canal de crise unique. Une seule source d’information, aucun fil de discussion parallèle : le guide de gestion de crise de l’ANSSI consacre une fiche entière à cette discipline.

2. Sauvegarde de sécurité de la source. Déclenchez-la, notez l’heure exacte de fin et vérifiez que le pointeur de restauration déjà testé reste exploitable. Une sauvegarde non vérifiée n’est pas un filet, c’est une hypothèse.

3. Dernière synchronisation différentielle. Relevez le delta réellement transféré et projetez le temps de synchronisation finale à partir de cette mesure. C’est ce delta, jamais la durée de la copie initiale, qui détermine si la fenêtre tient.

4. Point go/no-go intermédiaire. Réunissez-le sur des critères écrits, cochés un par un : état des disques, journaux d’erreurs, statut de la sauvegarde, disponibilité effective des intervenants, état de la cible Proxmox VE. Ces vérifications faites, la disponibilité effective de tous les intervenants est confirmée et la fenêtre serrée peut s’ouvrir sur H0.

5. Contrôle final des accès et du cluster. Testez une dernière fois les accès de secours, ainsi que les règles du pare-feu qui encadrent le canal d’administration, puis vérifiez le quorum du cluster Proxmox VE. Découvrir un nœud défaillant à l’instant de basculer transforme une opération planifiée en incident.

Ces cinq contrôles passés, la fenêtre serrée peut s’ouvrir sur H0.

H0 : freeze, synchronisation finale, bascule, validation

À H0, la fenêtre s’ouvre sur une décision binaire, pas sur une renégociation du périmètre.

Freeze. Basculez les applications en maintenance, puis arrêtez proprement les services qui écrivent et les moteurs de base de données (systemctl stop, arrêt SGBD, purge des files d’attente). Une coupure brutale de la machine laisse des journaux et des transactions incohérents, y compris après la restauration de la cible.

Synchronisation finale. Transférez le delta accumulé depuis H-1, horodatez chaque étape et comparez la durée réelle à l’estimation. Tout dépassement au-delà de la marge prévue remonte au décideur avant l’arrêt des services. Contrôlez ensuite l’intégrité (sommes de contrôle, comptages, horodatages des dernières écritures) avant de démarrer la cible.

Contrôles au premier démarrage. Vérifiez dans cet ordre : pilotes IDE ou VirtIO effectivement chargés, licence liée au matériel reconnue, adressage réseau identique, montages présents, jonction à l’annuaire et résolution DNS fonctionnelles. Chaque échec se consigne, il ne se corrige pas à chaud.

Go/no-go final. La décision repose sur les critères écrits ; elle est horodatée, consignée et prise par un décideur unique disposant d’un suppléant nommé à l’avance. Le plan de retour relève du même cadre de planification de continuité que celui décrit par le NIST SP 800-34 Rev. 1.

Rollback. Si le retour est déclenché, exécutez le plan déjà rédigé, dans l’ordre prévu : remise en production de la source, rétablissement des flux, reprise des sauvegardes. Aucune réparation de la nouvelle machine pendant que la production est arrêtée.

La fenêtre se referme sur un état documenté, prêt pour la recette métier.

De H0+1 à J+7 : recette, surveillance renforcée, clôture formelle

Une fois la cible démarrée, la recette métier reprend l’ordre de démarrage convenu. Chaque application est horodatée au moment où elle redevient disponible, et le responsable métier valide explicitement son retour en service. L’équipe technique ne valide pas à sa place : elle fournit les preuves, journaux et tests, le métier prononce l’acceptation.

La surveillance renforcée court plusieurs jours, jusqu’à J+7, pas quelques heures. On suit les erreurs applicatives, la latence, les alertes de supervision et, surtout, les sauvegardes nocturnes. Une sauvegarde Proxmox VE qui se termine sans erreur ne suffit pas : elle est montée et restaurée sur une cible isolée.

La machine source reste éteinte mais intacte jusqu’à la clôture. Aucun recyclage, aucune réinstallation, aucun effacement de disque : c’est le dernier filet de sécurité si un défaut n’apparaît qu’à J+4.

La clôture est formelle : procès-verbal de bascule, écarts constatés, actions correctives, mise à jour de la documentation, de l’inventaire et des plans de reprise. Le déclencheur de rollback reste actif jusque-là. Il n’est archivé qu’avec le procès-verbal, preuve que la sortie du mode dégradé a été décidée sur des critères mesurés, et non sur un calendrier.

Le déclencheur de rollback écrit : des seuils, des noms, un délai

Le déclencheur de rollback donne son sens à la surveillance décrite plus haut : rédigé et signé avant H0, il transforme une intuition en décision exécutable.

Des seuils mesurables, pas des intentions

service critique indisponible au-delà d’une durée fixée ;
taux d’erreur applicatif supérieur à un seuil donné, sur une fenêtre de mesure définie ;
incohérence ou perte de données constatée par un contrôle d’intégrité ;
dépendance indispensable non résolue : annuaire, résolution DNS, licence, périphérique lié au matériel.

Un décideur unique, un suppléant nommé Nom et suppléant écrits, avec l’autorité de dire stop. Un comité consultatif pendant une fenêtre d’arrêt coûte des heures et dilue la responsabilité.

Un délai de décision, pas une prolongation Passé le seuil horaire convenu, par exemple la fin de la fenêtre contractuelle, le retour devient la décision par défaut. Personne ne prolonge l’indisponibilité pour voir ce que cela donne.

Un retour déjà exécutable Ordre des opérations, qui remet la source en production, qui rétablit les flux réseau et les sauvegardes, et durée réelle de l’ensemble : chiffre tiré du test de restauration, jamais d’une estimation. Le cadre de planification de contingence du NIST SP 800-34 fournit la logique déclencheurs et responsabilités, pas vos seuils.

Les cas ambigus se tranchent à froid Pilote non pris en charge, application liée à une clé matérielle, base volumineuse dont la vérification dépasse la fenêtre : ces arbitrages se décident avant H0, jamais en direct. Les deux premiers reviennent d’ailleurs comme causes d’échec récurrentes.

Pilotes et matériel : les risques sous-estimés des sources physiques

Le déclencheur de rollback ne vaut que si les pilotes et le matériel de la source ont été traités à froid. C’est ici que se perdent les fenêtres d’arrêt.

Windows XP et 2003 : pilotes IDE standards. Le wiki Proxmox recommande d’activer les pilotes IDE standard sur la machine source avant toute conversion, avec mergeide.reg fourni pour XP et 2003. Sans cette préparation, la VM convertie peut ne plus redémarrer ; le correctif se fait à froid, jamais pendant la bascule.

VirtIO : présent avant la bascule. Basculer directement le disque système sur VirtIO SCSI sans pilotes produit un INACCESSIBLE BOOT DEVICE. La procédure documentée consiste à attacher un disque factice de 1 Go, installer les pilotes, éteindre la VM, retirer le disque, puis rattacher le disque système en SCSI et corriger l’ordre de démarrage. Pour Windows Server 2012, le wiki cite l’ISO VirtIO 0.1.189. Proxmox recommande SCSI en « VirtIO SCSI single » ; le mode VirtIO block pourrait être déprécié.

Linux : rejouer la couche matérielle. Noms d’interfaces réseau, entrées /etc/fstab en UUID plutôt qu’en /dev/sdX, modules chargés : tout change sous les pieds du système. À rejouer et à valider avant H0.

Matériel exotique. Contrôleur RAID propriétaire sans mode HBA, batterie de cache, démarrage UEFI contre BIOS, carte d’extension ancienne. Proxmox VE reposant sur Debian avec un noyau personnalisé, la compatibilité se vérifie au démarrage, elle ne se suppose pas.

Sécurité de l’opération. Console de management jamais exposée sur Internet, réseau d’administration séparé, migration lancée uniquement depuis des postes maîtrisés, et aucun mot de passe de secours qui circule par messagerie.

Ces vérifications se font avant de figer la fenêtre, pas pendant qu’elle court.

Ce qu’on signe et ce qu’on ne signe pas

Ces préparations techniques posées, il reste à verrouiller le contrat.

La checklist contractuelle

Exiger noir sur blanc : inventaire validé, mesures de référence (démarrage, restauration, latence), fenêtre horaire chiffrée, tableau de bascule avec un responsable par ligne, plan de retour testé, chaîne de sauvegarde opérationnelle, point de non-retour fixé et procès-verbal de clôture. Cette liste transforme une prestation en engagement vérifiable.

L’outil vient en dernier

Une démonstration d’import à chaud ne prouve rien sur une machine jamais restaurée. C’est l’état réel de la source, établi par l’inventaire et le test de restauration, qui détermine le chemin retenu parmi ceux que documente le wiki Proxmox.

Les assistants de migration changeront encore de version dans les prochains mois ; l’inventaire et le plan de retour, eux, ne changeront pas d’avis.

Conclusion

Retenez trois exigences. L’inventaire et les prérequis fixent le périmètre réel, bien avant le choix de l’outil. La checklist contractuelle transforme cette préparation en engagement vérifiable.

Passez à l’action : validez l’inventaire, mesurez une restauration réelle et rédigez le rollback avant de signer la bascule. Une bascule réussie n’est pas une démonstration, c’est une preuve.

Migration serveur vers Proxmox VE : plan heure par heure