EVC (Enhanced vMotion Compatibility) : comprendre son impact sur les performances

EVC (Enhanced vMotion Compatibility) reste l’un des mécanismes les plus utiles de vSphere lorsqu’un cluster doit traverser plusieurs générations de processeurs sans interrompre les machines virtuelles. Son rôle est simple à énoncer, mais ses conséquences opérationnelles sont souvent mal comprises : EVC ne rend pas des CPU différents identiques, il présente aux machines virtuelles un sous-ensemble commun de fonctionnalités processeur afin qu’elles puissent migrer par vMotion entre les hôtes compatibles.

Dans un environnement homogène, la question se pose peu. Dès qu’un renouvellement matériel commence, en revanche, le problème apparaît immédiatement : une VM démarrée sur un processeur récent peut avoir utilisé ou simplement exposé des instructions absentes d’un serveur plus ancien. Une migration à chaud vers cet ancien hôte deviendrait alors impossible. EVC évite cette situation en limitant le jeu d’instructions visible par l’OS invité et les applications.

Pourquoi vMotion dépend du jeu d’instructions CPU

vMotion transfère l’état d’exécution d’une machine virtuelle d’un hôte ESXi à un autre. Cela inclut la mémoire, les périphériques virtuels et l’état du processeur virtuel. Pour reprendre l’exécution sur le nouvel hôte, ESXi doit garantir que les instructions et registres CPU utilisés par la VM existent également sur la destination.

Les processeurs x86 évoluent par ajouts successifs : SSE, AVX, AVX2, AVX-512, AES-NI, SHA extensions, FMA, BMI, virtualisation matérielle, nouvelles capacités de gestion mémoire, etc. Deux serveurs d’architecture x86 peuvent donc être globalement compatibles tout en présentant des différences importantes dans leurs drapeaux CPUID.

Sans EVC, une VM expose généralement les capacités du processeur de l’hôte sur lequel elle a été mise sous tension. Si cette VM est exécutée sur un hôte récent, son système invité peut détecter et exploiter des instructions avancées. Une migration vers un hôte qui ne les supporte pas sera refusée, même si la VM utilise peu ou pas ces instructions à l’instant précis de la migration.

Le principe d’EVC est de choisir un niveau CPU commun au cluster. ESXi masque alors les fonctions trop récentes aux VM. Une VM voit un processeur virtuel cohérent quel que soit l’hôte du cluster, à condition que chaque hôte supporte au moins le niveau EVC sélectionné. Pour aller plus loin, consultez les fondamentaux de vMotion, DRS et DPM.

EVC fonctionne historiquement par famille de processeurs. Il faut donc distinguer les domaines Intel et AMD : un vMotion entre un hôte Intel et un hôte AMD n’est pas couvert par l’EVC de cluster traditionnel. Des possibilités de mobilité inter-fournisseurs existent dans certains scénarios et versions récentes, mais elles demandent une validation précise de la matrice de compatibilité, des versions ESXi et du profil CPU effectivement exposé. En exploitation, il reste préférable de considérer Intel et AMD comme deux domaines de mobilité distincts, sauf validation explicite en laboratoire puis en préproduction.

EVC de cluster : principe et prérequis

L’EVC de cluster définit un plancher fonctionnel, pas un plafond matériel absolu au niveau physique. Les processeurs récents continuent naturellement à exécuter les VM ; simplement, certaines instructions ne sont plus annoncées aux invités.

Prenons un cluster contenant des hôtes de plusieurs générations. Si le niveau EVC choisi correspond à la génération la plus ancienne, les hôtes récents masqueront leurs extensions supplémentaires. Les VM pourront alors être déplacées librement entre les membres du cluster, sous réserve des autres prérequis vMotion : réseau, stockage, compatibilité des périphériques, version matérielle virtuelle, chiffrement éventuel et politiques DRS.

Avant d’activer ou de modifier EVC, il faut inventorier les processeurs réellement présents. Ne pas se limiter à la référence commerciale du serveur : le même modèle de châssis peut avoir été livré avec plusieurs générations CPU. Il faut aussi vérifier les microcodes, les versions ESXi, les paramètres BIOS et les éventuelles options de sécurité qui influencent les capacités exposées.

Sur un hôte ESXi, les informations CPU peuvent être consultées depuis l’interface vSphere Client, mais la ligne de commande reste utile pour un contrôle détaillé :

esxcli hardware cpu list

Pour obtenir les informations générales sur la plateforme :

esxcli hardware cpu global get

Côté PowerCLI, l’inventaire des modèles CPU d’un cluster est rapide :

Get-Cluster -Name "Cluster-Production" |
Get-VMHost |
Select-Object Name, Version,
    @{Name="CPU"; Expression={$_.ProcessorType}},
    @{Name="Cores"; Expression={$_.NumCpu}},
    @{Name="Sockets"; Expression={$_.NumCpu / $_.NumCpuCores}}

