Proxmox : Migration d’une VM Hyper-V

Proxmox : Migration d’une VM Hyper-V

Migration de VM Hyper-V vers Proxmox 6.

Aujourd’hui nous allons voir comment migrer une machine virtuelle Windows Server 2012 R2 depuis un Hyper-V (version 2019) vers un Proxmox en version 6.4.4.

I) Le lab et rapides explications~

Rien de très sorcier ici :

  • PVE 6.4.4 : 192.168.0.100/24 ;
  • Hyper-V 2019 : 192.168.0.110/24 ;
  • VM ActiveDirectory sous WS2012 R2: 192.168.0.150/24 ;

Côté AD, je n’ai créé qu’un ou deux utilisateurs, ainsi que deux OUs. L’important est vraiment de s’assurer qu’après la migration les users soient toujours là, mais en pratique aucun soucis. D’ailleurs, nous verrons une commande pour vérifier si le disque virtuel ne présente pas de corruptions (toujours utile à savoir, surtout qu’en production ce ne sera pas de simples disques de 30Go que vous allez migrer, mais des disques faisant plusieurs Téraoctets…).

II) Copie du disque VM vers le nœud Proxmox

Bien, une fois votre VM installée et votre AD un peu peuplé, on peut stopper la machine virtuelle, puis copier son disque.

Deux OUs, et deux users, classique.

Pour copier le disque il n’y a pas de manipulations particulières, simplement copier le .vhdx, car même si la documentation de Proxmox ne parle que de .vhd, ce dernier supporte tout à fait les .vhdx. Aucun soucis donc.

Sachez cependant qu’une applet Powershell existe pour convertir un .vhdx en .vhd, si vraiment le besoin s’en fait sentir.

Si vous devez copier un disque de gros volume, le plus simple est encore de le copier sur un volume partagé, avec une liaison Gigabit voir 10-Gigabit. Sinon, dans le cadre de ce lab, un simple scp suffit :

Ici je copie directement le disque depuis mon hôte Hyper-V, à destination de mon nœud Proxmox, dans le dossier root.

Si vous vous posez la question “quid si la VM possède plusieurs disques ?“, et bien en théorie pas de soucis, la marche à suivre sera sensiblement la même, mais ne l’ayant pas encore pleinement testé à l’heure où j’écris ces lignes, je ne peux vous le garantir. Sûrement un prochain article !

III) Re-création de la VM côté Proxmox

La première étape est donc de re-créer une VM, en essayant dans la mesure du possible de reprendre les mêmes configurations hardware (si votre VM avait 4Go de ram, ne pas lui en mettre 2, ou même 8, en tout cas au départ, etc.)

On créer donc notre VM, de sorte que :

  • L’OS Invité choisi soit de type Windows (ou Linux si votre VM était une Linux, cela tombe sous le sens) ;
  • Pas encore d’image ISO à attacher ;
  • Au niveau de la carte graphique, j’ai lu que SPICE était assez souvent utilisé, mais ici je garderai le standard sous peine d’avoir un curseur qui n’en fait qu’a sa tête… ;
  • Concernant le Contrôleur SCSI, bien choisir VirtIO SCSI ;
  • Concernant le BIOS, opter plutôt pour l’OVMF/UEFI ;
  • Concernant le disque, ce n’est pas important car une fois notre VM créée celui-ci sera supprimée pour être remplacée par notre .vhdx fraîchement copié ;
  • Concernant le driver réseau, privilégiez Virtio (paravirtualisé) ;
  • Terminer, sans démarrer d’ores et déjà la VM ;

Je ne l’ai pas dit plus haut pour ne pas vous embrouiller, mais dans l’état, si l’on démarre notre VM, Windows ne détectera pas le disque ni la carte réseau. La raison est que nativement, les drivers VirtIO ne sont pas inclus dans Windows. Nous avons donc deux choix :

  • Installer les drivers VirtIO sur la VM avant de copier son disque ;
  • Démarrer tout de même la VM, puis installer les drivers par la suite ;

Je n’ai pas encore testé la première option, nous partirons donc sur la seconde. Mais avant de vouloir démarrer le tout et installer tel ou tel driver, nous devons rattacher notre ancien disque !

Bien, la première étape est de supprimer le disque de notre VM actuelle :

On le détache, puis on le supprime.

Une fois fait, on se connecte en CLI sur notre nœud Proxmox pour rattacher notre disque “Hyper-V” sur notre nouvelle VM :

qm importdisk 100 /root/srv-ad-01.vhdx local-lvm

On utilise donc l’utilitaire qemu pour importer notre disque sur la VM ayant l’ID 100, à adapter selon votre VM donc. Ensuite, on renseigne le chemin vers ce disque, et en dernier lieu on indique le datastore sur lequel il va être stocké. Ici il s’agit du datastore de base, local-lvm. Mais si vous utilisiez Ceph par exemple, cela aurait pu être rbd-datastore-24, ou que sais-je.

