Virtualisation à domicile : quelles fonctionnalités CPU importent vraiment

décembre 21, 2025 • février 3, 2026 • Lecture : 33 min • Views: 0

Cet article vous a aidé ?

Vos machines virtuelles semblent « lentes », alors vous commencez à acheter des CPU comme si c’était une question religieuse. Pourtant, le véritable responsable est souvent un groupe IOMMU manquant, un réglage du BIOS, un mauvais gouverneur CPU, ou un hôte qui assigne les interruptions sur le même cœur où vous avez épinglé votre VM « sensible à la latence ». Bienvenue dans la virtualisation à domicile : l’endroit où le maillon le plus faible est toujours celui auquel vous n’avez pas pensé.

Ceci est le point de vue pratique et orienté production sur les fonctionnalités CPU qui comptent vraiment pour exécuter KVM/Proxmox, ESXi, Hyper-V, bhyve ou Xen à la maison. Pas des listes marketing. Pas des superstitions de forum. Des fonctionnalités, des modes de défaillance et comment prouver ce que vous avez avec des commandes.

Ce qui compte réellement (et ce qui ne compte pas)

Si vous construisez ou mettez à jour une machine de virtualisation à domicile, le choix du CPU tient d’abord à la capacité, ensuite à la cohérence, et enfin à la vitesse brute. La plupart des labos domestiques ne tombent pas en panne parce qu’ils manquent 5 % de performance mono‑thread. Ils échouent parce qu’une fonctionnalité « prise en charge » n’est pas réellement disponible, ou qu’elle se comporte mal sous charge.

Fonctionnalités CPU indispensables

Virtualisation matérielle : Intel VT-x ou AMD-V. Sans cela, les hyperviseurs modernes ne fonctionneront pas ou fonctionneront comme en 2006.
Traduction d’adresses de second niveau : Intel EPT ou AMD NPT (Nested Paging). C’est la différence entre « les VM semblent natives » et « les VM semblent être une punition ».
IOMMU : Intel VT-d ou AMD-Vi. Nécessaire pour un vrai PCI passthrough (GPU, HBA, NIC) et utile pour l’isolation même sans passthrough.
Firmware raisonnable : BIOS/UEFI qui expose les fonctionnalités de façon fiable et n’a pas de réglages par défaut étranges.

Fonctionnalités CPU qui importent selon la charge

AES-NI / VAES : si vous utilisez du stockage chiffré (chiffrement natif ZFS, LUKS), des VPN ou des services TLS intensifs, cela peut changer la donne.
AVX2/AVX-512 : utile pour des charges spécifiques (transcodage média, certaines bases de données/analyses). Peut aussi réduire les fréquences Turbo ou augmenter la consommation. Des compromis existent.
TSX, RDT, etc. : jouets de réglage entreprise. Parfois utiles, souvent sans intérêt à la maison.

Fonctionnalités CPU dont on s’obsède trop

« Plus de cœurs, c’est toujours mieux » : jusqu’à ce que vous saturiez la bande passante mémoire, le cache L3 ou la capacité de l’hôte à planifier les interruptions.
« Il suffit de passer le GPU en passthrough » : génial quand ça marche. Cauchemar de support quand les groupes IOMMU sont collés par la conception de la carte mère.
« ECC ou rien » : l’ECC est une bonne pratique d’ingénierie, mais ce n’est pas la seule chose qui vous protège du chaos. (Ce n’est pas non plus une fonctionnalité CPU ; c’est une fonctionnalité plateforme.)

Une dure vérité : la virtualisation consiste moins à « faire tourner plusieurs OS » et plus à « faire en sorte que la mémoire et l’I/O se comportent correctement sous contention ». Les fonctionnalités CPU qui améliorent la virtualisation de la mémoire et l’isolation des périphériques sont celles qui font réellement la différence.

Faits intéressants et contexte historique

Parce que le contexte évite des erreurs coûteuses, voici quelques points concrets qui expliquent pourquoi ces fonctionnalités existent et pourquoi votre hyperviseur s’en soucie :

La traduction binaire a vraiment existé. Avant la maturité de VT-x/AMD-V, les hyperviseurs utilisaient des astuces pour réécrire les instructions privilégiées. Ça fonctionnait, mais c’était complexe et plus lent sous certaines charges.
EPT/NPT a changé la donne plus que VT-x/AMD-V. Une « virtualisation matérielle » précoce sans bonne traduction de second niveau conservait un lourd overhead à cause des shadow page tables.
IOMMU n’a pas été conçu pour les gamers. Il vient des besoins d’entreprise : isolation DMA, attribution de périphériques plus sûre, et moyen d’empêcher un périphérique d’écraser la mémoire d’un autre.
Les VM exits sont le percepteur. À chaque fois qu’une VM doit sauter vers l’hyperviseur pour une opération privilégiée, vous payez. Les CPU modernes ajoutent des fonctions pour réduire les exits.
La virtualisation imbriquée était mauvaise autrefois. Exécuter un hyperviseur à l’intérieur d’une VM (pour CI, labs ou « juste pour voir ») était pénible jusqu’à ce que les CPU s’améliorent et que les hyperviseurs apprennent à coopérer.
Meltdown/Spectre ont changé les hypothèses de performance de base. Les atténuations ont augmenté l’overhead pour certaines opérations noyau/hyperviseur; certaines générations de CPU ont été plus affectées.
SR-IOV est le cousin du passthrough. Plutôt que de donner une NIC entière à une VM, vous la divisez en fonctions virtuelles. Super quand c’est pris en charge ; sans intérêt si votre NIC ne le fait pas.
Intel et AMD utilisent des noms différents pour des idées similaires. VT-x vs AMD-V, EPT vs NPT, VT-d vs AMD-Vi. Le but est le même : réduire le travail de l’hyperviseur.

Extensions matérielles de virtualisation : l’essentiel

Démystifions le minimum requis.

VT-x / AMD-V : nécessaire, pas suffisant

Les extensions de virtualisation matérielle permettent au CPU d’exécuter le code invité dans un mode spécial et de faire trapper les opérations sensibles vers l’hyperviseur en toute sécurité. La plupart des CPU modernes les possèdent. Le piège est de supposer que « a VT-x » signifie « bon CPU pour virtualisation ». C’est comme supposer que « a des roues » signifie « voiture de course ».

Ce qui vous importe :

Stabilité sous charge : la qualité du firmware et la maturité du microcode comptent.
Complétude des fonctionnalités : EPT/NPT, virtualisation des interruptions, posted interrupts, etc.
Support dans votre hyperviseur : une fonctionnalité présente dans le silicium ne garantit pas que votre plateforme l’utilise bien.

Blague n°1 : Acheter un CPU pour la virtualisation parce qu’il a « VT-x » revient à acheter une voiture parce qu’elle a « un volant ». Techniquement correct. Pratiquement inutile.

Virtualisation imbriquée : si vous en avez besoin, planifiez-la

La virtualisation imbriquée est courante dans les entreprises réelles pour les pipelines CI, les environnements de labo et les tests d’automatisation d’hyperviseur. À la maison c’est niche, mais si vous exécutez Kubernetes dans des VMs qui lancent d’autres VMs (vous vous reconnaîtrez), vous voulez le support CPU+hyperviseur pour la virtualisation imbriquée et vous devez la tester tôt.

IOMMU/VT-d/AMD-Vi : passthrough et isolation

Si vous voulez le passthrough GPU, le passthrough HBA, ou « mon VM routeur a sa propre NIC », vous entrez dans le domaine de l’IOMMU. C’est là que les constructions domestiques réussissent ou échouent en fonction des particularités de la plateforme plutôt que du modèle de CPU.

Ce que fait réellement l’IOMMU

L’IOMMU est au DMA ce que l’MMU est aux accès mémoire CPU. Il permet au système de contrôler quelles adresses mémoire un périphérique peut lire/écrire via DMA. Sans lui, attribuer un périphérique à une VM est dangereux parce que le périphérique pourrait DMA dans la mémoire de l’hôte. Avec lui, vous pouvez mapper les adresses visibles par le périphérique vers la mémoire invitée en toute sécurité.

Le problème des groupes IOMMU

Le passthrough n’est pas « est-ce que je peux activer VT-d ». C’est « est-ce que les périphériques dont j’ai besoin sont isolés dans des groupes IOMMU exploitables ». Les cartes mères câblent parfois plusieurs périphériques derrière le même root complex PCIe sans séparation ACS (Access Control Services) adéquate. Résultat : votre GPU est dans le même groupe qu’un contrôleur SATA dont l’hôte a besoin. Bon choix.

Distribution des interruptions et latence

Même avec IOMMU, les performances dépendent de la façon dont les interruptions sont gérées. Les systèmes modernes peuvent faire du remapping d’interruptions, et les hyperviseurs peuvent utiliser des fonctionnalités comme les posted interrupts pour réduire les VM exits. C’est important pour le réseau à haut débit de paquets et le stockage basse latence.

Position opérationnelle : si le passthrough est une exigence centrale, achetez une plateforme connue pour bien se comporter. La marque du CPU compte moins que le comportement de la carte mère et du chipset.

EPT/NPT, TLBs, et pourquoi la virtualisation de la mémoire est le vrai enjeu

Quand quelqu’un parle d’« overhead de virtualisation », il veut généralement dire « quelque chose à propos du CPU ». La vérité : la plus grosse douleur historique était la traduction mémoire et le churn qu’elle provoque dans les caches et les TLBs.

Traduction d’adresses de second niveau (SLAT)

Intel EPT et AMD NPT permettent au CPU de traduire les adresses virtuelles invitées vers des adresses physiques invitées, puis vers des adresses physiques hôtes, avec assistance matérielle. Sans cela, l’hyperviseur maintient des shadow page tables, et chaque mise à jour de table de pages invitée devient un travail coûteux. SLAT supprime une grande partie de cet overhead.

TLB, tailles de pages et pourquoi les hugepages aident parfois

Les Translation Lookaside Buffers (TLB) mettent en cache les traductions d’adresses. La virtualisation ajoute une couche supplémentaire, donc la pression sur les TLB peut augmenter. Les hugepages (2MB, 1GB selon) peuvent réduire les manques de TLB pour les VM gourmandes en mémoire, mais elles peuvent aussi augmenter la fragmentation ou compliquer la surallocation de mémoire. C’est un outil, pas une religion.

Surallocation : la falaise des performances

Les labos domestiques aiment la surallocation parce que la RAM coûte cher et l’optimisme est gratuit. Les fonctionnalités CPU ne vous sauveront pas si l’hôte commence à swapper. Une fois que vous voyez du swap-in/swap-out sous charge VM, votre « problème de performance CPU » est en réalité un problème de capacité mémoire et de comportement.

Cœurs vs fréquences vs cache : choisir la morphologie du CPU

Le choix du CPU n’est pas seulement « quelle vitesse ». C’est « comment il se comporte quand 12 choses veulent du service en même temps ». Les hyperviseurs amplifient les mauvais compromis parce qu’ils multiplexent tout.

Cœurs : concurrence et marge de planification

Plus de cœurs signifie plus de threads exécutable qui peuvent progresser sans attendre. C’est excellent pour de nombreux petits services, des charges CI, et « j’exécute tout dans des VMs séparées parce que c’est plus propre ». Mais plus de cœurs peut aussi entraîner :

Une fréquence Turbo maximale réduite sur tous les cœurs sous charge soutenue
Moins de cache par cœur (selon le SKU)
Un comportement NUMA plus complexe sur multi-socket (moins courant à la maison)

Fréquences : latence et performance de queue

La performance mono‑thread compte toujours pour :

PFSense/OPNsense sur certains chemins de paquets
Serveurs de jeu
Certains chemins de stockage (checksum, compression, chiffrement) selon la configuration
Toute charge avec un chemin critique sérialisé

Dans des charges mixtes, la latence queue est le tueur. Un CPU qui booste haut sur quelques cœurs tout en gardant les autres occupés peut sembler meilleur qu’une puce « plus de cœurs, boost inférieur », même si le score de benchmark dit le contraire.

Cache : la fonctionnalité invisible

Le cache L3 est le MVP discret pour la densité de virtualisation. Beaucoup de VMs signifie beaucoup d’ensembles de travail. Les défauts de cache entraînent du trafic mémoire ; le trafic mémoire entraîne de la contention ; la contention rend tout instable et « aléatoire ».

Règle empirique : si vous exécutez beaucoup de services avec une utilisation CPU modérée (typique d’un labo domestique), privilégiez des CPU avec un bon L3 et un comportement stable en charge plutôt que le pic de boost marketing.

AES, AVX et jeux d’instructions qui changent la donne

AES-NI (et apparentés) : si vous chiffrez quelque chose, vous vous en souciez

AES-NI accélère les opérations cryptographiques courantes. Si vous exécutez :

ZFS native encryption
LUKS/dm-crypt
Tunnels VPN (WireGuard dépend plus des opérations de courbe ; IPsec/OpenVPN peuvent s’appuyer sur AES)
Beaucoup de terminaison TLS (reverse proxies, PKI interne, service meshes)

…alors AES-NI peut transformer un « chiffrement lié au CPU » en « I/O-bound normal ». Cela réduit aussi la gigue : le chiffrement sans accélération peut voler du CPU au pire moment possible.

AVX2/AVX-512 : performance avec des mises en garde

AVX peut fortement accélérer certaines charges de calcul. Il peut aussi :

Augmenter la consommation d’énergie
Déclencher des fréquences CPU plus basses sur certaines puces sous charges AVX soutenues
Provoquer des mystères du type « pourquoi l’hôte est plus lent quand cette VM tourne »

Dans un environnement domestique où une VM peut monopoliser l’hôte, les tâches lourdes en AVX peuvent être un voisin bruyant. Il ne faut pas craindre AVX. Il faut le comprendre et l’isoler si nécessaire (pinning CPU, quotas, hôte séparé).

CRC32, carryless multiply et le mythe du « CPU stockage »

Les piles de stockage utilisent diverses instructions CPU pour les checksums et la compression. ZFS, par exemple, bénéficie d’un CPU solide pour checksumming et compression, mais la plupart des constructions domestiques sont limitées par les disques ou les NIC avant le CPU. L’exception est quand vous activez une compression coûteuse, un chiffrement lourd, ou que vous travaillez en 10/25GbE avec des SSD rapides. Alors le CPU devient le moteur de stockage.

Topologie, SMT, NUMA et les petits délits de l’ordonnanceur

Le CPU n’est pas une piscine plate de cœurs identiques. Les systèmes modernes ont SMT (Hyper-Threading), caches partagés, chiplets, et parfois des cœurs hétérogènes. Les hyperviseurs et les ordonnanceurs hôtes font de leur mieux. Ils vous mentent aussi poliment.

SMT : plus de débit, parfois pire pour la latence

SMT peut augmenter le débit pour des charges mixtes. Mais si vous épinglez les vCPU un-à-un avec les pCPU et oubliez SMT, vous pouvez finir par épingler deux vCPU bruyants sur des threads sœurs du même cœur physique. C’est comme ça que vous obtenez « la VM a des cœurs dédiés mais elle subit des saccades ».

NUMA : surtout un problème serveur, jusqu’à ce que ce ne le soit plus

Sur les plateformes grand public mono-socket, les effets NUMA existent mais sont moins dramatiques. Sur des systèmes multi-socket ou des stations de travail à fort nombre de cœurs, un mauvais placement NUMA peut doubler la latence mémoire d’une VM. Si vous achetez un serveur dual-socket d’occasion parce qu’il était bon marché et bruyant (et il le sera), apprenez les bases NUMA ou acceptez que certaines VMs auront des performances mystérieuses.

Gestion d’alimentation : le saboteur silencieux

Le scaling de fréquence est excellent pour les laptops. Sur un hôte de VM, « powersave » peut ressembler à des pics de latence aléatoires. Les modes équilibrés peuvent convenir, mais vous devriez vérifier ce que fait réellement l’hôte. Si votre hôte hyperviseur est censé être un petit serveur, traitez-le comme tel.

Blague n°2 : Le gouverneur « powersave » sur un hôte VM, c’est comme mettre votre base de données en retraite yoga. Elle trouvera sa paix intérieure au moment où vous aurez besoin de réponses.

Atténuations de sécurité : impôt sur les performances avec factures

Spectre, Meltdown, L1TF, MDS, SSB, Retbleed — choisissez votre acronyme. Les atténuations affectent souvent l’overhead des appels système, les changements de contexte et les chemins de virtualisation.

Conseils opérationnels :

N’éteignez pas les atténuations à la légère. Les labos domestiques se font encore compromettre. Votre VM routeur et votre VM NAS ne sont pas des cas particuliers.
Connaissez la génération de votre CPU. Certaines générations souffrent plus de certaines atténuations.
Mesurez avant/après. Les atténuations ne sont pas universellement « lentes ». Certaines charges à peine les remarquent.

Une idée paraphrasée d’une légende des opérations : « L’espoir n’est pas une stratégie. » — idée paraphrasée attribuée à Gene Kranz (discipline des opérations de mission). En termes de virtualisation : ne comptez pas sur une fonctionnalité ; vérifiez-la sur votre matériel et firmware exacts.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les vérifications que je fais réellement quand je diagnostique un hôte, que je valide un achat ou que je confirme un changement de BIOS. Chaque tâche comprend : une commande, ce que signifie une sortie typique, et la décision à prendre.

Task 1: Confirm CPU virtualization flags (VT-x/AMD-V)

cr0x@server:~$ lscpu | egrep -i 'Virtualization|Model name|CPU\(s\)'
CPU(s):                               16
Model name:                           Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz
Virtualization:                       VT-x

Signification : « Virtualization: VT-x » indique que le noyau voit le support de virtualisation matérielle.

Décision : Si ceci manque (ou est vide), vérifiez les paramètres BIOS/UEFI pour Intel VT-x/AMD SVM. Si toujours absent, votre CPU/plateforme peut ne pas le supporter ou il est verrouillé.

Task 2: Confirm EPT/NPT (second-level translation)

cr0x@server:~$ grep -Eo 'vmx|svm|ept|npt' /proc/cpuinfo | sort | uniq -c
     16 ept
     16 vmx

Signification : La présence de ept (Intel) ou npt (AMD) indique le support SLAT, critique pour les performances.

Décision : Si vous avez VT-x/AMD-V mais pas EPT/NPT, considérez ce CPU comme un mauvais choix pour des charges de virtualisation modernes.

Task 3: Verify KVM modules are loaded and usable

cr0x@server:~$ lsmod | egrep 'kvm|kvm_intel|kvm_amd'
kvm_intel             372736  0
kvm                  1032192  1 kvm_intel
irqbypass              16384  1 kvm

Signification : KVM est actif ; irqbypass apparaît souvent dans les contextes de virtualisation.

Décision : Si les modules KVM ne se chargent pas, vérifiez les paramètres de virtualisation dans le BIOS et dmesg pour des messages « disabled by bios ».

Task 4: Check if IOMMU is enabled in the kernel

cr0x@server:~$ dmesg | egrep -i 'iommu|dmari|amd-vi' | head -n 8
[    0.842311] DMAR: IOMMU enabled
[    0.842451] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    0.924113] DMAR: Interrupt remapping enabled

Signification : L’IOMMU est activée ; le remapping d’interruptions est un bon signe pour un passthrough plus sûr.

Décision : Si vous ne voyez pas « IOMMU enabled », vous devrez probablement activer VT-d/AMD-Vi dans le BIOS et ajouter des paramètres kernel (par ex. intel_iommu=on ou amd_iommu=on).

Task 5: Confirm kernel cmdline includes IOMMU options

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.5.0 root=UUID=... ro quiet intel_iommu=on iommu=pt

Signification : intel_iommu=on active l’IOMMU ; iommu=pt améliore souvent les performances de l’hôte en utilisant des mappings passthrough pour les périphériques hôtes.

Décision : Si le passthrough est requis, ajoutez les bons flags et reconstruisez la configuration du bootloader. Si vous n’avez pas besoin de passthrough, vous pouvez activer l’IOMMU pour l’isolation mais mesurez les régressions potentielles.

Task 6: Inspect IOMMU groups (passthrough feasibility)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}:"; lspci -nns $(ls "$g/devices" | sed 's/^/0000:/'); echo; done | head -n 30
IOMMU Group 0:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e30]

IOMMU Group 1:
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901]

IOMMU Group 2:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1f82]
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10fa]

Signification : Les périphériques dans le même groupe ne peuvent pas être séparés en toute sécurité sans ACS. Qu’un GPU soit groupé avec sa fonction audio est normal et exploitable.

Décision : Si votre périphérique cible partage un groupe avec quelque chose dont l’hôte a besoin (contrôleur USB, contrôleur SATA), changez de slot, de carte mère, ou acceptez que le passthrough soit impossible.

Task 7: Validate that the hypervisor can expose CPU features to guests

cr0x@server:~$ virsh capabilities | egrep -n 'model|feature' | head -n 12
32:      Skylake-Client
41:      
44:

Signification : libvirt voit des modèles CPU et des fonctionnalités qu’il peut présenter aux VMs.

Décision : Pour des VMs sensibles aux performances, préférez le mode CPU « host-passthrough » (si la migration n’est pas requise). Pour des clusters mixtes, utilisez un modèle CPU de base stable.

Task 8: Check current CPU frequency governor (latency spikes often live here)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Signification : L’hôte privilégie les économies d’énergie, ce qui peut introduire de la latence et de la lenteur.

Décision : Envisagez de passer en performance sur un hôte dédié aux VMs, surtout si vous observez de la gigue. Mesurez la consommation et les températures.

Task 9: Switch governor to performance (temporary) and verify

cr0x@server:~$ sudo apt-get install -y linux-cpupower
Reading package lists... Done
...
cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
...
cr0x@server:~$ cpupower frequency-info | egrep -i 'governor|current policy' | head -n 6
current policy: frequency should be within 800 MHz and 4.70 GHz.
                  The governor "performance" may decide which speed to use

Signification : Le gouverneur a changé ; la plage de politique est affichée.

Décision : Si la latence des VMs s’améliore, rendez le changement persistant via les outils de gestion d’énergie de votre distribution.

Task 10: Check for host swapping (often misdiagnosed as “CPU weak”)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        26Gi       1.2Gi       3.1Gi       3.8Gi       1.6Gi
Swap:           16Gi       6.5Gi       9.5Gi

Signification : Une utilisation active du swap sous charge est un signal d’alerte pour les performances VM et la réactivité de l’hôte.

Décision : Réduisez la surallocation mémoire, ajoutez de la RAM, ajustez la politique de ballooning des VMs, ou déplacez les services gourmands en mémoire. Les améliorations CPU ne régleront pas le swap.

Task 11: Identify CPU steal time inside a VM (host contention)

cr0x@server:~$ mpstat 1 5
Linux 6.5.0 (vm01) 	01/12/2026 	_x86_64_	(4 CPU)

12:01:02 PM  all   %usr   %nice    %sys %iowait   %irq  %soft  %steal  %idle
12:01:03 PM  all   12.00    0.00    4.00    0.00   0.00   1.00   18.00  65.00

Signification : %steal indique que la VM voulait du temps CPU mais que l’hôte ne l’a pas planifiée. C’est de la contention, pas « Linux lent ».

Décision : Réduisez la surallocation, épinglez les vCPU, réservez du CPU pour les VMs critiques, ou augmentez le nombre de cœurs. Cherchez également une VM voisine bruyante.

Task 12: Spot interrupt hot spots (NIC/storage bottlenecks disguised as CPU)

cr0x@server:~$ cat /proc/interrupts | head -n 12
           CPU0       CPU1       CPU2       CPU3
  24:    987654          0          0          0  IR-PCI-MSI  327680-edge      nvme0q0
  25:          0     876543          0          0  IR-PCI-MSI  327681-edge      nvme0q1
  34:   4321098          0          0          0  IR-PCI-MSI  524288-edge      enp3s0-rx-0

Signification : Un CPU traitant la plupart des interruptions pour un périphérique très trafic peut créer de la latence et réduire le débit VM.

Décision : Assurez-vous que irqbalance tourne (ou épinglez les interruptions intentionnellement), répartissez les queues sur les CPU, et évitez d’épingler des VMs critiques sur le cœur saturé par les interruptions.

Task 13: Verify microcode is applied (stability and mitigations)

cr0x@server:~$ dmesg | egrep -i 'microcode' | tail -n 5
[    0.321987] microcode: microcode updated early to revision 0x000000f0, date = 2023-09-12

Signification : Les mises à jour microcode peuvent corriger des errata, améliorer la stabilité et affecter le comportement des atténuations.

Décision : Maintenez les paquets microcode à jour. Si vous voyez des fautes de virtualisation étranges, confirmez que vous n’exécutez pas un microcode ancien.

Task 14: Check mitigation status (performance expectations)

cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head -n 10
/sys/devices/system/cpu/vulnerabilities/meltdown: Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1: Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Retpolines; IBPB: conditional; IBRS: disabled; STIBP: conditional; RSB filling

Signification : Le noyau vous indique quelles atténuations sont actives. Certaines impactent plus les performances VM que d’autres.

Décision : Si une régression de benchmark apparaît après des mises à jour, consultez cette sortie. Ne devinez pas. Décidez d’accepter l’impôt ou de revoir l’architecture (par ex., moins de VM exits, meilleur I/O, génération CPU différente).

Task 15: Measure per-VM CPU model and flags (QEMU/KVM example)

cr0x@server:~$ sudo virsh dumpxml vm01 | egrep -n 'cpu mode|model|feature' | head -n 20
57:

Signification : host-passthrough expose les fonctionnalités du CPU hôte à l’invité, maximisant généralement les performances.

Décision : Si vous avez besoin de migration à chaud entre CPU différents, n’utilisez pas host-passthrough ; utilisez un modèle CPU compatible. Si vous ne migrez pas, host-passthrough est souvent le bon choix.

Playbook de diagnostic rapide

Quand « les VMs sont lentes », ne commencez pas par lire des pages marketing CPU. Commencez par trouver le goulet d’étranglement avec un triage impitoyable.

Première étape : déterminer s’il s’agit de planification CPU, pression mémoire ou I/O

Charge et file d’attente d’exécution de l’hôte : l’hôte est-il saturé CPU ou simplement « occupé » ?
Activité de swap : si du swap a lieu, arrêtez. Réglez la mémoire d’abord.
I/O wait : si iowait est élevé, les fonctionnalités CPU ne sont pas votre facteur limitant.

Deuxième étape : vérifiez les compteurs spécifiques à la virtualisation

Temps de steal VM : dans l’invité, cherchez %steal.
VM exits (indirectement) : vérifiez si une charge provoque des syscalls excessifs, des interruptions ou de l’émulation (par ex., mauvaise configuration virtio).
Répartition des interruptions : les IRQ chauds sur un seul cœur peuvent ressembler à une lenteur « aléatoire ».

Troisième étape : validez le firmware et les bascules de fonctionnalités

VT-x/AMD-V activé
VT-d/AMD-Vi activé
SR-IOV activé (si nécessaire)
BIOs et microcode à jour
Mode de gestion d’énergie raisonnable pour un hôte

Quatrième étape : décidez si vous avez besoin d’un nouveau CPU ou d’un nouveau plan

Si swap se produit : achetez de la RAM ou réduisez la surallocation.
Si iowait domine : corrigez le stockage/le réseau (queues, pilotes, choix de périphérique).
Si steal time est élevé : ajoutez des cœurs, réduisez la consolidation ou isolez les VMs bruyantes.
Si le passthrough échoue : vous aurez probablement besoin d’une carte mère différente plus qu’un CPU différent.

Trois mini-histoires d’entreprise issues du terrain

Incident causé par une mauvaise hypothèse : « VT-d est activé, donc le passthrough fonctionnera. »

Une petite équipe d’infrastructure a standardisé une plateforme workstation compacte pour un bureau distant. Le but : quelques VMs plus le passthrough GPU pour une charge Windows qui nécessitait une vraie accélération graphique. Ils ont vérifié le CPU : virtualisation prise en charge, VT-d pris en charge. Fin de l’histoire, non ?

Ils ont construit la première unité, installé l’hyperviseur, activé VT-d dans le BIOS, et fait les contrôles habituels IOMMU. L’IOMMU était activée. Tout le monde s’est détendu. Puis ils ont essayé d’assigner le GPU à la VM et se sont heurtés à un mur : le GPU était dans le même groupe IOMMU qu’un contrôleur USB et un bridge PCIe qui hébergeait aussi un périphérique embarqué critique. Assigner tout le groupe aurait signifié arracher du matériel à l’hôte. Pas drôle quand l’hôte a besoin de ce contrôleur pour démarrer.

La première réaction de l’équipe fut de « réparer Linux ». Ils ont essayé des patchs ACS override. Ça a partiellement fonctionné jusqu’à ce que non — resets aléatoires sous charge et fautes DMA occasionnelles qui semblaient être des problèmes de pilote. Ce n’était pas un problème de pilote. C’était la topologie PCIe de la plateforme et de faibles frontières d’isolation.

Ils ont fini par changer la carte mère pour une autre avec un câblage PCIe meilleur et un comportement ACS correct. Même CPU. Même GPU. Soudain tout s’est bien comporté. La leçon n’était pas « le passthrough est difficile ». La leçon : le support des fonctionnalités CPU est nécessaire, mais c’est la carte mère qui cache les cadavres.

Optimisation qui a mal tourné : « Épinglons tout pour les performances. »

Une autre équipe gérait un cluster de virtualisation avec un mélange de services web, de logging et quelques VMs sensibles à la latence. Un ingénieur a décidé d’être sérieux : pinning CPU, isolcpus, profils tuned, tout le tralala. Sur le papier c’était magnifique — cœurs dédiés pour les VMs importantes, moins de context switches, plus de déterminisme.

En pratique, les performances se sont dégradées. Les VMs sensibles à la latence se bloquaient occasionnellement, et la charge softirq de l’hôte a grimpé. L’ingénieur avait épinglé les vCPU soigneusement, mais avait oublié que les interruptions et les threads noyau ont aussi besoin de CPU. Pire encore, une queue NIC très chargée et une queue d’interruption NVMe ont fini par viser les mêmes cœurs « isolés » en raison de l’affinité IRQ par défaut.

Le résultat fut classique : la VM avait un « CPU dédié », mais ce CPU était occupé à traiter des interruptions et l’entretien de l’hôte. Le pinning a réduit la capacité de l’ordonnanceur à lisser la charge, donc les pics sont devenus plus prononcés. Les utilisateurs l’ont remarqué. Grafana est devenu une anthologie d’horreur.

Ils ont réparé ça en reculant sur le pinning agressif, en définissant explicitement les affinités IRQ, et en réservant quelques cœurs pour l’hôte. L’effet net n’était pas aussi « propre » que le diagramme, mais il était stable. L’optimisation des performances est une négociation avec la réalité ; la réalité ne lit pas votre runbook.

Pratique ennuyeuse mais correcte qui a sauvé la mise : modèles CPU de base et contrôle des changements

Une entreprise de taille moyenne gérait un environnement de virtualisation où la migration à chaud était importante. Ils avaient un mélange de générations CPU parce que le renouvellement matériel se fait par vagues, pas en un seul événement sacré. Très tôt, ils ont appris que le mode CPU « host-passthrough » est fantastique jusqu’à ce que vous ayez besoin de migrer une VM vers un hôte avec un jeu de fonctionnalités CPU légèrement différent.

