ou pourquoi Microsoft fait toujours de la merde avec ses propres OS et outils de virtualisation…
Contexte
Il me restait une machine (bare-metal) qui ne servait qu'à une chose : faire tourner une VM Windows Server 2008R2 dans VirtualBox. Cette machine étant anté-diluvienne et dans le cadre de la réorganisation des machines et ressources (comprendre : virer les vieux coucous et se débarasser définitivement de VirtualBox), l'objectif était de déplacer cette VM sur une machine dédiée à la virtualisation, et faisant tourner Hyper-V.
Windows Server 2008R2 n'étant plus supporté par Microsoft, c'est pour ça que c'est dans une VM non connectée à Internet.
La migration
Rien de compliqué. Arrêter la VM, et utiliser la ligne de commande
VBoxManage clonehd <chemin du fichier vdi de la vm d'origine> <chemin du fichier de destination au format vhd> --format VHD
Par exemple
VBoxManage clonehd E:\VMs\ws2008\ws2008.vdi E:\VMs\export\ws2008.vhd --format VHD
Commande ultra-classique et indiquée dans à peu près tous les tutos trouvables sur Internet.
Copier le fichier vhd sur la machine faisant tourner Hyper-V.
Créer une VM de type Génération 1 (génération UNE), paramétrer les ressources.
Démarrer la VM.
Et là, c'est le drame
BSOD direct.
Écran bleu de la mort
Message : A problem has been detected and Windows has been shut down to prevent damage to your computer.
blablabla baratin habituel, éteindre et rallumer, vérifier la présence de virus, etc.
Technical information: STOP: 0x0000007B (suite de nombres sans importance)
La cause ?
Hyper-V est particulièrement chiant à ce niveau là.
Sur les machines de génération 1, c'est codé en dur et non paramétrable :
- BIOS Classique
- Table de partition MBR/MS-DOS
- Disques IDE uniquement
Et sur les machines de génération 2, idem, codé en dur et non paramétrable :
- BIOS uEFI sans CSM
- Table de partition GPT
- Disques SATA/SAS uniquement
Les machines sous Windows Vista, 7 et 8 étaient sur une période de transition entre BIOS et uEFI, MBR et GPT.
Ici, la VM qui tournait dans VirtualBox était en mode BIOS classique, table de partition MBR, mais disque SATA.
Et Microsoft, dans son excellente bonté, ne gère pas ce type de configuration pour Hyper-V.
La solution de convertir l'image disque au format GPT n'étant pas envisageable (chances de perte de données supérieure à 150%).
Ah, et créer une machine en génération 2 dans Hyper-V ne marche pas non plus (système non bootable).
La solution ?
C'est un peu bourrin, mais bon, on a l'habitude.
Monter la base de registre, corriger quelques valeurs et redémarrer.
Montage de la base de registre de la VM
Démarrer en mode Recovery (c'est proposé lors du redémarrage).
System Recovery Options, select a keyboard input method
Sélectionner la disposition du clavier.
System Recovery Options, user name and password
Saisir les informations de connexion de l'administrateur local.
System Recovery Options, choose a recovery tool
Cliquer sur “Command Prompt”.
cmd.exe
Taper regedit puis appuyer sur Entrée.
regedit - Registry editor
Cliquer sur HKLM (HKEY_LOCAL_MACHINE)
On va maintenant charger la ruche HKLM de la machine virtuelle (celle sélectionnée ici est celle de l'environnement de récupération).
regedit - Registry editor, File menu
Cliquer sur “File” puis sur “Load Hive…”.
Load Hive
Cliquer sur “Computer”, puis sur le disque correspondant à celui de la VM (ici, D:)
Load Hive - look in folder
Descendre dans le répertoire Windows -> System32 -> config.
Load Hive - SYSTEM selected
Ouvrir “SYSTEM”.
Load Hive - type Key Name
Ici, on va saisir le nom de la clé dans laquelle sera montée la ruche SYSTEM de la VM.
Saisir par exemple RECOVERY_HKLM
regedit - Registry editor, key RECOVERY_HKLM
La ruche de la VM est bien montée et ses entrées sont présentes.
Modifications des clefs de registre
Descendre dans
RECOVERY_HKLM -> ControlSet001 -> services
Puis, pour ces clefs, changer ces valeurs
- intelide -> Start = 0
- LSI_SAS -> Start = 0
- msahci -> Start = 3
- pciide -> Start = 3
regedit - HKLM - ControlSet001 - services - intelide
regedit - HKLM - ControlSet001 - services - intelide - Start - Edit DWORD value
Une fois ces modifications terminées, aller dans “File” -> “Unload Hive…”, puis fermer Regedit, cmd.exe, et redémarrer la VM (restart).
Si c'est bon, Windows devrait démarrer correctement.
Windows Server a démarré correctement.
Conclusion
Microsoft n'est pas foutu de gérer correctement ses propres OS, notamment lors de migrations.
Genre, c'est pas possible de détecter le type d'OS, de comparer les clefs de registre et de proposer la correction automatique de ces clefs s'il y a discordance entre le type de disque de la VM et ce qui est attendu.
L'autre solution serait de permettre le démarrage des disques SATA en génération 1.