Combien de temps êtes-vous vraiment prêt à couper votre serveur Windows pour le sortir de Hyper-V ? La question revient à chaque fois, et la réponse qu’on redoute (une demi-journée, une soirée perdue) n’a aucune raison d’être. Le gros du travail, la copie du disque, se fait pendant que la machine continue de servir. La seule fenêtre d’arrêt réelle est celle de la bascule, et elle se compte en minutes.
Migrer une VM Windows de Hyper-V vers Proxmox sans longue coupure tient à un disque copié à chaud puis basculé sur un delta de quelques minutes ; ce qui fait échouer les gens, ce sont les pilotes VirtIO, pas le transfert.
Voici comment je procède. Je commence par construire la cible sur Proxmox : une VM avec le bon type de machine, un contrôleur de disque VirtIO, une carte réseau VirtIO, et les ressources CPU et mémoire reprises de l’existant. Cette coquille reste vide pour l’instant. Vient ensuite l’étape que presque tout le monde oublie, et qui décide de la réussite : installer les pilotes VirtIO côté Windows tant que la VM tourne encore sous Hyper-V. Sans le pilote de stockage, Windows démarre sur écran bleu une fois posé sur Proxmox, parce qu’il ne reconnaît plus le disque sur lequel il est censé booter. Ce pilote-là, viostor, n’a pas de session de rattrapage : si vous l’oubliez, vous êtes dehors. Le réseau, lui, se répare après coup, je m’en accommode.
Le transfert proprement dit ne pose pas de problème. Je convertis le VHDX en qcow2 avec qemu-img, puis je pousse l’image vers la cible. Sur un disque de 200 Go, ce premier passage tourne tranquillement pendant que la VM travaille en production. Au moment choisi pour la bascule, il ne reste qu’un delta à synchroniser : les quelques écritures survenues sur l’original depuis le début de la copie. J’arrête la VM Hyper-V, je rejoue ce dernier écart, je démarre sur Proxmox. Je contrôle alors le réseau, l’état de l’activation Windows et les services applicatifs, dans cet ordre. Et je garde un filet : la VM Hyper-V d’origine reste en place, éteinte, quelques jours encore. Si un détail cloche, le retour arrière prend trente secondes.
Reste un piège dont on parle peu et qui mord toujours au pire moment : l’activation. Changer le matériel virtuel sous les pieds de Windows peut redéclencher la vérification de licence, et une licence OEM rattachée à l’ancien hôte vous laisse un mardi matin avec un poste qui réclame une réactivation que personne n’avait vue venir. Je vérifie ce point bien en amont, jamais le jour J. Au fond, le disque se copie sans histoire à tous les coups. Ce sont les pilotes et la licence qui tranchent entre une bascule de quelques minutes et une nuit blanche.
L’an dernier, un cabinet comptable m’a appelé pour un serveur de gestion sous Windows Server, hébergé sur un Hyper-V vieillissant qu’il voulait abandonner avant une période fiscale chargée. On a installé les pilotes un lundi, lancé la copie du disque dans la foulée, et programmé la bascule le vendredi soir une fois les écritures comptables de la semaine terminées. Coupure réelle : un peu moins de dix minutes. Le lundi suivant, personne au cabinet n’avait remarqué que le serveur avait changé de maison.