>Tout savoir sur la paravirtualisation et son rôle en virtualisation_

Un SSD NVMe sur le serveur et la VM est encore plus lente que sur l’ancienne machine avec un disque dur. Le CPU n’est pas saturé, la RAM est disponible. Ce qui se passe, c’est que le contrôleur disque de la VM est resté sur IDE, le mode par défaut dans beaucoup d’hyperviseurs. Chaque lecture ou écriture passe par une émulation logicielle complète avant d’atteindre le stockage. Le NVMe est là, mais la VM ne le voit pas directement. C’est ce problème que les pilotes paravirtualisés résolvent.

Pourquoi la virtualisation bride les performances ?

Dans une VM sans pilotes paravirtualisés, l’hyperviseur doit imiter un matériel physique complet. La VM croit dialoguer avec une vraie carte réseau Intel e1000, un vrai contrôleur IDE ou un vrai adaptateur graphique VGA. L’hyperviseur intercepte chaque instruction que la VM envoie à ce matériel fictif, la traduit, l’exécute sur le matériel, puis renvoie le résultat.

Ce mécanisme fonctionne, mais il est coûteux. Chaque accès disque ou réseau déclenche un changement de contexte entre la VM et l’hyperviseur. Sur des opérations I/O fréquentes, ces interruptions s’accumulent et effacent le gain du matériel sous-jacent.

Émulation classique (trap-and-emulate)

VM (croit écrire sur un disque IDE)
      │  instruction CPU piégée
      ▼
Hyperviseur  ──  traduit + exécute
      │
Vrai matériel (SSD NVMe)

Paravirtualisation (VirtIO / pilotes paravirtualisés)

VM  ──  virtqueue  ──  Hyperviseur  ──  Vrai matériel
         canal direct, pas de trap

L’origine de Xen et la modification du noyau

Au début des années 2000, les processeurs x86 n’avaient pas d’extensions dédiées à la virtualisation. Pour contourner cette limite, le projet Xen a inventé la paravirtualisation en modifiant directement le noyau de l’OS invité pour qu’il sache qu’il tourne dans une VM et qu’il envoie des hypercalls à l’hyperviseur au lieu d’instructions CPU standards.

Linux, étant open source, a pu être adapté. Windows ne pouvait pas l’être. L’arrivée d’Intel VT-x et AMD-V au milieu des années 2000 a résolu ce problème matériellement, il est devenu possible de virtualiser n’importe quel OS sans modifier son noyau. La paravirtualisation totale du noyau est devenue obsolète.

Ce qui est resté, ce sont les pilotes paravirtualisés pour les I/O. Pas besoin de modifier le noyau entier, juste installer un pilote disque ou réseau qui sait parler directement à l’hyperviseur.

VirtIO : le standard ouvert pour KVM et Proxmox

VirtIO est le standard de pilotes paravirtualisés utilisé par KVM, QEMU et Proxmox. Au lieu d’émuler un périphérique physique, VirtIO expose à la VM une interface simplifiée qui communique directement avec l’hyperviseur via des virtqueues.

Une virtqueue est un anneau circulaire en mémoire partagée entre la VM et l’hyperviseur. La VM dépose ses requêtes I/O dans cet anneau, l’hyperviseur les lit et les exécute, sans passer par le cycle trap-and-emulate. Le gain est mesurable. En réseau, VirtIO atteint 2 à 3 fois les débits d’une carte e1000 émulée à charge équivalente.

Mécanisme VirtIO (virtqueue)

VM (pilote VirtIO frontend)
      │
      ▼  dépose requêtes dans l'anneau circulaire (mémoire partagée)
      │
Hyperviseur (pilote VirtIO backend)
      │
      ▼
Matériel physique

VirtIO couvre plusieurs types de périphériques. virtio-net pour le réseau, virtio-blk et virtio-scsi pour le stockage, virtio-balloon pour la mémoire, virtio-gpu pour l’affichage. Chacun remplace un périphérique émulé par un canal direct.

vhost : aller encore plus loin pour le réseau

Par défaut, le backend VirtIO réseau tourne dans le processus QEMU en espace utilisateur. Chaque paquet franchit donc la frontière entre espace noyau et espace utilisateur, ce qui ajoute de la latence.

vhost déplace ce backend directement dans le noyau Linux. Le paquet réseau passe de la VM au noyau hôte sans traverser QEMU. Sur des VM à haut débit réseau ou faible latence, la différence est notable. Proxmox active vhost par défaut sur les interfaces virtio-net.

Le balloon driver : paravirtualisation de la mémoire

VirtIO ne s’arrête pas aux I/O disque et réseau. Le balloon driver (virtio-balloon) est un pilote paravirtualisé qui gère la mémoire RAM de façon dynamique entre les VM.

Quand l’hyperviseur a besoin de récupérer de la RAM pour une autre VM, il demande au balloon driver de la VM concernée de réclamer de la mémoire inutilisée au sein de la VM et de la rendre à l’hyperviseur. La VM voit sa RAM disponible diminuer, l’hyperviseur la redistribue ailleurs. Quand la pression diminue, le balloon se dégonfle et la RAM est rendue.

