P2V d’un volume GPT et EFI sous Windows Server 2008 – LA solution

Après plusieurs semaines de recherches et de tests pour virtualiser correctement (et facilement, de préférence) une installation de Windows 2008 sur un volume GPT, et sur une machine EFI, je suis en mesure de vous donner LA solution qui fonctionne!

En effet, les Disk2VHD, et autres méthodes hasardeuses comme celle de Bizconn P2VLite ne fonctionnent pas. Oubliez aussi la méthode Double-Take Replication, longue à mettre en œuvre, et nécessitant une seconde licence Windows Server 2008 pendant la migration (puisque 2 instances de Windows 2008 lancées en même temps).

La solution simple, c’est Computer Associates ARCserve D2D : http://www.arcserve.com/fr/products/ca-arcserve-d2d.aspx

Le but n’est pas de faire de la publicité pour le produit (je ne suis pas commissionné dessus), mais voici les étapes à effectuer pour que votre migration fonctionne naturellement et sans effort:

1. Télécharger et installer D2D version 16 (prendre celle avec le dernier patch) et l’installer sur la machine à virtualiser.
2. Lancer une sauvegarde de la machine vers un disque NAS, par exemple
3. Sur la VM de destination (préalablement configurée en EFI), booter sur l’ISO D2DBMR (D2D Bare Metal Recovery) et suivre l’assistant pour sélectionner l’image à restaurer et lancer le processus de restauration.
4. Rebootez la VM : et Hop! c’est fini et fonctionnel (manquera plus que les VMware Tools pour être heureux)

4 étapes simples pour arriver au résultat recherché désespérément pendant plusieurs semaines!

Edit : Il semblerait que VMware Converter 5.1 résolve ce problème. Je mettrai à jour ce billet dès que testé.VMware Converter 5.5 fonctionne convenablement pour faire un P2V d’une machine EFI avec disque GPT.

Configuration d’un IMM à distance

Vous disposez d’un serveur IBM (ou Lenovo) chez un client, et vous avez déjà été obligé de faire 200 km pour simplement allumer physiquement la machine, car votre client ne trouvait pas le bouton Power?

L’IMM va vous sauver la vie!

Le problème majeur est que la configuration réseau de l’IMM s’effectue dans le BIOS (ou l’UEFI) et redémarrer le serveur d’un client peut s’avérer compliqué.

Qu’à cela ne tienne! Voici comment configurer l’IMM directement depuis l’OS de votre client (via une connexion bureau à distance, par exemple).

  1. Commencez par télécharger ce super outil qu’est ASU (Advanced Settings Utility) chez IBM : http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=TOOL-ASU
  2. Exécutez-le afin de récupérer le fichier asu.exe (ou asu64.exe pour les systèmes x64)
  3. Maintenant, il vous suffit d’utiliser les lignes de commande ci-dessous pour configurer votre IMM, sans devoir accéder au BIOS:
    asu64 set IMM.Network1 Enabled --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.DHCP1 Disabled --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 rebootimm --host 169.254.95.118 --user USERID --password PASSW0RD
  4. Tout le secret de la configuration réside sur la carte réseau USB NDIS qui apparait sous Windows et qui obtient une IP via le service d’attribution automatique utilisé par Windows : APIPA.
    L’utilitaire ASU va communiquer avec l’IMM au travers de cette interface, via l’IP 169.254.95.118 et envoyer les commandes de configuration.
  5. Une fois les 3 premières commandes exécutées, l’IMM ne recherche plus d’IP en DHCP et se voit attribuer l’IP 192.168.70.125 : vous pouvez utiliser cette IP pour effectuer le reste de la configuration via un navigateur Web à condition que la carte de Management ait été connectée au réseau.
  6. Si cette carte n’est pas connectée, il faudra effectuer quelques manipulations supplémentaires :
    asu64 set IMM.SharedNicMode Shared --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 rebootimm --host 169.254.95.118 --user USERID --password PASSW0RD
  7. Maintenant, vous devriez pouvoir pinger 192.168.70.125.Si cela n’est pas possible (impossibilité par exemple, d’ajouter un alias IP sur la carte du serveur), vous devrez continuer la configuration en ligne de commande :
    asu64 set IMM.HostName1 IMM-SRV2008 --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.HostIPAddress1 172.18.0.3 --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.HostIPSubnet1 255.255.255.0 --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.GatewayIPAddress1 172.18.0.254 --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.DNS_Enable Enabled --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.DNS_IP_Address1 172.18.0.254 --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 rebootimm --host 169.254.95.118 --user USERID --password PASSW0RD
  8. Normalement, tout doit être configuré maintenant avec l’IP 172.18.0.3 et vous allez pouvoir gouter à la joie des reboot hard à distance, allumage du serveur qui s’était éteint après une coupure de courant…

Note importante sur le mode SharedNicMode : dans ce mode de fonctionnement, étant donné que la carte réseau de l’OS serveur est partagée avec celle de l’IMM, il y a un partage d’adresse MAC. Du coup :

  • Il est impossible d’accéder à l’IMM depuis l’OS du serveur : en effet, les paquets sont interceptés directement par l’OS et ne sont pas envoyés vers le réseau.
  • Par contre, les machines autres que ce serveur physique peuvent accéder à l’IMM

En résumé, le mode SharedNicMode est à utiliser lorsque l’on n’a pas la possibilité d’accéder physiquement à la machine, mais doit être “rétrogradé” au mode Dedicated dès que possible, pour plus de souplesse.