Ils ont donc fait une chose ennuyeuse : standardiser les modèles CPU des VMs sur une base conservatrice et documenter les flags CPU requis. Ils ont aussi maintenu une checklist de pré‑mise à jour : paramètres BIOS, versions de microcode, et une « canary VM » qui exécutait une petite suite de tests après les changements.

Un weekend, un hôte est tombé et un lot de VMs a dû migrer. Le cluster l’a fait sans drame. La base de fonctionnalités a évité les échecs de migration, et la canary VM avait déjà validé la nouvelle image d’hôte plus tôt dans la semaine. Pas de débogage héroïque à 2 h du matin, juste des opérations normales.

Ce n’était pas glamour. C’était correct. Et en ingénierie de la fiabilité, « ennuyeux » est un compliment.

Erreurs courantes : symptômes → cause racine → correction

1) Le passthrough GPU ne démarre pas ; QEMU se plaint d’IOMMU

Symptômes : La VM ne démarre pas avec le passthrough ; les logs mentionnent DMAR/IOMMU, « VFIO: No IOMMU », ou des problèmes de reset de périphérique.

Cause racine : VT-d/AMD-Vi désactivé dans le BIOS, paramètres kernel manquants, ou groupes IOMMU non isolés.

Correction : Activez VT-d/AMD-Vi dans le BIOS ; ajoutez intel_iommu=on ou amd_iommu=on ; vérifiez les groupes IOMMU ; si les groupes sont mauvais, changez de carte mère/slot ou envisager d’abandonner le passthrough.

2) Les VMs saccadent sous charge même si l’usage CPU est « bas »

Symptômes : Lags interactifs, glitches audio, pertes de paquets, mais le CPU moyen semble correct.

Cause racine : Mise à l’échelle de fréquence CPU (powersave), tempêtes d’interruptions sur un seul cœur, ou steal time dû à la surallocation.

Correction : Mettre le gouverneur en performance ; répartir les IRQ ; réserver des cœurs pour l’hôte ; réduire la surallocation ; mesurer %steal dans les VMs.

3) Les performances de stockage s’effondrent quand vous activez chiffrement/compression

Symptômes : Forte utilisation CPU dans des threads noyau, latence I/O augmente, débit plafonne bien en dessous de la capacité du disque/NIC.

Cause racine : Accélération AES manquante ou mal exposée aux invités, ou le CPU devient le goulot d’étranglement du stockage à cause de réglages coûteux.

Correction : Vérifiez les flags AES-NI/VAES sur hôte et invité ; utilisez host-passthrough lorsque pertinent ; ajustez la compression ; envisagez un CPU plus rapide ou une stratégie d’offload.

4) La migration à chaud échoue avec « CPU incompatible »

Symptômes : La migration est refusée ; l’erreur mentionne des fonctionnalités CPU manquantes.

Cause racine : Utilisation de host-passthrough ou exposition de fonctionnalités absentes sur l’hôte de destination.

Correction : Standardisez un modèle CPU de base ; masquez des fonctionnalités ; gardez les hôtes du cluster dans une famille CPU compatible si la migration est non négociable.

5) Crashes aléatoires de VM après « tuning des performances »

Symptômes : Réinitialisations occasionnelles, blocages, dérive temporelle, ou erreurs de périphériques après pinning/réglages.

Cause racine : Isolation CPU trop agressive, IRQ mal épinglées, threads noyau affamés, ou réglages d’undervolt/overclock instables.

Correction : Annulez les réglages exotiques ; allouez des cœurs pour l’entretien de l’hôte ; assurez-vous que le microcode est à jour ; désactivez l’overclock sur une machine en rôle serveur.

6) Débit réseau faible malgré un CPU puissant

Symptômes : Débit bas, forte softirq, perte de paquets, un cœur CPU saturé.

Cause racine : Mauvaise configuration virtio, files insuffisantes, problèmes d’affinité IRQ, ou absence d’offloads/SR-IOV quand nécessaire.

Correction : Utilisez virtio-net avec multiqueue ; confirmez la distribution des IRQ ; envisagez SR-IOV ou le passthrough NIC si vous avez besoin d’un débit proche du filaire avec peu de CPU.

Listes de contrôle / plan étape par étape

Étape par étape : choisir un CPU/plateforme pour un hyperviseur domestique

Définissez les « must haves ». Passthrough GPU ? Passthrough HBA ? Routage 10GbE ? Chiffrement généralisé ? Si oui, priorisez le comportement IOMMU et l’accélération AES.
Choisissez la plateforme, pas seulement le CPU. Le layout PCIe de la carte mère, la maturité du BIOS et le support du chipset détermineront votre quotidien.
Vérifiez SLAT. Assurez-vous de la présence d’EPT (Intel) ou NPT (AMD). Considérez-le comme obligatoire pour la virtualisation moderne.
Décidez de la stratégie de migration. Un seul hôte : host-passthrough OK. Plusieurs hôtes avec migration : standardisez le modèle CPU/fonctionnalités.
Dimensionnez pour la RAM avant les cœurs. Si vous ne pouvez vous permettre qu’une seule amélioration, la RAM évite les pires échecs de performance.
Budgetez des cœurs pour l’hôte. Laissez de la marge pour les interruptions, ZFS et l’hyperviseur lui‑même.
Planifiez la thermique et l’alimentation. Un CPU qui throttle est un CPU qui vous ment.

Étape par étape : valider un nouvel hôte avant de déplacer des charges