On patiente pendant l’import (qui peut parfois durer très longtemps !), et une fois fait, nous pourrons le rattacher à notre VM.

Au passage, voici la commande pour vérifier l’intégrité d’un disque, toujours pratique à effectuer avant de l’importer sur notre datastore :

qemu-img check srv-ad-01.vhdx

Extrêmement simple à réaliser, mais toujours important !

Bien, retournons donc sur les paramètres de notre machine virtuelle :

On clique donc sur Éditer, puis on choisi bien le contrôleur VirtIO SCSI. On peut éventuellement activer l’émulation SSD, le caching, ou autre.

On touche désormais presque à la fin !

IV) Démarrage de la VM et installation des drivers OpenSource VirtIO

Comme dit précédemment, il vous faudra des drivers à installer, tout dû moins pour le disque, et éventuellement pour la carte réseau si vous avez aussi choisi VirtIO. Rien de compliqué je vous rassure !

On télécharge l’ISO contenant les différents drivers VirtIO ici : https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/

*Pour ma part, j’ai choisi la version 215-2, car la dernière en date ne fonctionnait pas.

Une fois l’ISO téléchargé, on l’upload sur notre Proxmox, et on le rattache à notre machine virtuelle. On peut enfin modifier l’ordre de boot, et nous pourrons démarrer !

Ici j’ai désactivé le boot via PXE mais pas via CD, car nous voulons que notre VM boot sur notre disque, mais si on ne sélectionne pas notre lecteur CD, l’ISO ne montera pas au boot…

Au démarrage, votre Windows plantera. Puis encore une fois, et même éventuellement une troisième fois.

C’est normal ! Rappelez-vous, il n’a pas encore les drivers adéquats… cela nous permettra d’afficher le mode Rescue de Windows, et d’accéder à une invite de commandes :

Au passage, il se peut que votre curseur n’en fasse qu’à sa tête… cela peut venir du fameux pilote SPICE choisi pour la carte graphique, si vous n’avez pas choisi le standard.

Bien, on va donc maintenant installer le driver concernant notre disque SCSI VirtIO :

drvload D:\vioscsi\2k12R2\amd64\vioscsi.inf

A noter que la commande sera identique peut importe la version de Windows utilisée :

Libre à vous d’adapter !

Ensuite :

dism /image:C:\ /Add-Driver /driver:D:\vioscsi\2k12R2\amd64\vioscsi.inf

Et le tour est joué ! Ni plus, ni moins. On peut clôturer ce terminal et poursuivre le boot de manière normale :

Et voilà, votre VM Windows Server 2012 R2 migrée depuis votre Hyper-V s’allume sous vos yeux !

Cependant, comme pour le disque, il n’y a pas encore le driver correspondant à la carte réseau. Mais étant donné que notre ISO VirtIO est toujours rattaché à notre machine, rien de plus simple :

Il nous suffit d’exécuter le binaire virtio-win-gt-x64, et de choisir les drivers souhaités ! Selon plusieurs forums, il vaut mieux éviter d’installer le driver concernant le Ballooning, et de mémoire lorsque j’avais installé Proxmox sur un serveur dédié avec pfSense et autre (il y a de ça presque trois ans), j’avais aussi des soucis avec, donc autant prendre des précautions et ne pas l’installer, beaucoup se plaignant de dégradations de performances.

Comme on peut le voir, la carte réseau est désormais bien reconnue est fonctionnelle :

Et concernant notre AD lui-même, nos OU et users sont toujours bien là :

V) Conclusion

Et bien voilà, vous avez réussi à migrer un DC depuis Hyper-V vers Proxmox. Félicitations ! Comme vous le voyez, il n’y a rien de très sorcier, et plus encore si les drivers VirtIO sont installés avant la copie du disque de la VM (je n’avais pas testé avant de conclure cet article, mais je confirme que cela fonctionne).

Bref, au moins vous aurez les deux façons de faire !

Bien-entendu, c’était une première pour moi, et cela a été fait dans le cadre d’un lab. Impossible de dire si les performances seront équivalentes à Hyper-V, si certaines options peuvent être poussées plus loin en terme d’optimisation… libre à vous de donner votre grain de sel en commentaire ! J’y répondrais avec plaisir comme d’habitude.

Sur ce, je vous souhaite une bonne journée/soirée, et n’arrêtez pas d’expérimenter~

2 comments

comments user
Alex

Salut ! Un grand merci pour le temps que tu as passé pour la rédaction de cet article.

    comments user
    Mairien Anthony

    Hey ! Merci à toi Alex ! 🙂

Laisser un commentaire

You May Have Missed