C’est ce mécanisme qui explique pourquoi une VM peut afficher 2 Go utilisés dans le gestionnaire de tâches alors que l’hyperviseur lui en a alloué 8. Le balloon driver a récupéré 6 Go au profit d’autres VM.

Les pilotes paravirtualisés selon votre hyperviseur

Le principe est le même partout. Chaque hyperviseur a son implémentation de pilotes paravirtualisés à installer dans la VM.

VMware Tools et open-vm-tools : lequel installer sur Linux

VMware Tools est le paquet d’intégration VMware pour les VM invitées. Il installe les pilotes PVSCSI et VMXNET3, synchronise l’horloge, active le copier-coller hôte-VM et permet les snapshots cohérents.

Comment installer VMware Tools sur Ubuntu ? (méthode officielle)

Linux3 minassistouest.fr

Installer VMware Tools sur Ubuntu n’a jamais été aussi simple : apprenez à configurer open-vm-tools pour une expérience fluide avec VMware Workstation, Player ou ESXi.

Sur Linux, VMware recommande depuis vSphere 5.5 (2013) d’utiliser open-vm-tools à la place du paquet .tar.gz propriétaire. open-vm-tools est la version open source, intégrée aux dépôts des distributions majeures (Ubuntu, Debian, RHEL). Sur Ubuntu, un simple apt install open-vm-tools suffit. Le paquet .tar.gz téléchargé depuis vCenter est réservé aux distributions non officiellement supportées.

Les pilotes Hyper-V sur Linux

Les pilotes d’intégration Hyper-V pour Linux sont intégrés directement dans le noyau Linux depuis la version 3.4. Sur une VM Linux sous Hyper-V, les modules hv_vmbus, hv_storvsc et hv_netvsc s’activent automatiquement si le noyau est récent. Aucune installation manuelle n’est nécessaire sur Ubuntu 22.04+ ou Debian 11+.

Sans ces modules, Linux utilise les périphériques émulés Hyper-V (IDE, e1000) au lieu du canal VMbus direct. La différence de performances réseau et disque est significative. Pour comprendre l’architecture VMbus et la partition parente Hyper-V, voir Hyper-V et son classement type 1.

Installer les pilotes VirtIO sur une VM Windows sous Proxmox

Windows ne contient pas les pilotes VirtIO nativement. Si vous créez une VM Windows sur Proxmox avec un contrôleur virtio-scsi, Windows ne détecte pas le disque pendant l’installation et l’assistant bloque.

La solution est de monter l’ISO des pilotes VirtIO comme second lecteur CD-ROM pendant l’installation. L’ISO est maintenue par le projet Fedora/Red Hat et téléchargeable depuis le wiki Proxmox.

Pendant l’installation Windows, au moment où l’assistant ne détecte aucun disque, cliquez sur « Charger un pilote », pointez vers le lecteur CD-ROM de l’ISO VirtIO, choisissez le dossier correspondant à votre version de Windows (w11, w10, 2k22…) et installez le pilote SCSI. Le disque apparaît immédiatement.

Une fois Windows installé, montez à nouveau l’ISO et exécutez virtio-win-guest-tools.exe pour installer tous les pilotes restants (réseau, balloon, serial, guest agent).

# Installer qemu-guest-agent sur Linux (Debian/Ubuntu)
apt install qemu-guest-agent
systemctl enable --now qemu-guest-agent

Le qemu-guest-agent permet à Proxmox de prendre des snapshots cohérents (freeze du filesystem avant snapshot), de récupérer l’adresse IP de la VM depuis l’interface Proxmox, et d’envoyer des signaux d’extinction propres à la VM.

Choisir entre hyperviseurs et pilotes selon votre usage

Sur Proxmox ou KVM, activer VirtIO sur le disque et le réseau est la première chose à faire après la création de la VM. Pour Linux, les pilotes sont intégrés au noyau. Pour Windows, monter l’ISO VirtIO-win pendant l’installation. Installer le qemu-guest-agent dans tous les cas.

Sur VMware ESXi, installer open-vm-tools sur les VM Linux (via le gestionnaire de paquets) et VMware Tools sur les VM Windows (via vCenter ou l’ISO VMware Tools). PVSCSI et VMXNET3 s’activent via le profil matériel de la VM dans vCenter.

Sur VirtualBox, installer les Guest Additions depuis le menu Périphériques de la fenêtre VM. Sans elles, la résolution d’écran reste bloquée, le copier-coller ne fonctionne pas et les dossiers partagés sont inaccessibles.

Pour choisir le bon hyperviseur selon votre usage avant de vous poser la question des pilotes, voir la différence entre hyperviseur de type 1 et type 2.

La paravirtualisation necessite que la virtualisation materielle soit activee au niveau du BIOS. Notre guide activer VT-x ou AMD-V dans le BIOS couvre les configurations par marque. Pour l’installation pratique de macOS en VM sous Windows, voir installer macOS avec VMware.