Mettez à jour le BIOS/UEFI vers une version stable.
Installez les microcodes et confirmez dans dmesg.
Activez VT-x/AMD-V et VT-d/AMD-Vi dans le BIOS.
Démarrez avec les flags kernel IOMMU si le passthrough est nécessaire.
Vérifiez les groupes IOMMU et confirmez que vos périphériques cibles sont isolables.
Mettez le gouverneur CPU sur une politique connue ; mesurez la gigue.
Exécutez une VM canary : test réseau, test disque, test CPU, et un cycle de reboot.
Puis migrez les services réels.

Étape par étape : stabiliser les performances sur un hôte existant

Vérifiez l’utilisation du swap et corrigez la pression mémoire en priorité.
Vérifiez %steal dans les VMs clés pour détecter la surallocation.
Vérifiez l’iowait pour voir si le stockage est le goulot.
Inspectez les interruptions pour les points chauds ; corrigez la distribution des IRQ.
Vérifiez les pilotes virtio et les réglages multiqueue.
Envisagez le pinning uniquement si vous pouvez aussi gérer les interruptions et réserver des cœurs pour l’hôte.

FAQ

1) Ai-je besoin de VT-x/AMD-V pour la virtualisation à domicile ?

Oui pour les hyperviseurs modernes et des performances sensées. Sans cela, vous êtes soit bloqué, soit contraint à des modes lents/limités. Considérez-le comme obligatoire.

2) EPT/NPT est‑il vraiment si important ?

Oui. SLAT (EPT/NPT) est l’un des plus grands habilitateurs de performance pour les VMs. Si vous évaluez des CPU plus anciens, c’est la fonctionnalité qui devrait décider « non ».

3) J’ai activé VT-d/AMD-Vi. Pourquoi le passthrough échoue encore ?

Parce que les groupes IOMMU et la topologie PCIe de la carte mère décident de ce qui peut être isolé. Vérifiez aussi les paramètres kernel, le remapping d’interruptions, et que le périphérique supporte le reset requis par VFIO.

4) Dois‑je choisir plus de cœurs ou des fréquences plus élevées ?

Pour les labos domestiques typiques (beaucoup de services, charge modérée), plus de cœurs avec un bon cache et un boost all‑core stable l’emportent. Pour quelques VMs sensibles à la latence, des fréquences soutenues plus élevées peuvent sembler meilleures. Si vous avez les moyens, faites les deux.

5) SMT/Hyper-Threading aide‑t‑il la virtualisation ?

Souvent oui pour le débit, parfois non pour la prédictibilité de la latence. Si vous faites du pinning CPU, soyez conscient de SMT afin de ne pas épingler deux vCPU lourds sur des threads sœurs du même cœur.

6) Ai‑je besoin d’AVX-512 ?

Seulement si vous exécutez des charges qui l’utilisent réellement. Pour beaucoup de charges domestiques, AVX-512 est sans intérêt. Il peut aussi influer sur les fréquences. Achetez-le pour une raison, pas pour la frime.

7) AES-NI importe‑t‑il si je n’exécute pas de VPN ?

Ça peut quand même. Le chiffrement apparaît dans le chiffrement disque, les sauvegardes, TLS et parfois dans les pipelines de checksumming/compression de stockage. Si vous chiffrez les données au repos, l’accélération AES mérite votre attention.

8) Dois‑je désactiver les atténuations CPU pour retrouver des performances ?

Généralement non. Si vous faites des benchmarks et que vous comprenez le risque, vous pouvez tester. Pour des services réels—même à la maison—gardez les atténuations activées et corrigez les performances en réduisant la contention, en améliorant l’I/O ou en upgradeant le matériel.

9) L’IOMMU est‑il utile même si je ne fais pas de passthrough ?

Oui pour l’isolation DMA et la posture de sécurité, mais cela peut ajouter de la complexité. Si vous n’en avez pas besoin, vous pouvez le laisser désactivé. Si vous pourriez en avoir besoin plus tard, activez‑le tôt et validez la stabilité.

10) Un « CPU serveur » peut‑il être pire qu’un CPU grand public pour la virtualisation domestique ?

Oui. Les vieux CPU serveur peuvent avoir beaucoup de cœurs mais une mono‑thread plus faible, une consommation plus élevée et un impact des atténuations plus important. Ils peuvent être excellents pour le débit brut ; ils peuvent sembler lents pour des charges interactives mixtes.

Prochaines étapes que vous pouvez réellement faire

Si vous voulez le chemin le plus court vers une meilleure expérience de virtualisation à domicile :

Exécutez les commandes de vérification ci‑dessus sur votre hôte actuel : SLAT, IOMMU, gouverneur, swap, interruptions, %steal.
Corrigez d’abord les problèmes bon marché : mettez un gouverneur sensé, arrêtez le swap, corrigez virtio et la distribution IRQ.
Si vous avez besoin de passthrough, validez les groupes IOMMU avant d’acheter quoi que ce soit. Un nouveau CPU ne réparera pas une carte mère qui ne peut pas isoler les périphériques.
Si vous achetez du matériel, priorisez : EPT/NPT + IOMMU fiable + suffisamment de cœurs + suffisamment de cache + capacité RAM suffisante sur la plateforme.
Mesurez après chaque changement. Les labos domestiques sont le lieu de naissance des mythes de performance ; la mesure est la façon de les éviter.