Virtualisation d’un serveur physique Windows Server 2008 (R2) dans Proxmox (2/2)

Suite et fin de notre virtualisation P2V, la première partie de l’article est à retrouver ici.

Dans l’article précédent, nous avons utilisé VMware Converter pour obtenir un fichier .vmdk à partir d’un serveur physique, puis nous avons convertit ce fichier au format QCOW2 ou RAW.

Il est temps maintenant de créer la machine virtuelle proprement dite.

1. Création de la machine virtuelle.

Dans l’interface Proxmox, créer une nouvelle VM en configurant le matériel au plus près de celui du serveur physique (ou de celui précédemment paramétré dans VMware Converter) :

Nom de la VM

Nommer la VM

Choisir l'OS approprié

Choisir l’OS approprié, ici Windows Server 2008 R2

Ne pas mettre de disque dans le lecteur

Ne pas mettre de disque dans le lecteur

Configurer le disque

Ne pouvant configurer directement le disque issu de la virtualisation, on va créer un disque qui servira de base à son ajout ultérieur. On sélectionne donc le bus IDE (sinon Windows ne trouvera pas le disque), le stockage de la VM (local/distant), la taille du disque (identique ou légèrement plus grande que le disque du serveur physique), le format du disque (QCOW2/RAW/VMDK) et le cache Write back (plus performant).

Configurer le CPU

Configurer le CPU

Configurer la mémoire vive

Configurer la mémoire vive

vm07

Configurer la carte réseau, ici en pont sur la carte physique et en VirtIO. Pensez à désactiver la carte réseau dans un premier temps afin de ne pas se retrouver avec 2 serveurs identiques sur le réseau si le serveur original est toujours démarré.

Valider la configuration

Valider la configuration

2. Importation du disque QCOW2

À ce stade, nous avons une VM prête à l’emploi, si ce n’est le disque configuré qui est vide. Nous allons donc attacher le disque QCOW2/RAW à la VM et pour ce faire il va falloir mettre les mains dans le cambouis à savoir faire un peu de ligne de commande. En effet, pour l’instant on ne peut pas ajouter un disque existant en passant par l’interface web 🙁 . Si vous n’êtes pas familier avec Proxmox, les opérations suivantes peuvent paraître un peu confuses, je vais donc résumer rapidement la suite :

  • Montage du disque dur USB contenant le disque QCOW2/RAW comme stockage utilisable par Proxmox
  • Modification du fichier de configuration de la VM afin d’utiliser le disque QCOW2/RAW
  • Déplacement du disque QCOW2/RAW du disque dur USB vers le stockage local via l’interface web

Dans la partie précédente, nous avions laisser notre disque QCOW2/RAW sur un disque dur externe monté sur /media/usb_disk. Nous allons devoir configurer ce périphérique comme stockage de Proxmox. Pour ce faire, dans l’interface web, cliquer sur Datacenter, sur l’onglet Stockage puis sur le bouton Ajouter et enfin sur Répertoire. Il ne reste plus qu’à indiquer le répertoire à utiliser et le contenu (Image disque) comme ci-dessous :

Configurer le stockage USB contenant le disque QCOW2

En fonction de ce que vous avez sélectionné dans liste déroulante Contenu, Proxmox va créer plusieurs répertoires sur le disque dur USB. Celui qui nous intéresse est le répertoire images (destiné à stocker les images disques). À l’intérieur, nous allons créer un répertoire nommé d’après le numéro de la VM, ici ce sera donc 105.

Se connecter à Proxmox en SSH ou par l’interface web en cliquant sur le bouton Shell et créer le répertoire :

mkdir /media/usb_disk/images/105

Il ne reste plus qu’à y déplacer l’image QCOW2/RAW, en partant du principe qu’elle se trouve à la racine du disque ça nous donne  :

mv /media/usb_disk/srv2k8r2.enterprise.net.qcow2 /media/usb_disk/images/105/

Si tout s’est bien passé, le disque QCOW2/RAW est maintenant visible dans l’interface web en cliquant sur le stockage usb_disk puis sur l’onglet Contenu.

Le disque apparaît bien dans le stockage USB

Le disque apparaît bien dans le stockage USB