Le résultat doit être rapproché de la documentation de compatibilité de la version vSphere déployée. Un niveau EVC disponible dans une version donnée peut être absent, renommé ou limité dans une autre. Lors d’une modernisation vers vSphere 8 ou une version plus récente, cette vérification est particulièrement importante : le retrait de matériel ancien et l’évolution des niveaux CPU supportés peuvent modifier la stratégie de consolidation.

Configurer EVC au niveau du cluster

La configuration est réalisée dans les paramètres du cluster, section dédiée à la compatibilité EVC. Dans vSphere Client, l’opération consiste typiquement à sélectionner le cluster, ouvrir les paramètres de configuration EVC, choisir le fournisseur CPU concerné puis le niveau EVC souhaité.

Le bon niveau n’est pas le plus bas par défaut. C’est le niveau le plus élevé compatible avec tous les hôtes qui doivent participer au domaine de vMotion. Choisir un niveau inutilement ancien augmente la pénalité fonctionnelle sans améliorer la mobilité au-delà de ce qui est nécessaire.

Une méthode prudente suit généralement ces étapes :

1. Recenser les générations CPU et versions ESXi de tous les hôtes.
2. Identifier l’hôte qui impose le niveau le plus bas.
3. Vérifier la compatibilité du niveau envisagé dans la matrice VMware et dans vCenter.
4. Mettre à jour les microcodes, firmware et ESXi lorsque cela est justifié.
5. Activer EVC au niveau du cluster.
6. Redémarrer les VM qui doivent adopter le nouveau profil CPU.
7. Valider les migrations vMotion dans les deux sens entre hôtes représentatifs.
8. Documenter le niveau choisi, sa justification et les conditions de retrait futur.

Le point souvent oublié est le redémarrage des VM. Modifier le niveau EVC du cluster ne transforme pas instantanément le processeur virtuel des machines déjà en cours d’exécution. Une VM doit être arrêtée puis remise sous tension pour recevoir le nouveau jeu de fonctionnalités CPU. Le comportement exact dépend du changement effectué et de l’état initial de la VM, mais il faut planifier cette contrainte comme une opération nécessitant une fenêtre de maintenance applicative.

Avant d’élever un niveau EVC, il faut au contraire s’assurer que les VM concernées ont été arrêtées ou redémarrées dans des conditions compatibles. Une VM ayant démarré avec un profil plus ancien peut continuer à présenter ce profil tant qu’elle n’est pas redémarrée. Cela peut être souhaitable pendant une migration progressive, mais devient un piège si l’objectif est de récupérer les instructions des nouveaux processeurs.

La vérification par PowerCLI peut compléter l’interface graphique :

$cluster = Get-Cluster -Name "Cluster-Production"
$cluster.ExtensionData.ConfigurationEx.EvcMode

Pour contrôler les capacités CPU d’une VM depuis ESXi, un examen des journaux peut également aider lors d’un diagnostic de vMotion refusé :

grep -iE "EVC|CPUID|vMotion|CPU feature" /var/log/vmkernel.log

Un refus de migration ne signifie pas automatiquement qu’EVC est mal configuré. Des périphériques pass-through, des vGPU, certains contrôleurs ou une configuration de chiffrement peuvent aussi créer des contraintes de placement. Il faut lire le message de compatibilité complet dans vCenter avant de conclure à un problème de processeur.

Quel est l’impact réel sur les performances ?

EVC a un impact potentiellement réel, mais il n’existe pas de pourcentage universel. Le coût dépend des instructions masquées, du compilateur utilisé par l’application, des bibliothèques chargées, de la taille des données, de la charge mémoire et de la fréquence effective du processeur. Pour aller plus loin, consultez l’architecture d’un cluster vSphere.

Pour des workloads généralistes, l’écart est souvent faible. Des services web, contrôleurs de domaine, serveurs de fichiers, applications métier transactionnelles ou composants d’infrastructure ne tirent pas forcément parti des extensions les plus récentes. Dans de nombreux tests internes réalistes, le différentiel se situe dans le bruit de mesure ou reste inférieur à quelques pourcents, par exemple 0 à 3 % sur un débit HTTP, une base relationnelle modérément chargée ou un traitement Java standard.

La situation change pour les charges de calcul intensif. Les bibliothèques scientifiques, l’analyse de données, le rendu, l’encodage vidéo, la compression, les moteurs de chiffrement, l’inférence et certains traitements de bases de données vectorisés peuvent sélectionner au démarrage des chemins optimisés selon les drapeaux CPUID disponibles.

À titre d’ordre de grandeur, voici des écarts fréquemment observés entre un profil CPU moderne complet et un profil EVC qui masque plusieurs générations d’extensions :

Ces chiffres ne remplacent pas une mesure. Ils illustrent surtout un mécanisme : si EVC masque AVX2 ou AVX-512, une application peut basculer vers SSE, vers un chemin scalaire ou vers une implémentation générique. La perte dépend alors autant du logiciel que du CPU.

