C’est toujours un moment un peu magique : le serveur était là, sagement racké dans son armoire 19 pouces, et puis d’un coup il n’est plus là. Mais son âme a survécu ailleurs… Le serveur s’est dématérialisé, il a subi une conversion P2V, pour « physical to virtual ».

Après cette introduction poétique, cet article décrit comment virtualiser un serveur physique dit « bare metal » en machine virtuelle avec KVM sour Linux. Pourquoi KVM ? Parce que c’est une fantastique solution de virtualisation qui ne fait qu’un avec le noyau Linux, et qu’elle est open-source. Voir mon article introductif « KVM ou Virtualbox pour virtualiser sous Linux« .

J’ai longtemps pensé que la transformation P2V était quelque chose de sale et qu’il valait mieux réinstaller le serveur from scratch. Mais tout se passe tellement simplement sous Linux que j’ai changé d’avis.

La virtualisation d’un serveur Linux

Préparatifs

Pour que la virtualisation se passe sans accrocs, il convient de préparer le serveur Linux un minimum. Rassurez-vous, Linux étant bien conçu, il n’y a pas grand chose à faire.

Je commence en général par regrouper tous les programmes et données utiles sur le disque système, et je supprime toutes les données inutiles afin de gagner de la place. Lorsque le disque dur sera transformé en image disque, il vaudra mieux que sa taille soit réduite, par confort et pour que les sauvegardes soient le moins long possible. Le fstab doit être commenté sur les systèmes de fichiers qui ne suivront pas notre serveur après sa virtualisation, afin d’éviter un boot en mode failsafe. Pensez également à désactiver les scripts de sauvegarde qui risquent de remplir le disque système si le disque

Les daemons de surveillance des ressources matérielles sont à désactiver. Tout d’abord il y a smartd ; le monitoring smartmontools ne sera plus possible sur la machine virtuelle car elle perdra son bus SATA dans la transformation au profit d’un périphérique virtio. Vient ensuite lm-sensors qui ne servira plus à rien.

Du coté de la carte réseau, je supprime avant le dernier reboot le fichier  /etc/udev/rules.d/70-persistent-net.rules  qui sert à associer le nom de l’interface à une adresse MAC. Dans le cas de figure où le serveur a deux interfaces eth0 et eth1, cela me permettra de conserver ces noms et de ne pas poursuivre la numérotation à eth2 pour la première interface.

Transfert du disque dur et configuration

Ça y est, le moment est venu d’éteindre le serveur physique. Lorsqu’il se réveillera, il sera virtualisé. On retire donc le disque système pour l’insérer dans le nouveau serveur de virtualisation.

Pour découvrir à quel device est rattaché le disque dur, le mieux est de l’identifier par son numéro de série avec  hdparm -I /dev/sda |grep "Serial Number"  par exemple pour sda. Avec un fdisk -l  ou blkid on pourra vérifier la structure des partitions.

Il faut ensuite créer une nouvelle machine virtuelle en spécifiant une image disque déjà existante. Au moment de renseigner cette image disque, on choisira le device du disque dur (exemple /dev/sde ) avec le format d’image ‘RAW. Plutôt que de choisir un nom de device qui risque de ne pas être stable dans le temps, on peut aussi choisir les devices par numéro de série comme par exemple /dev/disk/by-id/ata-Samsung_SSD_850_PRO_512GB_S250NXAG976494Y . La dernière chaîne de caractères est le numéro de série donc le risque d’erreur est nul.

Si vous utilisez virt-manager comme moi, et que celui-ci refuse d’accepter un disque entier, regardez comment solutionner le problème dans cet article illustré de copies d’écran.

Généralement j’ajoute 3 cartes réseau virtio à la machine virtuelle, en mode bridge : une première pour gérer l’ancienne eth0 (interface interne), une seconde pour gérer l’ancienne eth1 (interface externe), et une troisième pour gérer eth2 qui est le NAT avec l’hyperviseur.

Cette dernière interface réseau est utile pour communiquer avec l’hyperviseur sur son IP interne car le mode bridge empêchera de communiquer avec lui sur les interfaces eth0 et eth1. Si cela était une nécessité absolue de communiquer avec l’hôte sur eth0 et eth1, il faudra basculer les deux interfaces réseau en mode VEPA, et utiliser un switch haut de gamme qui gère le VEPA.

Voilà, une fois que vous avez terminé la configuration de la machine virtuelle il n’y a plus qu’à l’allumer. Dans un premier temps, vous pouvez vérifier le bon déroulement avec la console VNC permise par l’hyperviseur, et puis ensuite la gestion du serveur se fait comme avant.

Pour finir : conversion du disque dur en image disque

Cela n’est pas obligatoire, mais souvent préféré dans le cadre d’une gestion de plusieurs machines virtuelles : la conversion du disque dur en image disque.

L’excellent outil qemu-img permet de faire cette transformation sur le serveur hôte. On ne pense pas tout le temps à l’utiliser pour convertir des disques entiers, et pourtant il les gère très bien.

Alternativement, on peut faire cela en deux temps si on aime attendre :

Plus utile, on peut créer un qcow2 compressé pour tenter de réduire la taille du disque, notamment sur son espace libre ou non partitionné. J’arrive à des taux de compression de l’ordre de 30% sur des disques remplis. Il y aura un impact sur les performances de la machine virtuelle, et le temps de conversion s’en trouvera rallongé. Sur un processeur récent d’entrée de gamme je tourne autour de 5 Mo/sec avec un sul processeur chargé à 100% de longues heures.

Pour rappel, le format d’image qcow2 permet le snapshot et la compression, deux fonctionnalités sympathiques.

Si vous réalisez cette transformation, je vous conseille de désactiver la partition de swap qui reste dans l’image disque afin de ne pas gréver les performances de votre système de stockage. Le swap d’une seule VM pourrait s’avérer particulièrement destructeur de performances pour toutes les VM. Si vraiment vous avez besoin de mémoire, augmentez la RAM allouée : vous êtes sur un serveur de virtualisation, il en a a revendre ! Si vous manquez de mémoire et que vous voulez faire le maximum, lisez mon article sur les optimisations de la RAM sous Linux. KSM (kernel samepage merging) est votre allié.

La virtualisation d’un Windows

La transformation P2V d’un ordinateur sous Windows est possible, mais elle est beaucoup plus fastidieuse en raison des bugs et incompatibilités de pilotes matériels qui peuvent survenir.

L’idée est la même : je commence par faire du ménage et rassembler toutes les données essentielles sur un disque dur. Il faudra le défragmenter pour ne pas solliciter inutilement le futur système de stockage qui gère plusieurs machines virtuelles.

Une étape très importante et fastidieuse : désinstaller tous les pilotes des périphériques physiques : carte graphique, carte son, chipset central, carte réseau, … Le gestionnaire de périphériques n’affiche pas tous les périphériques par défaut (allez comprendre) et il faut une manipulation pour désactiver ce comportement.

Avant la transformation il faudra également installer les pilotes virtio pour la carte réseau et le disque dur. Ces pilotes virtio sont hébergés sur le site de Fedora puisque Red Hat en est le développeur.

Pour finir, et c’est là la clé du succès, il existe un ensemble de clés de registres appelé mergeide qu’il faut installer sur le Windows avant sa transformation. Sans ce fichier de registre, le poste Windows sera absolument incapable de booter, que vous branchiez un bus IDE, SATA ou virtio pour l’image disque. Voir la description du problème par Microsoft. C’est bien entendu le bus virtio qu’il faut privilégier.

Pour compléter cet article, le wiki de Proxmox est d’une aide précieuse. Proxmox est une distribution Linux orientée virtualisation.

Conclusion

Une fois la transformation réalisée, il n’y a normalement rien qui différencie le serveur virtuel de son précédent état physique. Celui-ci continuera à vivre sa petite vie, car il est tout aussi capable de gérer ses IP sur le réseau, de faire fonctionner ses services et de stocker des données. Pour peu que le serveur hôte soit plus récent de plusieurs générations par rapport au serveur physique, vous gagnerez même en performances.

J’utilise personnellement la transformation P2V pour remplacer ou upgrader un serveur matériel sans interruption de service supérieure à 10 minutes. Le plus souvent, le serveur ainsi virtualisé est utilisé temporairement le temps de transférer ses services ailleurs. Mais pour les serveurs un peu particuliers et dont la configuration est très particulière et très complexe (exemple : serveur email) c’est une méthode « globale » qui permet de tout migrer sans s’arracher les cheveux avec les détails. Peu importe de savoir ce que contient le serveur, quoi que soit son rôle sur le réseau, on peut le virtualiser. Si vous disposez d’une infrastructure de virtualisation, vous pourrez ainsi goûter les joies de la conversion P2V, et sinon, il n’y a plus qu’à trouver un hébergeur de machines virtuelles digne de ce nom.