On va maintenant éditer le fichier de configuration de la VM afin de lui indiquer le disque QCOW2/RAW (choisir le fichier correspondant à votre VM, ici 105.conf) :

nano /etc/pve/qemu-server/105.conf
bootdisk: ide0
cores: 4
ide0: local:105/vm-105-disk-1.qcow2,cache=writeback,size=147G
ide2: none,media=cdrom
memory: 16384
name: win2k8r2.enterprise.net
net0: virtio=BA:00:A6:B0:C9:F6,bridge=vmbr0,link_down=1
numa: 0
ostype: win7
smbios1: uuid=94d7f501-7d5c-4d2d-a1fa-2f8ba958f1bf
sockets: 1

On retrouve donc notre configuration et on va modifier la ligne :

ide0: local:105/vm-105-disk-1.qcow2,cache=writeback,size=147G

en

ide0: usb_disk:105/srv2k8r2.enterprise.net.qcow2,cache=writeback,size=147G

Sauvegarder et retourner dans l’interface web. Sélectionner la VM et cliquer sur l’onglet Matériel, le disque dur doit pointer sur notre disque QCOW2.

Sélectionner le disque et cliquer sur le bouton Déplacer le disque, il ne reste plus qu’à choisir la destination à savoir le stockage local (ou dans mon cas le stockage distant ZFS).

La VM est maintenant prête à démarrer.

3. Configuration de la machine virtuelle

Démarrer la VM, cliquer sur le bouton Console et vérifier qu’elle est bien fonctionnelle.

Si tel est le cas, il nous reste maintenant à améliorer ses performances en passant le disque dur de IDE à VirtIO. Pourquoi ne pas avoir configurer le disque en VirtIO dès le début ? Tout simplement car Windows ne possède pas les pilotes et que du coup la VM ne pourrait démarrer.

L’astuce consiste à ajouter un disque VirtIO temporaire de 1 Gio puis à démarrer la VM et enfin installer le pilote.

Tout d’abord, télécharger l’ISO contenant les pilotes VirtIO à cette adresse : https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso et le téléverser dans un des stockages de Proxmox :

Monter l’ISO dans le lecteur CD/DVD virtuel de la VM :

Ajouter ensuite un disque VirtIO de 1Gio :

Démarrer la VM, de nouveaux matériels sont alors détectés. Annuler toutes les procédures d’installation de pilote et ouvrir le gestionnaire de périphériques afin d’installer les pilotes un à un.

Sélectionner le contrôleur SCSI et mettez à jour le pilote :

Indiquer la version du pilote correspondant au système d’exploitation (ici Windows server 2008 R2 64 bits) dans le dossier viostor :

Si tout ce passe bien le pilote s’installe :

Faire de même pour le contrôleur ethernet dans le dossier NetKVM (la carte réseau que nous avions préalablement configurée en VirtIO).

Ainsi que pour le périphérique PCI restant, dans le dossier Balloon.

Éteindre la VM afin de modifier le disque IDE en VirtIO. Pour cela on passe de nouveau par la ligne de commande :

nano /etc/pve/qemu-server/105.conf

On modifie la ligne :

ide0: usb_disk:105/srv2k8r2.enterprise.net.qcow2,cache=writeback,size=147G

en

virtio0: usb_disk:105/srv2k8r2.enterprise.net.qcow2,cache=writeback,size=147G

On en profite pour supprimer la ligne correspondant au disque temporaire de 1 Gio. Sauvegarder le fichier et retourner dans l’interface web.

Le disque ide0 ayant disparu, la VM ne peut plus démarrer, il faut indiquer le « nouveau » disque VirtIO en allant dans Options puis Ordre de boot  :

Démarrer la VM et vérifier que tout est OK.

