Attribuer plus de vCPU que l’hôte ne compte de cœurs favorise la densité, mais ne promet aucune performance. Pris isolément, le ratio vCPU d’Hyper-V ne décrit ni la pression réelle ni les délais d’exécution.
Deux hôtes au ratio identique réagissent différemment selon l’alignement des pics, le SMT, la topologie NUMA et la taille des VM. La surallocation des processeurs virtuels reste viable lorsque la capacité CPU physique absorbe la demande sans allonger sensiblement l’attente. Sans cette marge, les vCPU attendent et les applications ralentissent.
Que mesure réellement le ratio vCPU Hyper-V ?
Un vCPU représente un processeur virtuel présenté à une VM, non une unité matérielle réservée en permanence. Hyper-V l’ordonnance sur les processeurs logiques de l’hôte, appelés LP, qui correspondent aux threads CPU visibles par Windows. Les cœurs physiques sont les unités d’exécution matérielles ; avec le SMT, un cœur peut exposer plusieurs LP. Cette distinction évite de confondre capacité matérielle, configuration virtuelle et activité CPU observée.
- VP par LP = total des vCPU actifs divisé par le nombre de processeurs logiques.
- vCPU par cœur = total des vCPU actifs divisé par le nombre de cœurs physiques.
Deux calculs éclairent la densité, sans prédire seuls les performances. Le ratio VP:LP divise le total des vCPU attribués aux machines virtuelles actives par le nombre de LP. Sur un serveur doté de 32 cœurs et 64 LP, 128 vCPU donnent un ratio de 2:1. Rapporté au matériel, le calcul atteint 4 vCPU par cœur physique. Ce ratio n’établit pas la saturation : 100 vCPU peu sollicités attendent moins que 40 vCPU utilisés à 100 %.
Aucun ratio VP:LP fixe ne s’applique aux versions modernes
Les ratios fixes relayés proviennent de règles d’anciennes éditions, non d’une loi de performance. Windows Server 2008 R2 prenait en charge jusqu’à 8 VP par LP pour les charges serveur ; son SP1 relevait ce seuil à 12 pour certains déploiements VDI sous Windows 7. Ces plafonds historiques de support délimitaient une configuration couverte par Microsoft. Depuis Windows Server 2012, ils ne constituent plus un ratio imposé.
Sur Windows Server 2016, 2019, 2022 et 2025, Microsoft ne fixe aucun rapport VP par LP. Les limites techniques d’Hyper-V décrivent plutôt des capacités absolues : 2 048 VP actifs par hôte, avec respectivement 512, 512, 1 024 et 2 048 LP au maximum. Une VM de génération 2 peut recevoir jusqu’à 240, 240, 1 024 ou 2 048 VP selon la version. Ces valeurs bornent le support ; le dimensionnement dépend des charges CPU réellement mesurées sur l’hôte.
Quel ratio retenir selon l’intensité de la charge CPU ?
Lorsqu’une VM mobilise presque constamment ses vCPU, la marge de mutualisation devient faible. Pour une charge CPU soutenue, le ratio 1:1 fournit le repère le plus sûr : un vCPU actif pour un processeur logique disponible. Cette correspondance réduit les files d’attente de l’hyperviseur et rend les temps de réponse plus prévisibles. Elle convient aux bases de données intensives, aux calculs continus ou aux applications fortement sensibles à la latence.
Les charges en pointes offrent davantage de latitude, surtout lorsque leurs périodes d’activité ne se chevauchent pas. Des workloads intermittents peuvent accepter un ratio supérieur à 1:1 sans baisse perceptible, mais ce gain de densité doit être vérifié aux heures très chargées. Comparez la consommation simultanée, les temps de réponse et les attentes d’exécution. Une hausse de la contention des ressources signale que l’hôte porte trop de vCPU actifs pour sa capacité.
À retenir : le ratio 1:1 favorise une performance CPU prévisible, tandis qu’un ratio supérieur suppose que les pics des VM ne se produisent pas simultanément.
Le SMT modifie la capacité réelle derrière les processeurs logiques
Le nombre de processeurs logiques affiché par Windows ne décrit pas la capacité physique de l’hôte. Avec deux threads matériels SMT par cœur, deux flux d’instructions utilisent le même cœur et n’offrent donc jamais l’équivalent garanti de deux cœurs complets. Le gain varie selon les instructions, les caches sollicités et la pression sur les unités d’exécution. La puissance CPU disponible progresse, mais pas dans une proportion de deux pour un.
L’ordonnancement doit intégrer cette asymétrie, sans traiter chaque processeur logique comme un cœur autonome. Sous Windows Server 2019, le core scheduler d’Hyper-V est utilisé par défaut et regroupe les vCPU d’une VM sur les threads frères lorsque sa topologie virtuelle le permet. Ce fonctionnement encadre le partage des ressources et renforce l’isolation entre VM. Une topologie SMT virtuelle inadéquate peut malgré tout laisser un thread frère inutilisé et réduire la densité globale attendue.
| Configuration de l’hôte | Cœurs physiques | Processeurs logiques | vCPU actifs | Ratio VP:LP | Ratio vCPU:cœur |
|---|---|---|---|---|---|
| 2 sockets × 16 cœurs, sans SMT | 32 | 32 | 128 | 4:1 | 4:1 |
| 2 sockets × 16 cœurs, SMT ×2 | 32 | 64 | 128 | 2:1 | 4:1 |
| 2 sockets × 24 cœurs, SMT ×2 | 48 | 96 | 192 | 2:1 | 4:1 |
Comment le nombre de vCPU attribué à chaque VM influence-t-il la densité ?
Ajouter des processeurs virtuels ne crée pas de puissance physique sur l’hôte. Une allocation des vCPU trop large élève artificiellement le ratio VP:LP et affiche une densité flatteuse, même si la charge demeure modeste. Ainsi, doter une VM de huit vCPU lorsqu’elle n’en exploite réellement que deux multiplie les ressources configurées sans accélérer ses traitements ni améliorer la capacité physique réellement disponible pour ses voisines.
Ce décalage devient visible quand plusieurs machines réclament simultanément du temps processeur. Le surprovisionnement des VM peut alors allonger l’attente des VP sur des LP occupés, malgré une consommation moyenne rassurante. Ajustez chaque configuration d’après des mesures représentatives : moyenne, pics, durée des pointes et latence applicative. Retirez progressivement les vCPU durablement inactifs, puis comparez les performances. À l’inverse, si tous les VP dépassent 90 % alors que l’hôte conserve une marge stable, un ajout ciblé se justifie.
La topologie NUMA limite certaines grosses machines virtuelles
Chaque nœud NUMA associe des cœurs à une zone mémoire locale, desservie avec une faible latence. Hyper-V présente généralement à l’invité une topologie NUMA virtuelle calquée sur les caractéristiques de l’hôte afin de rapprocher calculs et données. Lorsqu’une VM fortement dotée dépasse les ressources locales d’un nœud, ses vCPU sollicitent parfois une mémoire rattachée à un autre nœud. Ces accès mémoire distants ajoutent de la latence et rendent les performances moins prévisibles. Avant le déploiement, examinez ces trois paramètres :
- La mémoire locale disponible sur chaque nœud physique ;
- Le nombre de vCPU attribués à la machine virtuelle ;
- La capacité de l’application invitée à exploiter NUMA.
Sous Windows Server 2025, une VM plus large qu’un nœud demande une configuration cohérente. Le NUMA spanning autorise son exécution au-delà d’un seul nœud, mais ne supprime ni la latence distante ni les écarts de débit. Validez ce réglage avec une charge représentative. Plusieurs VM mieux réparties offrent parfois davantage de stabilité qu’une machine surdimensionnée, malgré un ratio VP:LP pourtant acceptable.
Quels compteurs révèlent une contention CPU réelle ?
Un ratio VP:LP décrit une densité théorique, sans prouver que les machines virtuelles attendent réellement. Les compteurs de performance Hyper-V à suivre sur l’hôte incluent Hyper-V Hypervisor Logical Processor(*)\% Total Run Time et Hyper-V Hypervisor Virtual Processor(*)\% Total Run Time. Le premier restitue le taux d’utilisation du processeur logique ; une valeur agrégée supérieure à 90 % signale un hôte saturé et invite à corréler l’observation avec la charge des VP.
Sous Windows Server 2025, CPU Wait Time Per Dispatch quantifie l’attente globale par distribution, tandis que CPU Contention Time Per Dispatch isole le temps de contention CPU. Le compteur Logical Processor Dispatches/sec apporte le volume de distributions. Leur lecture croisée fait ressortir le délai d’ordonnancement réellement subi, bien mieux qu’un ratio isolé. Une pointe brève appelle une vérification ; une hausse durable et commune à plusieurs VP confirme la pression CPU.
Réserves, limites et poids répartissent la capacité disponible
Hyper-V encadre l’accès au processeur par VM avec Set-VMProcessor. Reserve garantit un pourcentage minimal lorsque la machine en a besoin, Maximum plafonne sa consommation entre 0 % et 100 %, et RelativeWeight départage les demandes concurrentes. Ce dernier règle la priorité relative des VM sur une échelle de 1 à 10 000. Une valeur élevée favorise une charge lors d’une contention, sans lui réserver des cycles supplémentaires.
Pour administrer plusieurs charges comme un ensemble, les groupes de processeurs appliquent un budget commun ou une limite au groupe, puis y rattachent des VM. Ils servent à isoler des services ou à contenir un locataire bruyant, mais ne remplacent ni des cœurs physiques ni un hôte supplémentaire. Si la demande dépasse durablement la capacité disponible, la réponse reste le redimensionnement, le déplacement des charges ou l’ajout de capacité.
À retenir : les réserves, limites et poids organisent le partage des ressources existantes ; ils ne produisent aucune capacité CPU.
Comment valider le ratio retenu sur un hôte ou un cluster ?
Une moyenne CPU lisse peut masquer des ralentissements brefs mais pénalisants pour les applications. Pour éprouver le ratio retenu, reproduisez une activité représentative et observez les pics CPU simultanés, la latence applicative, le temps d’attente des processeurs virtuels et la contention côté hyperviseur. Croisez ces mesures avec le débit métier, car un hôte très sollicité peut rester acceptable si les délais demeurent stables. Répétez les tests aux heures chargées.
À l’échelle du cluster, la validation doit inclure la perte du nœud portant la charge la plus élevée. Ce scénario de panne vérifie si les VM redémarrées ou migrées sont absorbées sans dégrader les objectifs de service. Mesurez alors la capacité résiduelle du cluster, les files d’attente CPU, la durée des migrations et les latences observées. Si la saturation persiste après la bascule, réduisez le ratio vCPU/LP, redimensionnez les VM surdotées ou ajoutez des ressources physiques. Conservez ces résultats.