Un autre effet mérite attention : AVX et AVX-512 peuvent modifier les comportements de fréquence sur certains processeurs. Les instructions vectorielles lourdes peuvent déclencher des fréquences plus basses que des charges scalaires. Il est donc possible qu’un benchmark synthétique donne un résultat contre-intuitif selon la nature exacte du test. Cela ne signifie pas que masquer les extensions est gratuit ; cela signifie qu’il faut mesurer le temps de traitement, le débit et la consommation de ressources dans le contexte de l’application.

Une démarche de benchmark crédible comprend au minimum :

• une VM de référence avec le profil CPU complet ;
• la même VM démarrée avec le niveau EVC cible ;
• une version identique de l’OS, des pilotes et des bibliothèques ;
• des jeux de données identiques ;
• plusieurs exécutions, avec moyenne et dispersion ;
• une observation de la fréquence CPU, du ready time et de la pression mémoire ;
• une vérification des instructions réellement utilisées par l’application.

Sous Linux, les drapeaux CPU visibles dans l’invité peuvent être vérifiés ainsi :

lscpu
grep -m1 '^flags' /proc/cpuinfo

Pour une charge de compression, un test reproductible peut s’appuyer sur zstd :

dd if=/dev/zero of=/tmp/test-8g.bin bs=1M count=8192 status=progress
/usr/bin/time -v zstd -T0 -19 -f /tmp/test-8g.bin -o /tmp/test-8g.bin.zst

Pour une charge de calcul, il est préférable d’utiliser le benchmark représentatif de l’application réelle plutôt qu’un outil générique. Une bibliothèque numérique peut, par exemple, détecter AVX2 au démarrage et conserver ce choix pendant toute la durée du processus. Il faut donc redémarrer les services entre les scénarios.

Per-VM EVC : une granularité adaptée aux renouvellements

Le Per-VM EVC répond à une limite historique de l’EVC de cluster : un seul niveau commun pour toutes les VM d’un cluster peut pénaliser des machines qui ne migrent jamais vers les hôtes les plus anciens.

Avec Per-VM EVC, le profil CPU est défini à l’échelle de la machine virtuelle. Une VM critique pour le calcul peut conserver un profil récent et être placée uniquement sur les hôtes capables de l’exécuter. Une VM d’infrastructure, ou une VM destinée à migrer entre générations, peut recevoir un profil plus conservateur.

Cette approche est particulièrement utile dans les situations suivantes :

• renouvellement progressif sur plusieurs mois ;
• coexistence temporaire de deux ou trois générations de serveurs ;
• workloads HPC, analytiques ou multimédias sensibles aux extensions SIMD ;
• VM anciennes nécessitant une mobilité maximale ;
• clusters où DRS doit disposer de plus de souplesse sans imposer un profil CPU minimal à tout le monde.

Le revers est une complexité accrue. Le placement des VM devient dépendant de leur profil individuel. DRS ne peut pas déplacer une VM vers un hôte ne présentant pas les fonctionnalités requises. Il faut donc surveiller la capacité disponible dans chaque groupe matériel, surtout en cas de maintenance ou de panne d’un hôte. Pour aller plus loin, consultez l’administration quotidienne d’un hôte ESXi.

Per-VM EVC ne doit pas être vu comme un moyen de contourner toutes les incompatibilités. Il reste soumis aux capacités matérielles et aux règles de compatibilité vSphere. Il impose également une discipline de documentation : chaque profil particulier doit avoir une raison claire, un propriétaire applicatif et une date de révision.

Une stratégie saine consiste à créer deux classes de VM :

• des VM mobiles, avec un profil EVC compatible avec tout le cluster ou avec un sous-ensemble large ;
• des VM optimisées, avec un profil plus récent et des règles de placement explicites.

Cette séparation évite de sacrifier les performances de toute la plateforme pour quelques charges spécialisées.

Recommandations d’exploitation

EVC est avant tout un outil de continuité opérationnelle pendant un cycle de vie matériel. Il ne faut pas le considérer comme une configuration figée pour dix ans. Lorsqu’une ancienne génération CPU est retirée, le niveau EVC doit être réévalué. Relever le niveau permet aux VM redémarrées de bénéficier des instructions plus modernes.

Dans les clusters de production, il est recommandé de documenter :

• le niveau EVC choisi ;
• les modèles CPU présents ;
• les VM utilisant Per-VM EVC ;
• les contraintes de placement associées ;
• les applications sensibles aux instructions CPU ;
• le plan de relèvement du niveau après décommissionnement des anciens hôtes.

Enfin, un changement EVC doit suivre le même processus qu’une modification de capacité ou de compatibilité applicative. Tester un vMotion de validation, vérifier les alarmes DRS, redémarrer un échantillon représentatif de VM et comparer les performances des workloads sensibles restent des étapes indispensables.