À ce stade notre VM est parfaitement fonctionnelle mais il faut bien avouer que la console noVNC de Proxmox n’est pas très agréable à utiliser. Heureusement la console SPICE offre une meilleure expérience. Mais pour ce faire, il nous faut reconfigurer la carte vidéo puis installer le pilote SPICE. Dans la première partie, je vous avais fait télécharger ce fameux pilotes avant la procédure de virtualisation, histoire de l’avoir directement dans la VM au moment opportun (pour rappel il est disponible à cette adresse : https://www.spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-0.100.exe).

Éteindre la VM si elle est allumée et modifier la carte vidéo de Défaut à SPICE (qxl) :

Démarrer la VM, lancer une console noVNC et exécuter le pilote SPICE (si nécessaire l’exécutable installera aussi les pilotes VirtIO mais mieux vaut les installer comme préalablement en passant par l’ISO, histoire d’avoir des pilotes à jour).

Pour utiliser la console SPICE, il faudra installer sur votre poste client le paquet virt-viewer pour GNU/Linux ou virt-manager pour Windows (prendre la version 3 car la 4 est défectueuse).

Redémarrer la VM en utilisant cette fois la console SPICE. Il ne reste plus alors qu’à configurer la résolution d’écran de la VM.

Pour finir, un peu de ménage en supprimant physiquement les disques temporaires dans leur stockage respectifs.

Au terme de ce long article, nous sommes maintenant en possession d’une VM performante et pratique à utiliser 🙂 . Pour les questions, précisions, coquilles et critiques, les commentaires sont ouverts !

7 commentaires

  1. Hello DocGreen. Comme promis je reviens sur le P2V d’une machine sous win10. Le tuto est parfaitement clair (félicitations), il y a cependant une petite erreur au niveau du déplacement de l’image raw dans le disque virtuel, il faut remplacer mnt à 3 reprises par média sinon peut rester scotché des heures pour créer le dossier 105 ;-). A part ça la VM fonctionne mais on est très loin des performances qui étaient celle du serveur physique, en gros ça rame un max, la mémoire est utilisée à 85% en permanence, je trouve ça bizarre. J’ai été confronté à plusieurs difficultés, la première par rapport au premier boot. La machine étant sous bios UEFI, il fallait juste changer le type de bios dans la vm et le tour était joué. Ensuite, au 2 ème boot la machine crashait car la RAM renseignée était trop élevée. En fait il faut descendre la ram de 2 Gigas afin d’en « laisser » à PVE. Au 3ème ok ca démarre enfin mais queeelle leeenteur. Je suis confronté à un BSOD au bout de 5 minutes à cause du pilote asio.sys lié à la machine physique ASUS. Je redémarre donc en mode sans échec pour virer le pilote défectueux. Seul hic après, il m’est impossible de désinstaller les applis liées au monitoring de la carte mère physique. Du coup, la solution est donc de désactiver toutes ces fonctionnalités, programmes et pilotes liés à ASUS (ainsi que le raid matériel intel) AVANT la création de l’image. Ensuite j’avouerais que la console SPICE n’est pas joyeuse car il m’est impossible d’avoir une résolution correcte, le viewer ne redimensionne rien même si je redimensionne sa fenêtre. Si tu avais un bon tuyau la dessus ça serait royal. J’ai bien réussi à passer en disque SCSI mais le gain de rapidité n’est pas probant.
    Sinon je te félicite encore pour ce tuto hyper bien ficelé et utile, merci !! Au plaisir d’échanger sur proxmox avec toi car même si les débuts sont « chauds » tout cela est bien passionnant. A bientôt !!

    1. Salut Ced,

      bien vu pour le dossier /media, je corrige 😉

      Concernant les soucis de lenteurs, c’est probablement du à ZFS qui consomme pas mal de RAM pour son fonctionnement. Je pense qu’il en faut au moins 16 Gio pour faire tourner correctement 1-2 VM de type KVM.
      Les VM de type conteneurs (LXC) sont plus légères donc 8 Gio peut convenir.

      Si tu as 8 Gio ou moins, il vaut mieux utiliser Ext4 ou XFS (avec LVM).

      L’utilisation de SSD améliore aussi grandement la réactivité de ZFS.

      Concernant la virtualisation, il est effectivement important de supprimer les logiciels et pilotes qui touchent au matériel avant de virtualiser.

      Pour SPICE, il faut que je regarde mais c’est plus un outil de gestion de la VM plutôt que d’exploitation. Mieux vaut activer le bureau à distance pour avoir une expérience satisfaisante.

      A+

      1. Ah oui ce ZFS est donc gourmand en ressources, ce qui explique que ça rame. Du coup pour être en raid 1 je dois plutôt me rabattre sur la solution matérielle qui était celle d’origine ? Le souci est qu’en cas de crash je n’aurai pas d’alerte de la VM qui sera en Ext4.
        Sinon existe t’il une solution de monitoring et d’alerte sympa intégrée à PVE en cas de crash sur un des volume du ZFS raid1 ?
        J’en ai essayé une à l’aide d’un script déclenché dans le crontab mais je ne suis pas trop satisfait. A bientôt.

      1. Le RAID iRST est un RAID logiciel, je ne saurais dire comment ça se comporte avec Proxmox. Je pense qu’il vaut mieux le désactiver et laisser ZFS gérer le RAID en choisissant RAIDZ mirroring à l’installation.

        Je sais que les devs de Proxmox déconseillaient le RAID logiciel Linux (mdadm) mais plusieurs personnes affirmaient l’utiliser sans problème. Ce type de RAID permet d’avoir des alertes par email (je l’ai utilisé il y a bientôt 10 ans pour un serveur de fichier Debian et ça marchait bien).

        ZFS vise à éviter la corruption des données. Il est lent car il inscrit les données modifiées sur le HDD avant de rendre la main aux applis. La parade est d’utiliser beaucoup de RAM pour stocker ces écritures et un SSD comme cache pour les écrire rapidement avant d’enfin les inscrire sur le HDD. (cf : https://en.wikipedia.org/wiki/ZFS#Caching_mechanisms:_ARC,_L2ARC,_Transaction_groups,_ZIL,_SLOG,_Special_VDEV)

        Pour gagner en performance, tu as plusieurs solutions :

        – la plus simple (et la plus chère) serait de monter à au moins 16 Gio de RAM, de remplacer les HDD par des SSD et d’utiliser un RAIDZ mirroring avec 2 SSD voire un RAIDZ1 de 4 SSD.

        ZFS doit aussi être « tuné » pour correspondre au mieux à ta config (https://pve.proxmox.com/wiki/ZFS_on_Linux#_limit_zfs_memory_usage)

        Attention tout de même, j’ai remarqué que Proxmox a tendance à « user » rapidement son/ses SSD d’installation (si SSD grand public) car il y a beaucoup d’écritures. Il faut donc soit changer les SSD tous les 2-3 ans selon l’usure, soit utiliser des SSD « entreprise » qui supportent beaucoup de cycles d’écritures (pour un serveur perso, le prix pique un peu même si on peut en trouver d’occasion à un prix correct).

        – une solution moins coûteuse qui peut marcher mais qui est plus complexe à mettre en œuvre est d’ajouter un seul SSD à ta config. Ce SSD contiendra l’installation de Proxmox ainsi que des partitions dédiées aux ZiL et L2ARC de ZFS. Je l’ai déjà mise en oeuvre, la démarche est assez bien décrite ici : https://forum.level1techs.com/t/proxmox-zfs-with-ssd-caching-setup-guide/97663.

        Pour info, après avoir tester plusieurs configurations (dernièrement un HPE Microserver Gen10 avec un SSD pour Proxmox et 4 SSD en RAIDZ1 pour les VM), je me suis rabattu sur un « vieux » NUC D54250WYKH pour mon serveur perso :
        – i5 4250U
        – 16 Gio RAM
        – 1 SSD 500 Gio -> Proxmox + VM
        – 1 HDD 500 Gio -> Sauvegardes quotidiennes
        – 1 HDD 500 Gio USB -> Sauvegardes hebdomadaires

        Je n’utilise que des conteneurs donc ça reste assez léger. Je suis à la merci d’une panne de SSD mais tant que les sauvegardes fonctionnent, ça me va.

        Pour des besoins plus poussés, il y a moyen de monter des machines correctes pour pas très cher via des sites de matériel d’occasion comme https://www.servershop24.de/en/
        J’ai monté un cluster Proxmox qui me sert de lab en upgradant 2 vieux serveurs via ce site pour 400-500€ (HPE Proliant 360G5 / 2 x 4 coeurs / 64 Gio DDR2 / RAIDZ1 6 x 300Gio HDD 10000tr/min).

Répondre à Ced Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *