Pour des raisons d'arrêt de contrat de maintient en opération de "vieux" serveurs (IBM/LENOVO/HP/DELL) et afin d'anticiper une panne matérielle, j'ai proposé de virtualiser ces serveurs physiques.
J'ai de l'OS Microsoft et du Linux.
J'ai réussi à virtualiser du très vieux (Win2k srv)* et du plus récent (w2k8 r2) via "disk2vhd" (Sysinternal/Microsoft) sans trop de problèmes (il faut apprendre à contourner l'EFI sinon tout ce qui est MBR rien à faire).
En revanche dès que je tente de virtualiser du Microsoft alors que le physique est sur SAS/RAID j'ai des difficultés mais c'était évident (boot ok, mais lors du chargement des pilotes ça panique et c'est normal). Disk2VHD propose bien une option documentée pour faire abstraction de la HAL lors de la virtualisation, mais seulement pour des machine physiques XP/W2k3.
J'ai bien tenté d'amorcer sur un iso et de tenter pléthore d'options récupération/réparation en allant même à la main dans les ruches hardware de la BDR pour décharger/charger des entrées en relation avec les contrôleurs SCSI mais échecS.
Tant pis je passerai par ce que je voulais éviter à tout prix : créer une VM de toute pièce, l'insérer dans l'architecture AD et transférer tous les rôles FSMO sur ce nouveau serveur puis monter des DC virtuels tout de suite après répartir le catalogue et au final faire un demote sur les physique avant de les couper (pas de retour arrière possible).
Ensuite je vais galérer pour quelques serveurs qui ont un rôle de NPS (certification horrible à remettre en oeuvre).
Ce qui me bloque *réellement* c'est la virtualisation de Linux. ça échoue systématiquement.
Si les physiques virtualisés bootent correctement, ça finit systématiquement par un Kernel panic.
J'ai trouvé moulte documentation sur le sujet, certains sont partisans de recréer certaines parties de l'os virtualisé (/initramfs ou /initrd ou autres portions), d'autres chrootent leur os virtualisé afin de modifier le gestionnaire d'amorçage en cas de glissement du /dev/sd[n] vers sd[x].
Aucune de ces options ne m'a été d'un grand secours.
Et puis hier je passe à la virtualisation d'un (rires) Mandriva 2005* il s'agit d'un Postfix que je ne *peux pas* couper et je galère bien.
Virtualisé j'ai LILO (22.5.8) qui amorce mais aucune option possible, pas d'interaction et là encore un Kernel Panic.
Je me dis que je vais tenter de le chrooter mais comme pas possible d'avoir un mode interactif avec ce LILO "protégé" je me décide à booter sur un iso d'Ubuntu et là ... kernel panic !
Je tente, à la louche, une bonne douzaine de distribs : kernel panic.
64 ou 32 bits, même résultat.
Je fais des recherches afin de savoir si Hyer-V est (volontairement ?) allergique à Linux, mais bon il semble qu'il y ait un minimum de tolérance et les VM Linux sont du domaine du possible.
OUI MAIS. Il existe en effet un problème de taille : il faudrait fournir au noyau les modules lui permettant de gérer des disques virtuels
https://www.linuxquestions.org/question ... 175505288/
Au moment où je vous écris je suis sur cette piste.
Il existe un possibilité d'intégrer des services Hyper-V à la machine https://oitibs.com/hyper-v-lis-on-ubuntu-18-04/ mais 1° il faut le faire sur le physique et/ou une VM qui fonctionne. 2° il faut pouvoir le faire (cas présenté d'un Ubuntu 18, je doute fortement de pouvoir sauver le Postfix qui tourne sur un Mandriva).
Ma question est la suivante : Comme j'ai un taux d'échec de virtualisation qui grimpe, je voulais savoir si parmi vous il s'en trouveraient qui auraient réussi des P2V de Linux (et même des physique Microsoft avec du RAID) vers ... VmWare (Esxi), parce que si c'est le cas je vais faire le forcing pour abandonner Hyper-V au profit d'Esxi.
Il y a ... disons 15 ans, je sais qu'il y avait des agents de virtualisation vers ESX qui étaient très compétents, je crois savoir que ces outils ont évolué et existent toujours pour des architectures Esxi/Vcenter/Vsphere (même si je suis totalement paumé avec les produits VmWare de nos jours).
Bon, ceci dit j'ai appris de trucs sympathiques : contournement/bricolage EFI, utiliser qemu pour générer du .vmdk/.vhdx et d'autres.
* C'est le client qui maintient ce truc délibérément, pas moi.
