ESXi 6.7 Update 3 | 20 août 2019 | Build ISO 14320388

Vérifiez les compléments et les mises à jour pour ces notes de mise à jour.

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

  • Améliorations du pilote ixgben : le pilote ixgben ajoute le couplage de file d'attente pour optimiser l'efficacité du CPU.
  • Améliorations de VMXNET3 : ESXi 6.7 Update 3 ajoute le déchargement d'encapsulation invité et UDP, et la prise en charge du RSS ESP à la pile de mise en réseau améliorée (ENS). Les calculs de somme de contrôle sont déchargés des paquets encapsulés vers l'émulation de périphérique virtuel et vous pouvez exécuter RSS sur des paquets UDP et ESP à la demande. Le RSS UDP prend en charge IPv4 et IPv6, alors que le RSS ESP prend uniquement en charge IPv4. La fonctionnalité requiert un pilote VMXNET3 v4 correspondant.
  • Améliorations de NVIDIA Virtual GPU (vGPU) : Avec vCenter Server 6.7 Update 3, vous pouvez configurer des machines virtuelles et des modèles avec jusqu'à quatre périphériques vGPU pour couvrir les cas d'utilisation nécessitant plusieurs accélérateurs GPU rattachés à une machine virtuelle. Pour utiliser la fonctionnalité vGPU de vMotion, vous devez définir le paramètre avancé vgpu.hotmigrate.enabled sur true et vous assurer que vos hôtes vCenter Server et ESXi exécutent vSphere 6.7 Update 3.
    vMotion sur des machines virtuelles accélérées par plusieurs GPU peut échouer normalement sous une charge de travail GPU intense en raison du délai maximal de basculement de 100 secondes. Pour éviter cet échec, augmentez le délai maximal de basculement autorisé ou attendez que la machine virtuelle assure une charge de travail GPU moins intensive.
  • Améliorations du pilote bnxtnet : ESXi 6.7 Update 3 ajoute la prise en charge des adaptateurs réseau Broadcom 100G et du flux multi-RSS au pilote bnxtnet.
  • Améliorations de la prise en charge QuickBoot : ESXi 6.7 Update 3 autorise la prise en charge de QuickBoot sur les serveurs Dell EMC vSAN Ready Nodes R740XD et R640.
  • Délai d'arrêt configurable pour le service sfcbd : Avec ESXi 6.7 Update 3, vous pouvez configurer le délai d'arrêt du service sfcbd. Vous pouvez définir un délai d'arrêt en fonction du fournisseur CIM tiers que vous utilisez ou utiliser le réglage par défaut de 10 secondes.
  • Nouveau microcode SandyBridge : ESXi 6.7 Update 3 ajoute un microcode SandyBridge au VIB cpu-microcode pour actualiser la sécurité SandyBridge au niveau d'autres CPU et corriger la prise en charge de la compatibilité EVC (Enhanced vMotion Compatibility) par machine virtuelle. Pour plus d'informations, reportez-vous à l'article 1003212 de la base de connaissances VMware.

Versions antérieures d'ESXi 6.7

Les fonctions et problèmes connus d'ESXi sont décrits dans les notes de mise à jour de chaque version. Notes de mise à jour des versions antérieures à ESXi 6.7 :

Pour plus d'informations sur l'internationalisation, la compatibilité, l'installation et les mises à niveau, les composants open source et les remarques relatives à la prise en charge du produit, consultez les Notes de mise à jour de VMware vSphere 6.7 Update 1.

Notes d'installation de cette version

Modifications de l'intégration de VMware Tools dans ESXi 6.7 Update 3

Dans ESXi 6.7 Update 3, un sous-ensemble d'images ISO de VMware Tools 10.3.10 est intégré à l'hôte ESXi 6.7 Update 3.

Les images ISO de VMware Tools 10.3.10 suivantes sont intégrées à ESXi :

  • windows.iso : Image de VMware Tools pour Windows Vista ou version ultérieure
  • linux.iso : Image de VMware Tools pour le système d'exploitation Linux avec glibc version 2.5 ou version ultérieure

Les images ISO de VMware Tools 10.3.10 suivantes sont disponibles au téléchargement :

  • Solaris.iso: Image de VMware Tools pour Solaris
  • freebsd.iso : Image de VMware Tools pour FreeBSD
  • darwin.iso : Image de VMware Tools pour OSX

Pour télécharger VMware Tools pour les systèmes d'exploitation non intégrés à ESXi, suivez les procédures décrites dans les documents suivants :

Correctifs contenus dans cette version

Cette version contient tous les bulletins d'ESXi qui ont été publiés avant la date de publication de ce produit.

Détails de la build

Nom de fichier de téléchargement : update-from-esxi6.7-6.7_update03.zip
Build :

14320388

14141615 (sécurité uniquement)
Taille du téléchargement : 454,6 Mo

md5sum :

 b3a89ab239caf1e10bac7d60277ad995

sha1checksum :

 590aabc3358c45ca7ee3702d50995ce86ac43bf8
Redémarrage de l'hôte requis : Oui
Migration ou arrêt de la machine virtuelle requis : Oui

Bulletins

Cette version contient des bulletins généraux et de sécurité uniquement. Les bulletins de sécurité s'appliquent aux nouveaux correctifs de sécurité uniquement. Les nouveaux correctifs de bogues ne sont pas inclus, mais les correctifs de bogues des versions antérieures des correctifs et des mises à jour sont inclus.
Si l'installation de tous les nouveaux correctifs de sécurité et de bogues est requise, vous devez appliquer tous les bulletins présents dans cette version. Dans certains cas, le bulletin général remplacera le bulletin de sécurité uniquement. Cela n'est pas un problème, car le bulletin général contient les nouveaux correctifs de sécurité et de bogues.
Les bulletins de sécurité sont identifiables par leur ID de bulletin qui se termine par « SG ». Pour obtenir des informations sur la classification des correctifs et des mises à jour, consultez l'article KB 2014447.
Pour plus d'informations sur les bulletins individuels, consultez la page My VMware et la section Problèmes résolus.

ID de bulletin Catégorie Gravité
ESXi670-201908201-UG Correctif de bogues Critique
ESXi670-201908202-UG Correctif de bogues Important
ESXi670-201908203-UG Amélioration Important
ESXi670-201908204-UG Amélioration Important
ESXi670-201908205-UG Amélioration Important
ESXi670-201908206-UG Amélioration Important
ESXi670-201908207-UG Amélioration Important
ESXi670-201908208-UG Amélioration Important
ESXi670-201908209-UG Amélioration Important
ESXi670-201908210-UG Amélioration Important
ESXi670-201908211-UG Amélioration Important
ESXi670-201908212-UG Amélioration Important
ESXi670-201908213-UG Correctif de bogues Important
ESXi670-201908214-UG Amélioration Important
ESXi670-201908215-UG Amélioration Important
ESXi670-201908216-UG Amélioration Important
ESXi670-201908217-UG Correctif de bogues Important
ESXi670-201908218-UG Correctif de bogues Important
ESXi670-201908219-UG Amélioration Important
ESXi670-201908220-UG Correctif de bogues Important
ESXi670-201908221-UG Correctif de bogues Important
ESXi670-201908101-SG Sécurité Important
ESXi670-201908102-SG Sécurité Important
ESXi670-201908103-SG Sécurité Important
ESXi670-201908104-SG Sécurité Important

IMPORTANT : Pour les clusters qui utilisent VMware vSAN, vous devez tout d'abord mettre à niveau le système vCenter Server. La mise à niveau d'ESXi uniquement n'est pas prise en charge.
Avant une mise à niveau, consultez toujours la Matrice d'interopérabilité des produits VMware pour vérifier que les chemins de mise à niveau des versions antérieures d'ESXi, de vCenter Server et de vSAN sont compatibles avec ceux de la version actuelle. 

Profils d'image

Les versions des correctifs et des mises à jour de VMware contiennent des profils d'image généraux et critiques.

L'application du profil d'image général s'applique aux nouveaux correctifs de bogues.

Nom de profil d'image
ESXi-6.7.0-20190802001-standard
ESXi-6.7.0-20190802001-no-tools
ESXi-6.7.0-20190801001s-standard
ESXi-6.7.0-20190801001s-no-tools

Téléchargement et installation de correctifs

La manière habituelle d'appliquer des correctifs aux hôtes ESXi est d'utiliser VMware vSphere Update Manager. Pour plus d'informations, reportez-vous au guide À propos de l'installation et de l'administration de VMware vSphere Update Manager.

Les hôtes ESXi peuvent être mis à jour en téléchargeant manuellement le fichier ZIP de correctif à partir de la page de téléchargement de VMware et en installant le VIB à l'aide de la commande esxcli software vib. En outre, le système peut être mis à jour à l'aide du profil d'image et de la commande esxcli software profile.

Pour plus d'informations, reportez-vous aux guides Concepts et exemples de l'interface de ligne de commande vSphere et Mise à niveau vSphere.

Problèmes résolus

Les problèmes résolus sont regroupés comme suit :

ESXi670-201908201-UG
Catégorie des correctifs Correctif de bogues
Gravité des correctifs Critique
Redémarrage de l'hôte requis Oui
Migration ou arrêt de la machine virtuelle requis Oui
Matériel concerné S.O.
Logiciels concernés S.O.
VIB inclus
  • VMware_bootbank_esx-update_6.7.0-3.73.14320388
  • VMware_bootbank_vsan_6.7.0-3.73.14263135
  • VMware_bootbank_vsanhealth_6.7.0-3.73.14263064
  • VMware_bootbank_esx-base_6.7.0-3.73.14320388
PR résolus  2288428, 2282206, 2305377, 2213824, 2305719, 2301374, 2272250, 2220008, 2262288, 2290043, 2295425, 2300124, 2303227, 2301818, 2294347, 2338914, 2327317, 2312215, 2331247, 2340952, 2366745, 2331525, 2320309, 2304092, 2241121, 2306836, 2343913, 2361711, 2350171, 2297765, 2355516, 2287232, 2310826, 2332785, 2280742, 2386930, 2333442, 2346582, 2214222, 2335847, 2292419, 2132634, 2363202, 2367669, 2303016, 2337889, 2360408, 2344159, 2331369, 2370239, 2367142, 2336379, 2301231, 2354762, 2305414, 2305410, 2305404, 2305406, 2305405, 2335120, 2305407, 2315656, 2315652, 2305412, 2315684, 2323424, 2328263, 2332785, 2338914, 2214222, 2394247, 2402409, 2322882, 2482603
Numéros CVE CVE-2019-5528

Ce correctif met à jour les VIB esx-base, esx-update, vsan et vsanhealth pour résoudre les problèmes suivants :

  • PR 2288428 : des machines virtuelles peuvent cesser de répondre en raison de pannes répétitives de pilotes de périphérique tiers pour traiter les commandes

    Des machines virtuelles peuvent cesser de répondre en raison de pannes répétitives de certains pilotes de périphériques tiers pour traiter les commandes. Lorsque vous ouvrez la console de machine virtuelle, le message d'erreur suivant peut s'afficher :
    Erreur : connexion impossible au MKS : connexion impossible au canal \\.\pipe\vmware-authdpipe dans la période de nouvelle tentative 

    Ce problème est résolu dans cette version. Ce correctif récupère les commandes de pilotes de périphériques tiers qui ne répondent pas et s'assure que les commandes ayant échoué sont arrêtées, puis relancées jusqu'à ce qu'elles réussissent.

  • PR 2282206 : après le redémarrage d'un hôte ESXi, il se peut que les banques de données NFS utilisant une solution de tolérance de panne de Nutanix montées dans le système vCenter Server ne soient pas visibles

    Après le redémarrage d'un hôte ESXi, il se peut que les banques de données NFS utilisant une solution Fault Tolerance par Nutanix montées dans le système vCenter Server ne soient pas visibles. Cependant, vous pouvez voir les volumes dans l'hôte ESXi.

    Ce problème est résolu dans cette version.

  • PR 2305377 : les performances des machines virtuelles qui s'exécutent sur des banques de données NFS version 3 peuvent s'altérer dans le temps

    Les performances d'une machine virtuelle qui s'exécute sur une banque de données NFS version 3 peuvent s'altérer dans le temps. Après le redémarrage de l'hôte ESXi, les performances de la machine virtuelle redeviennent normales.

    Ce problème est résolu dans cette version.

  • PR 2213824 : un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une défaillance des pulsations de CPU physique

    Si une machine virtuelle dispose d'un snapshot SEsparse et si la taille du fichier VMDK de base n'est pas un multiple de 4K, lorsque vous interrogez la disposition physique du VMDK à partir de la système d'exploitation invité ou d'applications tierces, un blocage du CPU physique peut se produire. Par conséquent, ESXi échoue avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version.

  • PR 2305719 : la migration de machines virtuelles à l'aide de vSphere Storage vMotion avec des ports de conteneur peut entraîner l'échec de l'hôte ESXi avec un écran de diagnostic violet

    Si un port de conteneur a un ID d'attachement d'interface virtuelle (VIF) en double, lors de la migration de machines virtuelles à l'aide de vSphere Storage vMotion avec des ports de conteneur, la migration peut entraîner l'échec de l'hôte ESXi avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version.

  • PR 2301374 : un hôte ESXi peut échouer avec un écran de diagnostic violet à un point de capture UplinkRcv sur un adaptateur réseau convergé (CNA)

    Lorsque vous utilisez la syntaxe pktcap-uw, un hôte ESXi peut échouer avec un écran de diagnostic violet à un point de capture UplinkRcv sur un CNA. Ce problème se produit en raison d'une condition rare lorsqu'un périphérique ne dispose pas d'un objet de liaison montante associé lors de la capture d'un paquet sur la liaison montante.

    Ce problème est résolu dans cette version. Le correctif consiste à déplacer le point de capture si aucun objet de liaison montante n'est disponible. 

  • PR 2272250 : la route basée sur la stratégie de chargement de carte réseau physique ne fonctionne pas sur les hôtes ESXi 6.7 qui utilisent vSphere Distributed Switch version 6.6

    La route basée sur la stratégie de chargement de carte réseau physique n'était pas prise en charge sur vSphere Distributed Switch version 6.6 avant ESXi 6.7 Update 3.

    Ce problème est résolu dans cette version.

  • PR 2220008 : le démarrage réseau des machines virtuelles dans un réseau de grande taille peut échouer

    Le démarrage réseau des machines virtuelles limite la distance entre une machine virtuelle et le serveur de démarrage réseau à 15 routeurs. Si votre système dispose de davantage de routeurs sur le chemin entre une machine virtuelle et un serveur nécessaire au démarrage (PXE, DHCP, DNS, TFTP), le démarrage échoue, car la demande de démarrage n'atteint pas le serveur.

    Ce problème est résolu dans cette version. 

  • PR 2262288 : un hôte ESXi peut cesser de répondre en raison de demandes GET d'identifiant d'objet SNMPv3

    Chaque identifiant d'objet SNMPv3 peut recevoir des demandes GET bien qu'il y ait une authentification utilisateur. En conséquence, l'hôte ESXi peut cesser de répondre.

    Ce problème est résolu dans cette version.

  • PR 2290043 : vSphere Web Client ou vSphere Client peut afficher un profil d'hôte comme étant conforme même lorsqu'il a une valeur non conforme

    vSphere Web Client ou vSphere Client peut afficher un profil d'hôte comme étant conforme même lorsqu'il a une valeur non conforme telle que la taille de l'unité de transmission maximale (MTU). La correction du profil fonctionne comme prévu, mais il n'est pas reflété dans vSphere Web Client ou vSphere Client.

    Ce problème est résolu dans cette version.

  • PR 2295425 : les diagrammes de performances des hôtes ESXi peuvent disparaître par intermittence d'une application Web qui se connecte au système vCenter Server

    Vous pouvez arrêter par intermittence de voir des diagrammes de performances des hôtes ESXi dans l'instance intégrée de VMware Host Client ou dans n'importe quelle application Web qui se connecte au système vCenter Server, y compris vSphere Client et vSphere Web Client. Un problème interne entraîne la suppression des informations de compteurs de performance disponibles pour certains hôtes ESXi.

    Ce problème est résolu dans cette version.

  • PR 2300124 : un hôte ESXi n'utilise pas l'état de faible alimentation C2 sur les CPU AMD EPYC

    Même si les états C sont activés dans la configuration du microprogramme d'un hôte ESXi, VMkernel ne détecte pas correctement tous les états C. L'écran d'alimentation de l'outil esxtop affiche les colonnes %C0 (pourcentage de temps passé en état C0) et %C1 (pourcentage de temps passé en état C1), mais n'affiche pas la colonne %C2. Par conséquent, les performances du système par watt de puissance ne sont pas optimisées.

    Ce problème est résolu dans cette version.

  • PR 2303227 : si un hôte ESXi utilise une version spécifique du BIOS, un échec d'assertion peut se déclencher prématurément lors de la phase de démarrage de l'hôte

    Si un hôte ESXi dispose d'une version de BIOS spécifique, un échec d'assertion peut se produire au début de la phase de démarrage de l'hôte, et lorsque le BIOS est activé dans le BIOS. L'échec d'assertion est du type :
    Panic: ASSERT bora/vmkernel/vmkBoot/x86/vmkBootTxt.c:2235.

    Ce problème est résolu dans cette version. Pour les versions antérieures à la version 6.7 Update 3, désactivez Intel TXT dans le BIOS, s'il n'est pas requis. Une mise à niveau du BIOS peut également fonctionner.

  • PR 2301818 : un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une condition de concurrence

    Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une rare condition de concurrence lorsque l'hôte tente d'accéder à une zone de la mémoire dans l'intervalle exact où elle est libérée et allouée à une autre tâche.

    Ce problème est résolu dans cette version.

  • PR 2294347 : un hôte ESXi peut échouer avec un écran de diagnostic violet lorsque vous utilisez l'adaptateur iSCSI logiciel

    Lorsque vous utilisez l'adaptateur iSCSI logiciel, l'hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une condition de concurrence.

    Ce problème est résolu dans cette version.

  • PR 2338914 : des différences dans la spécification AHCI du pilote vmw_ahci et du microprogramme du contrôleur AHCI peuvent générer plusieurs erreurs

    Dans les charges de travail d'E/S lourdes, des différences dans la spécification AHCI du pilote vmw_ahci natif ESXi et du microprogramme du contrôleur AHCI tiers (tel que l'adaptateur DELL BOSS-S1) peuvent générer plusieurs erreurs, notamment des erreurs de pannes de stockage ou un écran de diagnostic violet.

    Ce problème est résolu dans cette version. 

  • PR 2327317 : les machines virtuelles peuvent perdre la connectivité lors de migrations entre clusters à l'aide de vSphere vMotion dans une installation NSX

    Les machines virtuelles peuvent perdre la connectivité lors de migrations entre clusters à l'aide de vSphere vMotion dans une installation NSX, car les filtres NetX peuvent bloquer le trafic vers les ports.

    Ce problème est résolu dans cette version.

  • PR 2312215 : la mise sous tension d'une machine virtuelle avec des fichiers VMDK sauvegardés par vSphere Virtual Volumes peut échouer lorsque vous la restaurez vers un snapshot

    Ce problème est spécifique aux banques de données vSphere Virtual Volumes lorsqu'un fichier VMDK est attribué à différentes cibles SCSI dans les snapshots. Le fichier de verrouillage du VMDK est réattribué sur différents snapshots et peut être supprimé de façon incorrecte lorsque vous restaurez la machine virtuelle vers un snapshot. En raison du fichier de verrouillage manquant, le disque ne s'ouvre pas et la machine virtuelle ne parvient pas à se mettre sous tension.

    Ce problème est résolu dans cette version.

  • PR 2331247 : le démarrage PXE d'une machine virtuelle avec un périphérique de réseau virtuel VMXNET3 à partir d'un serveur PVS (Citrix Provisioning Services) peut échouer

    Une machine virtuelle disposant de vNIC VMXNET3 ne peut pas démarrer à l'aide du démarrage de Citrix PVS. Cela est dû aux interruptions en attente sur le périphérique réseau virtuel qui ne sont pas gérées correctement lors de la transition du démarrage PXE au démarrage du système d'exploitation invité. Par conséquent, le système d'exploitation invité ne peut pas démarrer le périphérique réseau virtuel et le démarrage de la machine virtuelle échoue également.

    Ce problème est résolu dans cette version. Le correctif efface toutes les interruptions en attente et toutes les interruptions INTx de masque lors du démarrage du périphérique virtuel.

  • PR 2340952 : les tailles d'anneau Rx et Tx personnalisées des cartes réseau physiques peuvent ne pas être persistantes lors des redémarrages d'hôtes ESXi

    Si vous personnalisez les tailles d'anneau Rx et Tx des cartes réseau physiques pour améliorer les performances du réseau en utilisant les commandes suivantes :
    esxcli network nic ring current set -n -t
    esxcli network nic ring current set -n -r
    les paramètres peuvent ne pas être persistants lors des redémarrages d'hôtes ESXi.

    Ce problème est résolu dans cette version. Avec ce correctif, vous pouvez rendre ces configurations ESXCLI persistantes lors des redémarrages en effectuant une écriture dans le fichier de configuration ESXi. La configuration de la taille d'anneau doit être autorisée sur les cartes réseau physiques avant toute utilisation de la CLI.

  • PR 2366745 : macOS 10.15 Developer Preview risque de ne pas démarrer sur une machine virtuelle

    Lorsque vous démarrez macOS 10.15 Developer Preview sur une machine virtuelle, le système d'exploitation peut échouer avec un écran vide affichant un logo Apple blanc. Une opération de mise sous tension en mode détaillé cesse de répondre après l'affichage du message d'erreur suivant :
    Erreur lors de la désérialisation de l'utilitaire de prelink plist : OSUnserializeXML : erreur de syntaxe à proximité de la ligne 2
    panic(...): « Pilote pour cette plate-forme introuvable : \"ACPI\".\n »@...

    Ce problème est résolu dans cette version. Pour que le correctif s'applique, vous devez mettre hors tension les machines virtuelles existantes avant de procéder à la mise à niveau vers macOS 10.15 Developer Preview.

  • PR 2331525 : Si vous définissez NetworkNicTeamingPolicy ou SecurityPolicy pour utiliser les paramètres par défaut, vous risquez de ne pas pouvoir appliquer un profil d'hôte

    Si vous modifiez NetworkNicTeamingPolicy ou SecurityPolicy d'un profil d'hôte pour revenir aux paramètres par défaut, vous risquez de ne pas pouvoir appliquer le profil d'hôte à un hôte ESXi et d'obtenir une erreur de ce type : Erreur : un paramètre spécifié n'était pas correct.

    Ce problème est résolu dans cette version.

  • PR 2320309 : lorsqu'une opération vMotion échoue et est immédiatement suivie d'une opération d'ajout à chaud ou Storage vMotion, l'hôte ESXi peut échouer avec un écran de diagnostic violet

    Si la taille de l'unité de transmission maximale (MTU) d'un commutateur virtuel est inférieure à la taille MTU configurée pour le port VMkernel, les opérations vMotion peuvent échouer. Si une opération vMotion est immédiatement suivie d'une opération d'ajout à chaud ou Storage vMotion, l'hôte ESXi peut échouer avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version.

  • PR 2304092 : un périphérique réseau virtuel VMXNET3 peut obtenir des propriétés nulles pour les adresses MAC de certaines interfaces de machine virtuelle

    La taille maximale de segment de mémoire pour n'importe quel module est de 3 Go. Si la taille de la mémoire totale demandée est supérieure à 4 Go, un dépassement de capacité pour un entier se produit. Par conséquent, les adresses MAC des interfaces de machine virtuelle sont définies sur 00:00:00:00:00:00 et le périphérique VMXNET3 peut ne pas démarrer. Dans le journal VMkernel, vous pouvez voir une erreur semblable à celle-ci : Vmxnet3: 15204: Allocation de la mémoire échouée pour tq 0.

    Ce problème est résolu dans cette version.

  • PR 2241121 : lors de l'exportation de machines virtuelles en tant que fichiers OVF à l'aide de VMware Host Client, des fichiers de disque VMDK pour différentes machines virtuelles possèdent le même préfixe

    Lors de l'exportation de plusieurs machines virtuelles vers un dossier, les noms VMDK peuvent être en conflit et être automatiquement renommés par le navigateur Web. Cela rend les fichiers OVF exportés non valides.

    Ce problème est résolu dans cette version. Les noms des fichiers VMDK exportés sont désormais basés sur le nom de la machine virtuelle.

  • PR 2306836 : une opération de mise à niveau ou de migration d'un hôte ESXi peut échouer avec un écran de diagnostic violet

    Si vous utilisez une instance de vSphere Distributed Switch ou une instance de vSphere Distributed Switch gérée par NSX-T avec une fonctionnalité de conteneur activée, et si votre hôte ESXi est de version 6.7 ou de version antérieure, lors d'une opération de mise à niveau ou de migration, l'hôte ESXi peut échouer avec un violet écran de diagnostic.

    Ce problème est résolu dans cette version.

  • PR 2343913 : vous devez ajouter manuellement les règles de réclamation à un hôte ESXi

    Vous devez ajouter manuellement les règles de réclamation à un hôte ESXi pour les baies de stockage Tegile afin de définir le paramètre Opérations d'E/S par seconde sur 1.

    Ce problème est résolu dans cette version. Le correctif définit le plug-in SATP (Storage Array Type Plug-in) dans les hôtes ESXi version 6.5 et 6.7 pour les baies de stockage Tegile sur :
    esxcli storage nmp satp rule add -s VMW_SATP_ALUA -V TEGILE -M "INTELLIFLASH" -c tpgs_on --psp="VMW_PSP_RR" -O "iops=1" -e "Tegile arrays with ALUA support"
    esxcli storage nmp satp rule add -s VMW_SATP_DEFAULT_AA -V TEGILE -M "INTELLIFLASH" -c tpgs_off --psp="VMW_PSP_RR" -O "iops=1" -e "Tegile arrays without ALUA support"'''

  • PR 2361711 : lors du provisionnement de clones instantanés, un message d'erreur peut s'afficher et la mise sous tension des machines virtuelles peut échouer

    Lors du provisionnement de clones instantanés dans vSphere Web Client ou vSphere Client, l'erreur Déconnecté de la machine virtuelle peut s'afficher. Les machines virtuelles ne peuvent pas être mises sous tension, car le processus d'exécution de la machine virtuelle (VMX) échoue.

    Ce problème est résolu dans cette version. Le correctif corrige l'incident VMX Panic et renvoie une erreur.

  • PR 2350171 : si vous exécutez l'utilitaire kdump alors que vIOMMU est activé, le système d'exploitation invité Linux dans un hôte ESXi peut cesser de répondre

    Si vIOMMU est activé, le système d'exploitation invité Linux peut cesser de répondre lors de l'initialisation du noyau kdump.

    Ce problème est résolu dans cette version.

  • PR 2297765 : La suppression de disques ne déclenche pas StorageHealthAlarm sur le système vCenter Server

    Un hôte ESXi risque de ne pas parvenir à surveiller la santé de l'adaptateur de bus hôte (HBA) LSI et du stockage attaché. Par conséquent, le système vCenter Server ne peut pas afficher d'alarme lorsque la santé HBA est dégradée. Vous devez installer le fournisseur tiers LSI SMI-S CIM. Pour plus d'informations, reportez-vous à l'article 2001549 de la base de connaissances VMware.

    Ce problème est résolu dans cette version.

  • PR 2355516 : un appel API pour configurer le nombre de files d'attente et de mondes d'un pilote peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet

    Vous pouvez utiliser la méthode SCSIBindCompletionWorlds() pour définir le nombre de files d'attente et de mondes d'un pilote. Cependant, si vous définissez le paramètre numQueues sur une valeur supérieure à 1 et que le paramètre numWorlds est égal ou inférieur à 1, l'appel d'API peut retourner sans libérer le verrou maintenu. Cela entraîne un blocage et l'hôte ESXi peut échouer avec un écran de diagnostic violet.

    Le problème est résolu dans cette version.

  • PR 2287232 : les machines virtuelles avec Microsoft Windows 10 Version 1809 peuvent démarrer lentement ou cesser de répondre pendant la phase de démarrage si elles sont en cours d'exécution sur une banque de données VMFS6

    Si une machine virtuelle fonctionne avec Windows 10 Version 1809, possède des snapshots et s'exécute sur une banque de données VMFS6, elle peut démarrer lentement ou cesser de répondre pendant la phase de démarrage.

    Ce problème est résolu dans cette version.

  • PR 2310826 : un hôte ESXi peut échouer avec un écran de diagnostic violet en cas d'échec intermittent de la connectivité aux banques de données NFS41

    Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une erreur NullPointerException dans l'exécution des E/S lorsque la connectivité aux banques de données NFS41 échoue par intermittence.

    Ce problème est résolu dans cette version.

  • PR 2332785 : un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'un absence de pulsation de CPU physique

    Si vous utilisez un hôte ESXi avec le modèle de lecteur de CD-ROM DU-8A5LH, le lecteur de CD-ROM peut signaler une exception Frame Information Structure (FIS) inconnue. Le pilote vmw_ahci ne gère pas l'exception correctement et crée des journaux d'exceptions PORT_IRQ_UNK_FIS répétés dans le noyau. Les journaux répétés provoquent une absence de pulsation de CPU physique et l'hôte ESXi peut échouer avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version.

  • PR 2280742 : une corruption du segment de mémoire d'un commutateur virtuel DvFilter peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet

    Une condition de concurrence dans les opérations de règle de pare-feu get-set pour les commutateurs virtuels DvFilter peut entraîner un débordement de tampon et une corruption du segment de mémoire. Par conséquent, un hôte ESXi peut échouer avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version.

  • PR 2386930 : les applications risquent de ne pas être disponibles sur les hôtes ESXi de destination après la migration de machines virtuelles disposant de vGPU NVIDIA GRID configurés

    Une corruption de la mémoire peut se produire lors de la migration à chaud du calcul et du stockage de machines virtuelles disposant de vGPU NVIDIA GRID. La migration réussit, mais les applications en cours d'exécution peuvent ne pas reprendre sur l'hôte de destination. 

    Ce problème est résolu dans cette version.

  • PR 2333442 : la mise sous tension de machines virtuelles peut échouer lorsque le nombre de périphériques virtuels dépasse la limite maximale

    La mise sous tension de machines virtuelles configurées avec un nombre maximal de périphériques virtuels et relais PCI peut échouer si la limite est dépassée.
    Le problème est identifié par un journal de panique dans le fichier vmware.log semblable à celui-ci : vmx| E105: PANIC: VERIFY bora/devices/pci/pci.c:1529.

    Ce problème est résolu dans cette version.

  • PR 2346582 : lorsque vous mettez à jour vos hôtes ESXi depuis la version 6.7 ou 6.7 Update 1, y compris les versions de correctifs, vers la version 6.7 Update 2 ou toute autre version de correctif 6.7 Update 2, et si un serveur utilise des CPU Intel Skylake, le démarrage rapide est annulé et l'hôte ESXi effectue un redémarrage complet du système

    ESXi 6.7 Update 2 introduit un correctif relatif à l'errata d'Intel pour les CPU Skylake. Le correctif a un impact sur la configuration matérielle et certains contrôles de santé sont déclenchés, de sorte que l'hôte ESXi effectue un redémarrage complet du système au lieu d'un démarrage rapide. Ce problème ne se produit qu'une seule fois, lors d'une mise à jour des hôtes ESXi depuis une version sans correctif vers une version incluant ce correctif, et lorsque le démarrage rapide est activé pour cette mise à jour.

    Ce problème est résolu dans cette version. Avec ce correctif, lorsque vous mettez à jour vos hôtes ESXi de la version 6.7 ou 6.7 Update 1 vers la version 6.7 Update 3, les hôtes ESXi effectuent un démarrage rapide sur les serveurs disposant de CPU Intel Skylake.

  • PR 2214222 : Xorg risque de ne pas parvenir à démarrer sur des systèmes disposant de plusieurs GPU

    Plusieurs scripts Xorg peuvent s'exécuter en parallèle et interférer entre eux. Par conséquent, le démarrage du script Xorg peut échouer sur les systèmes disposant de plusieurs GPU.

    Ce problème est résolu dans cette version. Le correctif garantit qu'un seul script Xorg s'exécute pendant les opérations de démarrage.

  • PR 2335847 : les périphériques ConnectX5 Mellanox peuvent signaler que la négociation automatique n'est pas active bien que cette fonctionnalité soit activée

    Lorsque vous utilisez la commande esxcli network nic get -n vmnicX pour obtenir l'état de négociation automatique sur des périphériques Mellanox ConnectX5, vous pouvez voir l'état False même si la fonctionnalité est activée sur le commutateur physique.

    Ce problème est résolu dans cette version.

  • PR 2334911 : lorsque vous configurez le groupe d'agrégation de liens (LAG), si un membre du bundle bascule, un message d'observation VMkernel incorrect peut s'afficher

    Lorsque vous configurez le LAG, si un membre du bundle bascule, un message d'observation VMkernel incorrect peut s'afficher pour le LAG : Critères en échec : 0.

    Ce problème est résolu dans cette version.

  • PR 2366640 : Si le nom de la liaison montante n'est pas au format vmnicX, où X est un nombre, le protocole LACP (Link Aggregation Control Protocol) ne fonctionne pas

    Si le nom de la liaison montante n'est pas au format vmnicX, où X est un nombre, LACP ne fonctionne pas.

    Ce problème est résolu dans cette version.

  • PR 2292419 : lorsque le test de récupération Site Recovery Manager déclenche une phase de synchronisation vSphere Replication, hostd peut cesser de répondre

    Lorsque vous mettez en veille les machines virtuelles qui exécutent Microsoft Windows Server 2008 ou version ultérieure, les snapshots de l'application mise au repos sont créés. Le nombre maximal de snapshots simultanés est de 32, ce qui est trop élevé, car un trop grand nombre de threads est utilisé dans le suivi des tâches de l'opération de snapshot. Par conséquent, le service hostd peut cesser de répondre.

    Ce problème est résolu dans cette version. Le correctif réduit le nombre maximal de snapshots simultanés à 8.

  • PR 2132634 : le service hostd échoue parfois lors de la recomposition de pools VDI et crée un hostd-worker-zdump

    Le service hostd échoue parfois lors de la recomposition de pools VDI, avec le message d'erreur VmfsExtentCommonOpen : VmfsExtentParseExtentLine a échoué. Vous pouvez voir des fichiers hostd-Worker-zdump générés dans le répertoire /var/core/ de l'hôte ESXi.

    Ce problème est résolu dans cette version.

  • PR 2363202 : Les services de surveillance indiquent que les machines virtuelles d'une banque de données vSphere Virtual Volumes sont dans un état critique

    Dans vSphere Web Client, une latence de lecture ou d'écriture incorrecte s'affiche pour les graphiques de performances des banques de données vSphere Virtual Volumes au niveau d'une machine virtuelle. Par conséquent, le service de surveillance indique que les machines virtuelles sont dans un état critique.

    Ce problème est résolu dans cette version.

  • PR 2367669 : lors de la décompression de sa page de mémoire, une machine virtuelle peut cesser de répondre et redémarrer

    Lors de la décompression de la page mémoire d'une machine virtuelle s'exécutant sur ESXi 6.7, la vérification de la taille de la fenêtre de compression peut échouer. En conséquence, la machine virtuelle peut cesser de répondre et redémarrer. Dans la trace de débogage du journal VMkernel, vous pouvez voir des entrées semblables à :
    Unable to decompress BPN(0x1005ef842) from frameIndex(0x32102f0) block 0 for VM(6609526)

    0x451a55f1baf0:[0x41802ed3d040]WorldPanicWork
    0x451a55f1bb50:[0x41802ed3d285]World_Panic
    0x451a55f1bcc0:[0x41802edb3002]VmMemIO_FaultCompressedPage
    0x451a55f1bd20:[0x41802edbf72f]VmMemPfCompressed
    0x451a55f1bd70:[0x41802edc033b]VmMemPfInt
    0x451a55f1be10:[0x41802edc0d4f]VmMemPf
    0x451a55f1be80:[0x41802edc108e]VmMemPfLockPageInt
    0x451a55f1bef0:[0x41802edc3517]VmMemPf_LockPage
    0x451a55f1bfa0:[0x41802ed356e6]VMMVMKCall_Call
    0x451a55f1bfe0:[0x41802ed59e5d]VMKVMM_ArchEnterVMKernel

    Ce problème est résolu dans cette version.

  • PR 2303016 : le test de récupération avec VMware Site Recovery Manager peut échouer avec une erreur DiskQueue est saturé

    Le nombre de contextes simultanés du gestionnaire de ressources d'un hôte ESXi peut dépasser le maximum de 512 en raison d'une erreur dans la logique de répartition. En cas de ralentissement d'hôte secondaire ou de problèmes réseau, cela peut provoquer des erreurs DiskQueue est saturé et l'échec de la synchronisation de machines virtuelles dans des opérations exécutées par Site Recovery Manager.

    Ce problème est résolu dans cette version.

  • PR 2337889 : si vous ne configurez pas de route par défaut dans un hôte ESXi, les interruptions SNMP sont envoyées avec une charge utile dans laquelle la séquence d'adresses IP de l'agent SNMP ESXi est dans l'ordre inverse

    Si vous ne configurez pas de route par défaut dans l'hôte ESXi, l'adresse IP de l'agent SNMP ESXi peut être en ordre inverse dans la charge utile des interruptions SNMP envoyées. Par exemple, si l'agent SNMP dispose de l'adresse IP 172.16.0.10, dans la charge utile l'adresse IP est 10.0.16.172. Par conséquent, les interruptions SNMP atteignent la cible avec une adresse IP incorrecte de l'agent SNMP ESXi dans la charge utile.

    Ce problème est résolu dans cette version.

  • PR 2360408 : Lorsque des applications qui utilisent l'accélération logicielle 3D s'exécutent sur une machine virtuelle, la machine virtuelle peut cesser de répondre

    Si une machine virtuelle exécute des applications qui utilisent un état 3D et des nuanciers particuliers, et si l'accélération 3D logicielle est utilisée, la machine virtuelle peut cesser de répondre.

    Ce problème est résolu dans cette version.

  • PR 2344159 : lorsque le total de contrôle IPv6 est activé et qu'un hôte EXSi reçoit un paquet IPv6 avec des en-têtes d'extension de routage, l'hôte ESXi peut échouer avec un écran de diagnostic violet

    Lorsque l'invité envoie un déchargement de total de contrôle IPv6 avec des en-têtes de routage activés, l'hôte ESXi peut échouer avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, désactivez le déchargement de total de contrôle sur le vNIC.

  • PR 2331369 : lorsqu'un hôte ESXi supprime une indication PShare avec la fonction VmMemCow_PShareRemoveHint, l'hôte ESXi peut échouer avec un écran de diagnostic violet

    Lorsqu'un hôte ESXi supprime un conseil PShare d'une chaîne PShare, si la chaîne PShare est endommagée, l'hôte ESXi peut échouer avec un écran de diagnostic violet et une erreur semblable à :
    0x43920bd9bdc0:[0x41800c5930d6]VmMemCow_PShareRemoveHint
    0x43920bd9be00:[0x41800c593172]VmMemCowPFrameRemoveHint
    0x43920bd9be30:[0x41800c594fc8]VmMemCowPShareFn@vmkernel
    0x43920bd9bf80:[0x41800c500ef4]VmAssistantProcessTasks@vmkernel
    0x43920bd9bfe0:[0x41800c6cae05]CpuSched_StartWorld@vmkernel

    Ce problème est résolu dans cette version.

  • PR 2370239 : lorsqu'une machine virtuelle utilise un port série distant, si une panne DNS se produit pendant une migration, la machine virtuelle peut être mise hors tension

    Lorsqu'une machine virtuelle utilise un port série distant connecté à un concentrateur de ports série virtuel (vSPC), où un nom DNS est l'adresse du vSPC, si une panne de DNS se produit lors d'une migration à l'aide de vMotion, la machine virtuelle peut être mise hors tension.

    Ce problème est résolu dans cette version.

  • PR 2367142 : si vous modifiez la compatibilité matérielle d'une machine virtuelle, les périphériques relais PCI peuvent être supprimés

    Lorsque vous modifiez le niveau de compatibilité matérielle d'une machine virtuelle avec un périphérique relais PCI, le périphérique peut être retiré de la machine virtuelle pendant la procédure.

    Le problème est résolu dans cette version.

  • PR 2336379 : lorsque vous définissez l'alias de la carte réseau physique (pNIC), le mappage des liaisons montantes dans le fichier de configuration ESXi peut être incorrect

    Lorsque vous utilisez la ligne de commande et exécutez la commande pour définir l'alias pNIC, l'adresse MAC enregistrée dans esx.conf pour le pNIC correspondant est incorrecte. La commande que vous utilisez est la suivante :
    localcli --plugin-dir /usr/lib/vmware/esxcli/int/ deviceInternal alias store --bus-type pci --alias vmnicX --bus-address XX.

    Ce problème est résolu dans cette version.

  • PR 2301231 : un hôte ESXi ne parvient pas à détecter les périphériques locaux après la mise à niveau de vSphere 6.0 vers une version ultérieure

    Ce problème se produit uniquement lorsque le SATP est VMW_SATP_LOCAL. Dans ESXi 6.0, si une règle de réclamation SATP avec SATP défini sur VMW_SATP_LOCAL est ajoutée avec une option de configuration mal formatée, les plug-ins NMP/SATP ne reconnaissent pas l'option et ne parviennent pas à détecter le périphérique lors de la mise à niveau vers une version ultérieure d'ESXi.
    Les journaux peuvent contenir des entrées semblables aux entrées suivantes :
    2018-11-20T02:10:36.333Z cpu1:66089)WARNING: NMP: nmp_DeviceAlloc:2048: nmp_AddPathToDevice failed Bad parameter (195887111).
    2018-11-20T02:10:36.333Z cpu1:66089)WARNING: ScsiPath: 6615: Plugin 'NMP' had an error (Bad parameter) while claiming path 'vmhba0:C0:T2:L0'. Skipping the path

    Ce problème est résolu dans cette version.

  • PR 2280742 : une corruption du segment de mémoire d'un commutateur virtuel DvFilter peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet

    Une condition de concurrence dans les opérations get-set de règle de pare-feu pour les commutateurs virtuels DvFilter peut entraîner un débordement de mémoire tampon et une corruption du segment de mémoire. Par conséquent, un hôte ESXi peut échouer avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version.

  • PR 2354762 : un état de santé du matériel du système vCenter Server peut ne pas afficher les échecs sur les barrettes DIMM

    Un état de santé du matériel du système vCenter Server peut ne pas afficher les échecs sur les barrettes DIMM, que les contrôleurs de serveur affichent ou non un avertissement. Par exemple, le contrôleur d'accès à distance Dell dans un système Dell M630 Server peut afficher un avertissement dans un module DIMM, mais vous ne voyez aucune alerte ou alarme dans votre système vCenter Server.

    Ce problème est résolu dans cette version.

  • PR 2394247 : vous ne pouvez pas configurer les machines virtuelles pour qu'elles effectuent un cycle d'alimentation lors du redémarrage du système d'exploitation invité

    Après la mise à jour du microcode, il est parfois nécessaire d'énumérer de nouveau le CPUID des machines virtuelles sur un serveur ESXi. À l'aide du paramètre de configuration vmx.reboot.powerCycle=TRUE, vous pouvez planifier l'exécution d'un cycle d'alimentation par les machines virtuelles si nécessaire.

    Ce problème est résolu dans cette version.

  • PR 2402409 : les machines virtuelles dont le suivi de blocs modifiés (CBT) est activé peuvent échouer lors de la création d'un snapshot en raison de l'absence de mémoire allouée pour la carte de bits CBT

    Lors de la création d'un snapshot, une machine virtuelle peut être mise hors tension et échouer avec une erreur semblable à celle-ci :
    2019-01-01T01:23:40.047Z| vcpu-0| I125: DISKLIB-CTK : Failed to mmap change bitmap of size 167936: Cannot allocate memory.
    2019-01-01T01:23:40.217Z| vcpu-0| I125: DISKLIB-LIB_BLOCKTRACK : Impossible d'ouvrir le suivi des modifications /vmfs/volumes/DATASTORE_UUID/VM_NAME/VM_NAME_1-ctk.vmdk: Mémoire insuffisante pour le suivi des modifications.
    L'erreur est due à un manque de mémoire allouée pour la carte de bits CBT.

    Ce problème est résolu dans cette version.

  • PR 2322882 : Un hôte ESXi peut cesser de répondre en raison d'un problème de mémoire dans vSphere Storage I/O Control de VMware vSphere 6.7 

    En raison d'un problème de mémoire dans vSphere Storage I/O Control, un hôte ESXi peut cesser de répondre et le fichier /var/log/vmkernel.log contient les éléments suivants :
    MemSchedAdmit: 470: Admission failure in path: sioc/storageRM.13011002/uw.13011002
    MemSchedAdmit: 477: uw.13011002 (68246725) extraMin/extraFromParent: 256/256, sioc (840) childEmin/eMinLimit: 14059/14080

    Ce problème est résolu dans cette version.

  • PR 2482603 : Si vous disposez de cartes réseau physiques qui prennent en charge SR-IOV et d'autres qui ne le prennent pas en charge sur le même hôte ESXi, vous pouvez voir des informations différentes à partir de l'ensemble de commandes EXCLI et dans vSphere Client

    Si le même pilote de carte réseau sur un hôte ESXi dispose de cartes réseau physiques qui ne prennent pas en charge SR-IOV et d'autres qui prennent en charge SR-IOV, vous pouvez voir des informations différentes à partir de l'ensemble de commandes EXCLI et dans vSphere Client ou vSphere Web Client. Par exemple, dans l'ensemble de commandes ESXCLI, vous pouvez voir que les vmnic 16, 17 et 18 disposent de SR-IOV configuré, alors que dans vSphere Client vous pouvez voir que SR-IOV est configuré sur vmnic 6, 7 et 8.

    Ce problème est résolu dans cette version.

ESXi670-201908202-UG
Catégorie des correctifs Correctif de bogues
Gravité des correctifs Important
Redémarrage de l'hôte requis Oui
Migration ou arrêt de la machine virtuelle requis Oui
Matériel concerné S.O.
Logiciels concernés S.O.
VIB inclus
  • VMW_bootbank_igbn_0.1.1.0-5vmw.670.3.73.14320388
PR résolus  S.O.
Numéros CVE S.O.

Ce correctif met à jour le VIB igbn.

    ESXi670-201908203-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_nvme_1.2.2.28-1vmw.670.3.73.14320388
    PR résolus  2305414 
    Numéros CVE S.O.

    Ce correctif met à jour le VIB nvme afin de résoudre le problème suivant :

    • Mise à jour du pilote NVMe

      La mise à jour du pilote NVMe résout le problème de surcharge de performances sur les périphériques qui s'exécutent sur la série P4600 Intel SSD DC.

    ESXi670-201908204-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMware_bootbank_qlnativefc_3.1.8.0-5vmw.670.3.73.14320388
    PR résolus  2305410
    Numéros CVE S.O.

    Ce correctif met à jour le VIB qlnativefc afin de résoudre le problème suivant :

    • Mise à jour du pilote qlnativefc

      Le pilote qlnativefc est mis à jour vers la version 3.1.8.0.

    ESXi670-201908205-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_lsi-mr3_7.708.07.00-3vmw.670.3.73.14320388
    PR résolus  2305404
    Numéros CVE S.O.

    Ce correctif met à jour le VIB lsi-mr3 afin de résoudre le problème suivant :

    • Mise à jour du pilote lsi_mr3

      Le pilote lsi_mr3 est mis à jour vers la version MR 7.8.

    ESXi670-201908206-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_lsi-msgpt35_09.00.00.00-5vmw.670.3.73.14320388
    PR résolus  2305406 
    Numéros CVE S.O.

    Ce correctif met à jour le VIB lsi-msgpt35 afin de résoudre le problème suivant :

    • Mise à jour du pilote lsi_msgpt35

      Le pilote lsi_msgpt35 est mis à jour vers la version 09.00.00.00-5vmw.

    ESXi670-201908207-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_lsi-msgpt3_17.00.02.00-1vmw.670.3.73.14320388
    PR résolus  2335120
    Numéros CVE S.O.

    Ce correctif met à jour le VIB lsi-msgpt3 afin de résoudre le problème suivant :

    • mise à jour du pilote lsi_msgpt3

      Le pilote lsi_msgpt3 est mis à jour vers la version 17.00.02.00-1vmw.

    ESXi670-201908208-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_lsi-msgpt2_20.00.06.00-2vmw.670.3.73.14320388
    PR résolus  2305407
    Numéros CVE S.O.

    Ce correctif met à jour le VIB lsi-msgpt2 afin de résoudre le problème suivant :

    • mise à jour du pilote lsi_msgpt2

      Le pilote lsi_msgpt2 est mis à jour vers la version 20.00.06.00-2.

    ESXi670-201908209-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_i40en_1.8.1.9-2vmw.670.3.73.14320388
    PR résolus  2315656 
    Numéros CVE S.O.

    Ce correctif met à jour le VIB i40en.

    • Mise à jour du pilote i40en

      Le pilote i40en est mis à jour vers la version 1.8.1.9-2.

    ESXi670-201908210-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_ixgben_1.7.1.16-1vmw.670.3.73.14320388
    PR résolus  2315652 
    Numéros CVE S.O.

    Ce correctif met à jour le VIB ixgben afin de résoudre le problème suivant :

    • Le pilote ixgben ajoute le couplage de file d'attente pour optimiser l'efficacité du CPU.

    ESXi670-201908211-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_smartpqi_1.0.1.553-28vmw.670.3.73.14320388
    PR résolus  2305412 
    Numéros CVE S.O.

    Ce correctif met à jour le VIB smartpqi afin de résoudre le problème suivant :

    • mise à jour du pilote smartpqi

      Le pilote smartpqi est mis à jour vers la version 1.0.1.553-28.

    ESXi670-201908212-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_bnxtnet_20.6.101.7-24vmw.670.3.73.14320388
    PR résolus  2315684 
    Numéros CVE S.O.

    Ce correctif met à jour le VIB bnxtnet afin de résoudre le problème suivant :

    • ESXi 6.7 Update 3 ajoute la prise en charge des adaptateurs réseau Broadcom 100G et du flux multi-RSS au pilote bnxtnet.

    ESXi670-201908213-UG
    Catégorie des correctifs Correctif de bogues
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_elxnet_11.4.1097.0-5vmw.670.3.73.14320388
    PR résolus  2323424 
    Numéros CVE S.O.

    Ce correctif met à jour le VIB elxnet afin de résoudre le problème suivant :

    • PR 2323424 : dans de rares cas, les cartes réseau qui utilisent un pilote elxnet peuvent perdre la connectivité  

      Un problème avec le pilote elxnet peut entraîner une perte de connectivité des cartes réseau qui utilisent ce pilote. Dans les journaux du noyau de l'hôte ESXi, des avertissements semblables à ceux-ci peuvent s'afficher : 
      WARNING: elxnet: elxnet_workerThread:2122: [vmnic3] GetStats: MCC cmd timed out. timeout:36
      WARNING: elxnet: elxnet_detectDumpUe:416: [vmnic3] Recoverable HW error detected

      Ce problème est résolu dans cette version.

    ESXi670-201908214-UG
    Catégorie des correctifs Amélioration
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_brcmfcoe_11.4.1078.25-14vmw.670.3.73.14320388
    PR résolus  S.O.
    Numéros CVE S.O.

    Ce correctif met à jour le VIB brcmfcoe.

      ESXi670-201908215-UG
      Catégorie des correctifs Amélioration
      Gravité des correctifs Important
      Redémarrage de l'hôte requis Oui
      Migration ou arrêt de la machine virtuelle requis Oui
      Matériel concerné S.O.
      Logiciels concernés S.O.
      VIB inclus
      • VMW_bootbank_lpfc_11.4.33.25-14vmw.670.3.73.14320388
      PR résolus  S.O.
      Numéros CVE S.O.

      Ce correctif met à jour le VIB lpfc.

        ESXi670-201908216-UG
        Catégorie des correctifs Amélioration
        Gravité des correctifs Important
        Redémarrage de l'hôte requis Oui
        Migration ou arrêt de la machine virtuelle requis Oui
        Matériel concerné S.O.
        Logiciels concernés S.O.
        VIB inclus
        • VMW_bootbank_nenic_1.0.29.0-1vmw.670.3.73.14320388
        PR résolus  2328263 
        Numéros CVE S.O.

        Ce correctif met à jour le VIB nenic afin de résoudre le problème suivant :

        • Mise à jour du pilote nenic

          Le pilote nenic est mis à jour vers la version 1.0.29.0.

        ESXi670-201908217-UG
        Catégorie des correctifs Correctif de bogues
        Gravité des correctifs Important
        Redémarrage de l'hôte requis Oui
        Migration ou arrêt de la machine virtuelle requis Oui
        Matériel concerné S.O.
        Logiciels concernés S.O.
        VIB inclus
        • VMW_bootbank_vmw-ahci_1.2.8-1vmw.670.3.73.14320388
        PR résolus  2332785, 2338914
        Numéros CVE S.O.

        Ce correctif met à jour le VIB vmw-ahci.

          ESXi670-201908218-UG
          Catégorie des correctifs Correctif de bogues
          Gravité des correctifs Important
          Redémarrage de l'hôte requis Oui
          Migration ou arrêt de la machine virtuelle requis Oui
          Matériel concerné S.O.
          Logiciels concernés S.O.
          VIB inclus
          • VMW_bootbank_nmlx5-core_4.17.13.1-1vmw.670.3.73.14320388
          PR résolus  S.O.
          Numéros CVE S.O.

          Ce correctif met à jour le VIB nmlx5-core.

            ESXi670-201908219-UG
            Catégorie des correctifs Amélioration
            Gravité des correctifs Important
            Redémarrage de l'hôte requis Oui
            Migration ou arrêt de la machine virtuelle requis Oui
            Matériel concerné S.O.
            Logiciels concernés S.O.
            VIB inclus
            • VMW_bootbank_nfnic_4.0.0.29-0vmw.670.3.73.14320388
            PR résolus  S.O.
            Numéros CVE S.O.

            Ce correctif met à jour le VIB nfnic.

              ESXi670-201908220-UG
              Catégorie des correctifs Correctif de bogues
              Gravité des correctifs Important
              Redémarrage de l'hôte requis Non
              Migration ou arrêt de la machine virtuelle requis Non
              Matériel concerné S.O.
              Logiciels concernés S.O.
              VIB inclus
              • VMware_bootbank_esx-xserver_6.7.0-3.73.14320388
              PR résolus  2214222 
              Numéros CVE S.O.

              Ce correctif met à jour le VIB esx-xserver.

                ESXi670-201908221-UG
                Catégorie des correctifs Correctif de bogues
                Gravité des correctifs Important
                Redémarrage de l'hôte requis Oui
                Migration ou arrêt de la machine virtuelle requis Oui
                Matériel concerné S.O.
                Logiciels concernés S.O.
                VIB inclus
                • VMW_bootbank_sfvmk_1.0.0.1003-6vmw.670.3.73.14320388
                PR résolus  S.O.
                Numéros CVE S.O.

                Ce correctif met à jour le VIB sfvmk.

                  ESXi670-201908101-SG
                  Catégorie des correctifs Sécurité
                  Gravité des correctifs

                  Important
                  Redémarrage de l'hôte requis Oui
                  Migration ou arrêt de la machine virtuelle requis Oui
                  Matériel concerné S.O.
                  Logiciels concernés S.O.
                  VIB inclus
                  • VMware_bootbank_esx-base_6.7.0-2.69.14141615
                  • VMware_bootbank_esx-update_6.7.0-2.69.14141615
                  • VMware_bootbank_vsan_6.7.0-2.69.13808269
                  • VMware_bootbank_vsanhealth_6.7.0-2.69.13808270
                  PR résolus  2307421, 2360047, 2300903, 2262288, 2313239
                  Numéros CVE S.O.

                  Ce correctif met à jour les VIB esx-base, esx-update, vsan et vsanhealth pour résoudre les problèmes suivants :

                  • Mise à jour du démon Network Time Protocol (NTP)

                    Le démon NTP est mis à jour vers la version ntp-4.2.8p13.

                  • Mise à jour de la bibliothèque libcurl

                    La bibliothèque ESXi userworld libcurl est mise à jour vers la version 7.64.1.

                  • PR 2262288 : les hôtes ESXi peuvent répondre à toutes les demandes get snmpv3 à partir d'ID d'utilisateur OID (Object Identifier), même s'ils ne sont pas authentifiés

                    Les hôtes ESXi peuvent répondre à toutes les demandes get snmpv3 de l'utilisateur spécial "", qui est utilisé pour la découverte d'ID de moteur, même si l'utilisateur n'est pas authentifié ou mal authentifié.

                    Le problème est résolu dans cette version.

                  • Mise à jour de la bibliothèque libxml2

                    La bibliothèque ESXi userworld libxml2 a été mise à jour vers la version 2.9.9.

                  • Mise à jour de la bibliothèque Python

                    La bibliothèque tierce Python est mise à jour vers la version 3.5.7.

                  ESXi670-201908102-SG
                  Catégorie des correctifs Sécurité
                  Gravité des correctifs

                  Important
                  Redémarrage de l'hôte requis Non
                  Migration ou arrêt de la machine virtuelle requis Non
                  Matériel concerné S.O.
                  Logiciels concernés S.O.
                  VIB inclus
                  • VMware_locker_tools-light_10.3.10.12406962-14141615
                  PR résolus  2313239
                  Numéros CVE S.O.

                  Ce correctif met à jour le VIB tools-light.

                    ESXi670-201908103-SG
                    Catégorie des correctifs Sécurité
                    Gravité des correctifs

                    Important
                    Redémarrage de l'hôte requis Non
                    Migration ou arrêt de la machine virtuelle requis Non
                    Matériel concerné S.O.
                    Logiciels concernés S.O.
                    VIB inclus
                    • VMware_bootbank_cpu-microcode_6.7.0-2.69.14141615
                    PR résolus  S.O.
                    Numéros CVE S.O.

                    Ce correctif met à jour le VIB cpu-microcode.

                    • Le VIB cpu-microcode inclut le microcode Intel suivant :
                      Nom de code FMS ID de PLT Révision de MCU Date de MCU Noms de marque
                      Nehalem EP 0x106a5 0x03 0x0000001d 11/05/2018 Intel Xeon 35xx Series
                      Intel Xeon 55xx Series
                      Lynnfield 0x106e5 0x13 0x0000000a 08/05/2018 Intel Xeon 34xx Lynnfield Series
                      Clarkdale 0x20652 0x12 0x00000011 08/05/2018 Intel i3/i5 Clarkdale Series
                      Intel Xeon 34xx Clarkdale Series
                      Arrandale 0x20655 0x92 0x00000007 23/04/2018 Processeur Intel Core i7-620LE
                      Sandy Bridge DT 0x206a7 0x12 0x0000002f 17/02/2019 Intel Xeon E3-1100 Series
                      Intel Xeon E3-1200 Series
                      Intel i7-2655-LE Series
                      Intel i3-2100 Series
                      Westmere EP 0x206c2 0x03 0x0000001f 08/05/2018 Intel Xeon 56xx Series
                      Intel Xeon 36xx Series
                      Sandy Bridge EP 0x206d7 0x6d 0x00000718 21/05/2019 Intel Pentium 1400 Series
                      Intel Xeon E5-1400 Series
                      Intel Xeon E5-1600 Series
                      Intel Xeon E5-2400 Series
                      Intel Xeon E5-2600 Series
                      Intel Xeon E5-4600 Series
                      Nehalem EX 0x206e6 0x04 0x0000000d 15/05/2018 Intel Xeon 65xx Series
                      Intel Xeon 75xx Series
                      Westmere EX 0x206f2 0x05 0x0000003b 16/05/2018 Intel Xeon E7-8800 Series
                      Intel Xeon E7-4800 Series
                      Intel Xeon E7-2800 Series
                      Ivy Bridge DT 0x306a9 0x12 0x00000021 13/02/2019 Intel i3-3200 Series
                      Intel i7-3500-LE/UE
                      Intel i7-3600-QE
                      Intel Xeon E3-1200-v2 Series
                      Intel Xeon E3-1100-C-v2 Series
                      Intel Pentium B925C
                      Haswell DT 0x306c3 0x32 0x00000027 26/02/2019 Intel Xeon E3-1200-v3 Series
                      Intel i7-4700-EQ Series
                      Intel i5-4500-TE Series
                      Intel i3-4300 Series
                      Ivy Bridge EP 0x306e4 0xed 0x0000042e 14/03/2019 Intel Xeon E5-4600-v2 Series
                      Intel Xeon E5-2600-v2 Series
                      Intel Xeon E5-2400-v2 Series
                      Intel Xeon E5-1600-v2 Series
                      Intel Xeon E5-1400-v2 Series
                      Ivy Bridge EX 0x306e7 0xed 0x00000715 14/03/2019 Intel Xeon E7-8800/4800/2800-v2 Series
                      Haswell EP 0x306f2 0x6f 0x00000043 01/03/2019 Intel Xeon E5-4600-v3 Series
                      Intel Xeon E5-2600-v3 Series
                      Intel Xeon E5-2400-v3 Series
                      Intel Xeon E5-1600-v3 Series
                      Intel Xeon E5-1400-v3 Series
                      Haswell EX 0x306f4 0x80 0x00000014 01/03/2019 Intel Xeon E7-8800/4800-v3 Series
                      Broadwell H 0x40671 0x22 0x00000020 07/03/2019 Intel Core i7-5700EQ
                      Intel Xeon E3-1200-v4 Series
                      Avoton 0x406d8 0x01 0x0000012a 04/01/2018 Intel Atom C2300 Series
                      Intel Atom C2500 Series
                      Intel Atom C2700 Series
                      Broadwell EP/EX 0x406f1 0xef 0x0b000036 02/03/2019 Intel Xeon E7-8800/4800-v4 Series
                      Intel Xeon E5-4600-v4 Series
                      Intel Xeon E5-2600-v4 Series
                      Intel Xeon E5-1600-v4 Series
                      Skylake SP 0x50654 0xb7 0x0200005e 02/04/2019 Intel Xeon Platinum 8100 Series
                      Intel Xeon Gold 6100/5100, Silver 4100, Bronze 3100 Series
                      Intel Xeon D-2100 Series
                      Intel Xeon D-1600 Series
                      Intel Xeon W-3100 Series
                      Intel Xeon W-2100 Series
                      Cascade Lake B-0 0x50656 0xbf 0x04000024 07/04/2019 Intel Xeon Platinum 9200/8200 Series
                      Intel Xeon Gold 6200/5200
                      Intel Xeon Silver 4200/Bronze 3200
                      Intel Xeon W-3200
                      Cascade Lake 0x50657 0xbf 0x05000024 07/04/2019 Intel Xeon Platinum 9200/8200 Series
                      Intel Xeon Gold 6200/5200
                      Intel Xeon Silver 4200/Bronze 3200
                      Intel Xeon W-3200
                      Broadwell DE 0x50662 0x10 0x0000001a 23/03/2019 Intel Xeon D-1500 Series
                      Broadwell DE 0x50663 0x10 0x07000017 23/03/2019 Intel Xeon D-1500 Series
                      Broadwell DE 0x50664 0x10 0x0f000015 23/03/2019 Intel Xeon D-1500 Series
                      Broadwell NS 0x50665 0x10 0x0e00000d 23/03/2019 Intel Xeon D-1600 Series
                      Skylake H/S 0x506e3 0x36 0x000000cc 01/04/2019 Intel Xeon E3-1500-v5 Series
                      Intel Xeon E3-1200-v5 Series
                      Denverton 0x506f1 0x01 0x0000002e 21/03/2019 Intel Atom C3000 Series
                      Kaby Lake H/S/X 0x906e9 0x2a 0x000000b4 01/04/2019 Intel Xeon E3-1200-v6 Series
                      Intel Xeon E3-1500-v6 Series
                      Coffee Lake H/S 0x906ea 0x22 0x000000b4 01/04/2019 Intel Xeon E-2100 Series
                      Coffee Lake H/S 0x906eb 0x02 0x000000b4 01/04/2019 Intel Xeon E-2100 Series
                      Coffee Lake H/S 0x906ec 0x22 0x000000b8 17/03/2019 Intel Xeon E-2100 Series
                      Coffee Lake Refresh 0x906ed 0x22 0x000000b8 17/03/2019 Intel Xeon E-2200 Series
                    ESXi670-201908104-SG
                    Catégorie des correctifs Sécurité
                    Gravité des correctifs

                    Important
                    Redémarrage de l'hôte requis Non
                    Migration ou arrêt de la machine virtuelle requis Non
                    Matériel concerné S.O.
                    Logiciels concernés S.O.
                    VIB inclus
                    • VMware_bootbank_esx-ui_1.33.4-14093553
                    PR résolus  S.O.
                    Numéros CVE S.O.

                    Ce correctif met à jour le VIB esx-ui.

                      ESXi-6.7.0-20190802001-standard
                      Nom du profil ESXi-6.7.0-20190802001-standard
                      Build Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.
                      Fournisseur VMware, Inc.
                      Date de publication 20 août 2019
                      Niveau d'acceptation PartnerSupported
                      Matériel concerné S.O.
                      Logiciels concernés S.O.
                      VIB concernés
                      • VMware_bootbank_esx-update_6.7.0-3.73.14320388
                      • VMware_bootbank_vsan_6.7.0-3.73.14263135
                      • VMware_bootbank_vsanhealth_6.7.0-3.73.14263064
                      • VMware_bootbank_esx-base_6.7.0-3.73.14320388
                      • VMW_bootbank_igbn_0.1.1.0-5vmw.670.3.73.14320388
                      • VMW_bootbank_nvme_1.2.2.28-1vmw.670.3.73.14320388
                      • VMware_bootbank_qlnativefc_3.1.8.0-5vmw.670.3.73.14320388
                      • VMW_bootbank_lsi-mr3_7.708.07.00-3vmw.670.3.73.14320388
                      • VMW_bootbank_lsi-msgpt35_09.00.00.00-5vmw.670.3.73.14320388
                      • VMW_bootbank_lsi-msgpt3_17.00.02.00-1vmw.670.3.73.14320388
                      • VMW_bootbank_lsi-msgpt2_20.00.06.00-2vmw.670.3.73.14320388
                      • VMW_bootbank_i40en_1.8.1.9-2vmw.670.3.73.14320388
                      • VMW_bootbank_ixgben_1.7.1.16-1vmw.670.3.73.14320388
                      • VMW_bootbank_smartpqi_1.0.1.553-28vmw.670.3.73.14320388
                      • VMW_bootbank_bnxtnet_20.6.101.7-24vmw.670.3.73.14320388
                      • VMW_bootbank_elxnet_11.4.1097.0-5vmw.670.3.73.14320388
                      • VMW_bootbank_brcmfcoe_11.4.1078.25-14vmw.670.3.73.14320388
                      • VMW_bootbank_lpfc_11.4.33.25-14vmw.670.3.73.14320388
                      • VMW_bootbank_nenic_1.0.29.0-1vmw.670.3.73.14320388
                      • VMW_bootbank_vmw-ahci_1.2.8-1vmw.670.3.73.14320388
                      • VMW_bootbank_nmlx5-core_4.17.13.1-1vmw.670.3.73.14320388
                      • VMW_bootbank_nfnic_4.0.0.29-0vmw.670.3.73.14320388
                      • VMware_bootbank_esx-xserver_6.7.0-3.73.14320388
                      • VMW_bootbank_sfvmk_1.0.0.1003-6vmw.670.3.73.14320388
                      • VMware_locker_tools-light_10.3.10.12406962-14141615
                      • VMware_bootbank_cpu-microcode_6.7.0-2.69.14141615
                      • VMware_bootbank_esx-ui_1.33.4-14093553
                      PR résolus 2288428, 2282206, 2305377, 2213824, 2305719, 2301374, 2272250, 2220008, 2262288, 2290043, 2295425, 2300124, 2303227, 2301818, 2294347, 2338914, 2327317, 2312215, 2331247, 2340952, 2366745, 2331525, 2320309, 2304092, 2241121, 2306836, 2343913, 2361711, 2350171, 2297765, 2355516, 2287232, 2310826, 2332785, 2280742, 2386930, 2333442, 2346582, 2214222, 2335847, 2292419, 2132634, 2363202, 2367669, 2303016, 2337889, 2360408, 2344159, 2331369, 2370239, 2367142, 2336379, 2301231, 2354762, 2305414, 2305410, 2305404, 2305406, 2305405, 2335120, 2305407, 2315656, 2315652, 2305412, 2315684, 2323424, 2328263, 2332785, 2338914, 2214222, 2394247, 2402409, 2482603
                      Numéros CVE associés S/O
                      • Ce correctif met à jour les problèmes suivants :

                        • Des machines virtuelles peuvent cesser de répondre en raison de pannes répétitives de certains pilotes de périphériques tiers pour traiter les commandes. Lorsque vous ouvrez la console de machine virtuelle, le message d'erreur suivant peut s'afficher :
                          Erreur : connexion impossible au MKS : connexion impossible au canal \\.\pipe\vmware-authdpipe dans la période de nouvelle tentative 

                        • Après le redémarrage d'un hôte ESXi, il se peut que les banques de données NFS utilisant une solution Fault Tolerance par Nutanix montées dans le système vCenter Server ne soient pas visibles. Cependant, vous pouvez voir les volumes dans l'hôte ESXi.

                        • Les performances d'une machine virtuelle qui s'exécute sur une banque de données NFS version 3 peuvent s'altérer dans le temps. Après le redémarrage de l'hôte ESXi, les performances de la machine virtuelle redeviennent normales.

                        • Si une machine virtuelle dispose d'un snapshot SEsparse et si la taille du fichier VMDK de base n'est pas un multiple de 4K, lorsque vous interrogez la disposition physique du VMDK à partir de la système d'exploitation invité ou d'applications tierces, un blocage du CPU physique peut se produire. Par conséquent, ESXi échoue avec un écran de diagnostic violet.

                        • Si un port de conteneur a un ID d'attachement d'interface virtuelle (VIF) en double, lors de la migration de machines virtuelles à l'aide de vSphere Storage vMotion avec des ports de conteneur, la migration peut entraîner l'échec de l'hôte ESXi avec un écran de diagnostic violet.

                        • Lorsque vous utilisez la syntaxe pktcap-uw, un hôte ESXi peut échouer avec un écran de diagnostic violet à un point de capture UplinkRcv sur un CNA. Ce problème se produit en raison d'une condition rare lorsqu'un périphérique ne dispose pas d'un objet de liaison montante associé lors de la capture d'un paquet sur la liaison montante.

                        • La route basée sur la stratégie de chargement de carte réseau physique n'était pas prise en charge sur vSphere Distributed Switch version 6.6 avant ESXi 6.7 Update 3.

                        • Le démarrage réseau des machines virtuelles limite la distance entre une machine virtuelle et le serveur de démarrage réseau à 15 routeurs. Si votre système dispose de davantage de routeurs sur le chemin entre une machine virtuelle et un serveur nécessaire au démarrage (PXE, DHCP, DNS, TFTP), le démarrage échoue, car la demande de démarrage n'atteint pas le serveur.

                        • Chaque identifiant d'objet SNMPv3 peut recevoir des demandes GET bien qu'il y ait une authentification utilisateur. En conséquence, l'hôte ESXi peut cesser de répondre.

                        • vSphere Web Client ou vSphere Client peut afficher un profil d'hôte comme étant conforme même lorsqu'il a une valeur non conforme telle que la taille de l'unité de transmission maximale (MTU). La correction du profil fonctionne comme prévu, mais il n'est pas reflété dans vSphere Web Client ou vSphere Client.

                        • Vous pouvez arrêter par intermittence de voir des diagrammes de performances des hôtes ESXi dans l'instance intégrée de VMware Host Client ou dans n'importe quelle application Web qui se connecte au système vCenter Server, y compris vSphere Client et vSphere Web Client. Un problème interne entraîne la suppression des informations de compteurs de performance disponibles pour certains hôtes ESXi.

                        • Même si les états C sont activés dans la configuration du microprogramme d'un hôte ESXi, VMkernel ne détecte pas correctement tous les états C. L'écran d'alimentation de l'outil esxtop affiche les colonnes %C0 (pourcentage de temps passé en état C0) et %C1 (pourcentage de temps passé en état C1), mais n'affiche pas la colonne %C2. Par conséquent, les performances du système par watt de puissance ne sont pas optimisées.

                        • Si un hôte ESXi dispose d'une version de BIOS spécifique, un échec d'assertion peut se produire au début de la phase de démarrage de l'hôte, et lorsque le BIOS est activé dans le BIOS. L'échec d'assertion est du type :
                          Panic: ASSERT bora/vmkernel/vmkBoot/x86/vmkBootTxt.c:2235.

                        • Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une rare condition de concurrence lorsque l'hôte tente d'accéder à une zone de la mémoire dans l'intervalle exact où elle est libérée et allouée à une autre tâche.

                        • Lorsque vous utilisez l'adaptateur iSCSI logiciel, l'hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une condition de concurrence.

                        • Dans les charges de travail d'E/S lourdes, des différences dans la spécification AHCI du pilote vmw_ahci natif ESXi et du microprogramme du contrôleur AHCI tiers (tel que l'adaptateur DELL BOSS-S1) peuvent générer plusieurs erreurs, notamment des erreurs de pannes de stockage ou un écran de diagnostic violet.

                        • Les machines virtuelles peuvent perdre la connectivité lors de migrations entre clusters à l'aide de vSphere vMotion dans une installation NSX, car les filtres NetX peuvent bloquer le trafic vers les ports.

                        • Ce problème est spécifique aux banques de données vSphere Virtual Volumes lorsqu'un fichier VMDK est attribué à différentes cibles SCSI dans les snapshots. Le fichier de verrouillage du VMDK est réattribué sur différents snapshots et peut être supprimé de façon incorrecte lorsque vous restaurez la machine virtuelle vers un snapshot. En raison du fichier de verrouillage manquant, le disque ne s'ouvre pas et la machine virtuelle ne parvient pas à se mettre sous tension.

                        • Une machine virtuelle disposant de vNIC VMXNET3 ne peut pas démarrer à l'aide du démarrage de Citrix PVS. Cela est dû aux interruptions en attente sur le périphérique réseau virtuel qui ne sont pas gérées correctement lors de la transition du démarrage PXE au démarrage du système d'exploitation invité. Par conséquent, le système d'exploitation invité ne peut pas démarrer le périphérique réseau virtuel et le démarrage de la machine virtuelle échoue également.

                        • Si vous personnalisez les tailles d'anneau Rx et Tx des cartes réseau physiques pour améliorer les performances du réseau en utilisant les commandes suivantes :
                          esxcli network nic ring current set -n -t 
                          esxcli network nic ring current set -n -r 
                          les paramètres peuvent ne pas être persistants lors des redémarrages d'hôtes ESXi.

                        • Lorsque vous démarrez macOS 10.15 Developer Preview sur une machine virtuelle, le système d'exploitation peut échouer avec un écran vide affichant un logo Apple blanc. Une opération de mise sous tension en mode détaillé cesse de répondre après l'affichage du message d'erreur suivant :
                          Erreur lors de la désérialisation de l'utilitaire de prelink plist : OSUnserializeXML : erreur de syntaxe à proximité de la ligne 2
                          panic(...): « Pilote pour cette plate-forme introuvable : \"ACPI\".\n »@...

                        • Si vous modifiez NetworkNicTeamingPolicy ou SecurityPolicy d'un profil d'hôte pour revenir aux paramètres par défaut, vous risquez de ne pas pouvoir appliquer le profil d'hôte à un hôte ESXi et d'obtenir une erreur de ce type : Erreur : un paramètre spécifié n'était pas correct.

                        • Si la taille de l'unité de transmission maximale (MTU) d'un commutateur virtuel est inférieure à la taille MTU configurée pour le port VMkernel, les opérations vMotion peuvent échouer. Si une opération vMotion est immédiatement suivie d'une opération d'ajout à chaud ou Storage vMotion, l'hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • La taille maximale de segment de mémoire pour n'importe quel module est de 3 Go. Si la taille de la mémoire totale demandée est supérieure à 4 Go, un dépassement de capacité pour un entier se produit. Par conséquent, les adresses MAC des interfaces de machine virtuelle sont définies sur 00:00:00:00:00:00 et le périphérique VMXNET3 peut ne pas démarrer. Dans le journal VMkernel, vous pouvez voir une erreur semblable à celle-ci : Vmxnet3: 15204: Allocation de la mémoire échouée pour tq 0.

                        • Lors de l'exportation de plusieurs machines virtuelles vers un dossier, les noms VMDK peuvent être en conflit et être automatiquement renommés par le navigateur Web. Cela rend les fichiers OVF exportés non valides.

                        • Si vous utilisez une instance de vSphere Distributed Switch ou une instance de vSphere Distributed Switch gérée par NSX-T avec une fonctionnalité de conteneur activée, et si votre hôte ESXi est de version 6.7 ou de version antérieure, lors d'une opération de mise à niveau ou de migration, l'hôte ESXi peut échouer avec un violet écran de diagnostic.

                        • Vous devez ajouter manuellement les règles de réclamation à un hôte ESXi pour les baies de stockage Tegile afin de définir le paramètre Opérations d'E/S par seconde sur 1.

                        • Lors du provisionnement de clones instantanés dans vSphere Web Client ou vSphere Client, l'erreur Déconnecté de la machine virtuelle peut s'afficher. Les machines virtuelles ne peuvent pas être mises sous tension, car le processus d'exécution de la machine virtuelle (VMX) échoue.

                        • Si vIOMMU est activé, le système d'exploitation invité Linux peut cesser de répondre lors de l'initialisation du noyau kdump.

                        • Un hôte ESXi risque de ne pas parvenir à surveiller la santé de l'adaptateur de bus hôte (HBA) LSI et du stockage attaché. Par conséquent, le système vCenter Server ne peut pas afficher d'alarme lorsque la santé HBA est dégradée. Vous devez installer le fournisseur tiers LSI SMI-S CIM. Pour plus d'informations, reportez-vous à l'article 2001549 de la base de connaissances VMware.

                        • Vous pouvez utiliser la méthode SCSIBindCompletionWorlds() pour définir le nombre de files d'attente et de mondes d'un pilote. Cependant, si vous définissez le paramètre numQueues sur une valeur supérieure à 1 et que le paramètre numWorlds est égal ou inférieur à 1, l'appel d'API peut retourner sans libérer le verrou maintenu. Cela entraîne un blocage et l'hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Si une machine virtuelle fonctionne avec Windows 10 Version 1809, possède des snapshots et s'exécute sur une banque de données VMFS6, elle peut démarrer lentement ou cesser de répondre pendant la phase de démarrage.

                        • Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une erreur NullPointerException dans l'exécution des E/S lorsque la connectivité aux banques de données NFS41 échoue par intermittence.

                        • Si vous utilisez un hôte ESXi avec le modèle de lecteur de CD-ROM DU-8A5LH, le lecteur de CD-ROM peut signaler une exception Frame Information Structure (FIS) inconnue. Le pilote vmw_ahci ne gère pas l'exception correctement et crée des journaux d'exceptions PORT_IRQ_UNK_FIS répétés dans le noyau. Les journaux répétés provoquent une absence de pulsation de CPU physique et l'hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Une condition de concurrence dans les opérations de règle de pare-feu get-set pour les commutateurs virtuels DvFilter peut entraîner un débordement de tampon et une corruption du segment de mémoire. Par conséquent, un hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Une corruption de la mémoire peut se produire lors de la migration à chaud du calcul et du stockage de machines virtuelles disposant de vGPU NVIDIA GRID. La migration réussit, mais les applications en cours d'exécution peuvent ne pas reprendre sur l'hôte de destination. 

                        • La mise sous tension de machines virtuelles configurées avec un nombre maximal de périphériques virtuels et relais PCI peut échouer si la limite est dépassée.
                          Le problème est identifié par un journal de panique dans le fichier vmware.log semblable à celui-ci : vmx| E105: PANIC: VERIFY bora/devices/pci/pci.c:1529.

                        • ESXi 6.7 Update 2 introduit un correctif relatif à l'errata d'Intel pour les CPU Skylake. Le correctif a un impact sur la configuration matérielle et certains contrôles de santé sont déclenchés, de sorte que l'hôte ESXi effectue un redémarrage complet du système au lieu d'un démarrage rapide. Ce problème ne se produit qu'une seule fois, lors d'une mise à jour des hôtes ESXi depuis une version sans correctif vers une version incluant ce correctif, et lorsque le démarrage rapide est activé pour cette mise à jour.

                        • Plusieurs scripts Xorg peuvent s'exécuter en parallèle et interférer entre eux. Par conséquent, le démarrage du script Xorg peut échouer sur les systèmes disposant de plusieurs GPU.

                        • Lorsque vous utilisez la commande esxcli network nic get -n vmnicX pour obtenir l'état de négociation automatique sur des périphériques ConnectX5 Mellanox, vous pouvez voir l'état False même si la fonctionnalité est activée sur le commutateur physique.

                        • Lorsque vous mettez en veille les machines virtuelles qui exécutent Microsoft Windows Server 2008 ou version ultérieure, les snapshots de l'application mise au repos sont créés. Le nombre maximal de snapshots simultanés est de 32, ce qui est trop élevé, car un trop grand nombre de threads est utilisé dans le suivi des tâches de l'opération de snapshot. Par conséquent, le service hostd peut cesser de répondre.

                        • Le service hostd échoue parfois lors de la recomposition de pools VDI, avec le message d'erreur VmfsExtentCommonOpen: VmfsExtentParseExtentLine a échoué. Vous pouvez voir des fichiers hostd-worker-zdump générés dans le répertoire /var/core/ de l'hôte ESXi.

                        • Dans vSphere Web Client, une latence de lecture ou d'écriture incorrecte s'affiche pour les graphiques de performances des banques de données vSphere Virtual Volumes au niveau d'une machine virtuelle. Par conséquent, le service de surveillance indique que les machines virtuelles sont dans un état critique.

                        • Lors de la décompression de la page mémoire d'une machine virtuelle s'exécutant sur ESXi 6.7, la vérification de la taille de la fenêtre de compression peut échouer. En conséquence, la machine virtuelle peut cesser de répondre et redémarrer. Dans la trace de débogage du journal VMkernel, vous pouvez voir des entrées semblables à :
                          Unable to decompress BPN(0x1005ef842) from frameIndex(0x32102f0) block 0 for VM(6609526)

                          0x451a55f1baf0:[0x41802ed3d040]WorldPanicWork
                          0x451a55f1bb50:[0x41802ed3d285]World_Panic
                          0x451a55f1bcc0:[0x41802edb3002]VmMemIO_FaultCompressedPage
                          0x451a55f1bd20:[0x41802edbf72f]VmMemPfCompressed
                          0x451a55f1bd70:[0x41802edc033b]VmMemPfInt
                          0x451a55f1be10:[0x41802edc0d4f]VmMemPf
                          0x451a55f1be80:[0x41802edc108e]VmMemPfLockPageInt
                          0x451a55f1bef0:[0x41802edc3517]VmMemPf_LockPage
                          0x451a55f1bfa0:[0x41802ed356e6]VMMVMKCall_Call
                          0x451a55f1bfe0:[0x41802ed59e5d]VMKVMM_ArchEnterVMKernel

                        • Le nombre de contextes simultanés du gestionnaire de ressources d'un hôte ESXi peut dépasser le maximum de 512 en raison d'une erreur dans la logique de répartition. En cas de ralentissement d'hôte secondaire ou de problèmes réseau, cela peut provoquer des erreurs DiskQueue est saturé et l'échec de la synchronisation de machines virtuelles échoue dans des opérations exécutées par Site Recovery Manager.

                        • Si vous ne configurez pas de route par défaut dans l'hôte ESXi, l'adresse IP de l'agent SNMP ESXi peut être en ordre inverse dans la charge utile des interruptions SNMP envoyées. Par exemple, si l'agent SNMP dispose de l'adresse IP 172.16.0.10, dans la charge utile l'adresse IP est 10.0.16.172. Par conséquent, les interruptions SNMP atteignent la cible avec une adresse IP incorrecte de l'agent SNMP ESXi dans la charge utile.

                        • Si une machine virtuelle exécute des applications qui utilisent un état 3D et des nuanciers particuliers, et si l'accélération 3D logicielle est utilisée, la machine virtuelle peut cesser de répondre.

                        • Lorsque l'invité envoie un déchargement de total de contrôle IPv6 avec des en-têtes de routage activés, l'hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Lorsqu'un hôte ESXi supprime un conseil PShare d'une chaîne PShare, si la chaîne PShare est endommagée, l'hôte ESXi peut échouer avec un écran de diagnostic violet et une erreur semblable à :
                          0x43920bd9bdc0:[0x41800c5930d6]VmMemCow_PShareRemoveHint
                          0x43920bd9be00:[0x41800c593172]VmMemCowPFrameRemoveHint
                          0x43920bd9be30:[0x41800c594fc8]VmMemCowPShareFn@vmkernel
                          0x43920bd9bf80:[0x41800c500ef4]VmAssistantProcessTasks@vmkernel
                          0x43920bd9bfe0:[0x41800c6cae05]CpuSched_StartWorld@vmkernel

                        • Lorsqu'une machine virtuelle utilise un port série distant connecté à un concentrateur de ports série virtuel (vSPC), où un nom DNS est l'adresse du vSPC, si une panne de DNS se produit lors d'une migration à l'aide de vMotion, la machine virtuelle peut être mise hors tension.

                        • Lorsque vous modifiez le niveau de compatibilité matérielle d'une machine virtuelle avec un périphérique relais PCI, le périphérique peut être retiré de la machine virtuelle pendant la procédure.

                        • Lorsque vous utilisez la ligne de commande et exécutez la commande pour définir l'alias pNIC, l'adresse MAC enregistrée dans esx.conf pour le pNIC correspondant est incorrecte. La commande que vous utilisez est la suivante :
                          localcli --plugin-dir /usr/lib/vmware/esxcli/int/ deviceInternal alias store --bus-type pci --alias vmnicX --bus-address XX.

                        • Ce problème se produit uniquement lorsque le SATP est VMW_SATP_LOCAL. Dans ESXi 6.0, si une règle de réclamation SATP avec SATP défini sur VMW_SATP_LOCAL est ajoutée avec une option de configuration mal formatée, les plug-ins NMP/SATP ne reconnaissent pas l'option et ne parviennent pas à détecter le périphérique lors de la mise à niveau vers une version ultérieure d'ESXi.
                          Les journaux peuvent contenir des entrées semblables aux entrées suivantes :
                          2018-11-20T02:10:36.333Z cpu1:66089)WARNING: NMP: nmp_DeviceAlloc:2048: nmp_AddPathToDevice failed Bad parameter (195887111).
                          2018-11-20T02:10:36.333Z cpu1:66089)WARNING: ScsiPath: 6615: Plugin 'NMP' had an error (Bad parameter) while claiming path 'vmhba0:C0:T2:L0'. Skipping the path

                        • Une condition de concurrence dans les opérations get-set de règle de pare-feu pour les commutateurs virtuels DvFilter peut entraîner un débordement de mémoire tampon et une corruption du segment de mémoire. Par conséquent, un hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Un état de santé du matériel du système vCenter Server peut ne pas afficher les échecs sur les barrettes DIMM, que les contrôleurs de serveur affichent ou non un avertissement. Par exemple, le contrôleur d'accès à distance Dell dans un système Dell M630 Server peut afficher un avertissement dans un module DIMM, mais vous ne voyez aucune alerte ou alarme dans votre système vCenter Server.

                        • La mise à jour du pilote NVMe résout le problème de surcharge de performances sur les périphériques qui s'exécutent sur la série P4600 Intel SSD DC.

                        • Le pilote qlnativefc est mis à jour vers la version 3.1.8.0.

                        • Le pilote lsi_mr3 est mis à jour vers la version MR 7.8.

                        • Le pilote lsi_msgpt35 est mis à jour vers la version 09.00.00.00-5vmw.

                        • Le pilote i40en est mis à jour vers la version 1.8.1.9-2.

                        • Le pilote lsi_msgpt3 est mis à jour vers la version 17.00.02.00-1vmw.

                        • Le pilote lsi_msgpt2 est mis à jour vers la version 20.00.06.00-2.

                        • Le pilote ixgben ajoute le couplage de file d'attente pour optimiser l'efficacité du CPU.

                        • Le pilote smartpqi est mis à jour vers la version 1.0.1.553-28.

                        • ESXi 6.7 Update 3 ajoute la prise en charge des adaptateurs réseau Broadcom 100G et du flux multi-RSS au pilote bnxtnet.

                        • Un problème avec le pilote elxnet peut entraîner une perte de connectivité des cartes réseau qui utilisent ce pilote. Dans les journaux du noyau de l'hôte ESXi, des avertissements semblables à ceux-ci peuvent s'afficher : 
                          WARNING: elxnet: elxnet_workerThread:2122: [vmnic3] GetStats: MCC cmd timed out. timeout:36 
                          WARNING: elxnet: elxnet_detectDumpUe:416: [vmnic3] Recoverable HW error detected

                        • Le pilote nenic est mis à jour vers la version 1.0.29.0.

                        • Si vous modifiez NetworkNicTeamingPolicy ou SecurityPolicy d'un profil d'hôte pour revenir aux paramètres par défaut, vous risquez de ne pas pouvoir appliquer le profil d'hôte à un hôte ESXi et d'obtenir une erreur de ce type : Erreur : un paramètre spécifié n'était pas correct.

                        • Si vous personnalisez les tailles d'anneau Rx et Tx des cartes réseau physiques pour améliorer les performances du réseau en utilisant les commandes suivantes :
                          esxcli network nic ring current set -n -t 
                          esxcli network nic ring current set -n -r 
                          les paramètres peuvent ne pas être persistants lors des redémarrages d'hôtes ESXi.

                        • Si vous utilisez une instance de vSphere Distributed Switch ou une instance de vSphere Distributed Switch gérée par NSX-T avec une fonctionnalité de conteneur activée, et si votre hôte ESXi est de version 6.7 ou de version antérieure, lors d'une opération de mise à niveau ou de migration, l'hôte ESXi peut échouer avec un violet écran de diagnostic.

                        • Lorsque l'invité envoie un déchargement de total de contrôle IPv6 avec des en-têtes de routage activés, l'hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Lorsque vous utilisez la ligne de commande et exécutez la commande pour définir l'alias pNIC, l'adresse MAC enregistrée dans esx.conf pour le pNIC correspondant est incorrecte. La commande que vous utilisez est la suivante :
                          localcli --plugin-dir /usr/lib/vmware/esxcli/int/ deviceInternal alias store --bus-type pci --alias vmnicX --bus-address XX.

                        • Si le nom de la liaison montante n'est pas au format vmnicX, où X est un nombre, LACP ne fonctionne pas.

                        • Lorsque vous configurez le LAG, si un membre du bundle bascule, un message d'observation VMkernel incorrect peut s'afficher pour le LAG : Critères en échec : 0.

                        • Après la mise à jour du microcode, il est parfois nécessaire d'énumérer de nouveau le CPUID des machines virtuelles sur un serveur ESXi. À l'aide du paramètre de configuration vmx.reboot.powerCycle=TRUE, vous pouvez planifier l'exécution d'un cycle d'alimentation par les machines virtuelles si nécessaire.

                        • Lors de la création d'un snapshot, une machine virtuelle peut être mise hors tension et échouer avec une erreur semblable à celle-ci :
                          2019-01-01T01:23:40.047Z| vcpu-0| I125: DISKLIB-CTK : Failed to mmap change bitmap of size 167936: Cannot allocate memory.
                          2019-01-01T01:23:40.217Z| vcpu-0| I125: DISKLIB-LIB_BLOCKTRACK : Impossible d'ouvrir le suivi des modifications /vmfs/volumes/DATASTORE_UUID/VM_NAME/VM_NAME_1-ctk.vmdk: Mémoire insuffisante pour le suivi des modifications.
                          L'erreur est due à un manque de mémoire allouée pour la carte de bits CBT.

                        • Si le même pilote de carte réseau sur un hôte ESXi dispose de cartes réseau physiques qui ne prennent pas en charge SR-IOV et d'autres qui prennent en charge SR-IOV, vous pouvez voir des informations différentes à partir de l'ensemble de commandes EXCLI et dans vSphere Client ou vSphere Web Client. Par exemple, dans l'ensemble de commandes ESXCLI, vous pouvez voir que les vmnic 16, 17 et 18 disposent de SR-IOV configuré, alors que dans vSphere Client vous pouvez voir que SR-IOV est configuré sur vmnic 6, 7 et 8.
                      ESXi-6.7.0-20190802001-no-tools
                      Nom du profil ESXi-6.7.0-20190802001-no-tools
                      Build Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.
                      Fournisseur VMware, Inc.
                      Date de publication 20 août 2019
                      Niveau d'acceptation PartnerSupported
                      Matériel concerné S.O.
                      Logiciels concernés S.O.
                      VIB concernés
                      • VMware_bootbank_esx-update_6.7.0-3.73.14320388
                      • VMware_bootbank_vsan_6.7.0-3.73.14263135
                      • VMware_bootbank_vsanhealth_6.7.0-3.73.14263064
                      • VMware_bootbank_esx-base_6.7.0-3.73.14320388
                      • VMW_bootbank_igbn_0.1.1.0-5vmw.670.3.73.14320388
                      • VMW_bootbank_nvme_1.2.2.28-1vmw.670.3.73.14320388
                      • VMware_bootbank_qlnativefc_3.1.8.0-5vmw.670.3.73.14320388
                      • VMW_bootbank_lsi-mr3_7.708.07.00-3vmw.670.3.73.14320388
                      • VMW_bootbank_lsi-msgpt35_09.00.00.00-5vmw.670.3.73.14320388
                      • VMW_bootbank_lsi-msgpt3_17.00.02.00-1vmw.670.3.73.14320388
                      • VMW_bootbank_lsi-msgpt2_20.00.06.00-2vmw.670.3.73.14320388
                      • VMW_bootbank_i40en_1.8.1.9-2vmw.670.3.73.14320388
                      • VMW_bootbank_ixgben_1.7.1.16-1vmw.670.3.73.14320388
                      • VMW_bootbank_smartpqi_1.0.1.553-28vmw.670.3.73.14320388
                      • VMW_bootbank_bnxtnet_20.6.101.7-24vmw.670.3.73.14320388
                      • VMW_bootbank_elxnet_11.4.1097.0-5vmw.670.3.73.14320388
                      • VMW_bootbank_brcmfcoe_11.4.1078.25-14vmw.670.3.73.14320388
                      • VMW_bootbank_lpfc_11.4.33.25-14vmw.670.3.73.14320388
                      • VMW_bootbank_nenic_1.0.29.0-1vmw.670.3.73.14320388
                      • VMW_bootbank_vmw-ahci_1.2.8-1vmw.670.3.73.14320388
                      • VMW_bootbank_nmlx5-core_4.17.13.1-1vmw.670.3.73.14320388
                      • VMW_bootbank_nfnic_4.0.0.29-0vmw.670.3.73.14320388
                      • VMware_bootbank_esx-xserver_6.7.0-3.73.14320388
                      • VMW_bootbank_sfvmk_1.0.0.1003-6vmw.670.3.73.14320388
                      • VMware_bootbank_cpu-microcode_6.7.0-2.69.14141615
                      • VMware_bootbank_esx-ui_1.33.4-14093553
                      PR résolus 2288428, 2282206, 2305377, 2213824, 2305719, 2301374, 2272250, 2220008, 2262288, 2290043, 2295425, 2300124, 2303227, 2301818, 2294347, 2338914, 2327317, 2312215, 2331247, 2340952, 2366745, 2331525, 2320309, 2304092, 2241121, 2306836, 2343913, 2361711, 2350171, 2297765, 2355516, 2287232, 2310826, 2332785, 2280742, 2386930, 2333442, 2346582, 2214222, 2335847, 2292419, 2132634, 2363202, 2367669, 2303016, 2337889, 2360408, 2344159, 2331369, 2370239, 2367142, 2336379, 2301231, 2354762, 2305414, 2305410, 2305404, 2305406, 2305405, 2335120, 2305407, 2315656, 2315652, 2305412, 2315684, 2323424, 2328263, 2332785, 2338914, 2214222, 2394247, 2402409, 2482603
                      Numéros CVE associés S/O
                      • Ce correctif met à jour les problèmes suivants :

                        • Des machines virtuelles peuvent cesser de répondre en raison de pannes répétitives de certains pilotes de périphériques tiers pour traiter les commandes. Lorsque vous ouvrez la console de machine virtuelle, le message d'erreur suivant peut s'afficher :
                          Erreur : connexion impossible au MKS : connexion impossible au canal \\.\pipe\vmware-authdpipe dans la période de nouvelle tentative 

                        • Après le redémarrage d'un hôte ESXi, il se peut que les banques de données NFS utilisant une solution Fault Tolerance par Nutanix montées dans le système vCenter Server ne soient pas visibles. Cependant, vous pouvez voir les volumes dans l'hôte ESXi.

                        • Les performances d'une machine virtuelle qui s'exécute sur une banque de données NFS version 3 peuvent s'altérer dans le temps. Après le redémarrage de l'hôte ESXi, les performances de la machine virtuelle redeviennent normales.

                        • Si une machine virtuelle dispose d'un snapshot SEsparse et si la taille du fichier VMDK de base n'est pas un multiple de 4K, lorsque vous interrogez la disposition physique du VMDK à partir de la système d'exploitation invité ou d'applications tierces, un blocage du CPU physique peut se produire. Par conséquent, ESXi échoue avec un écran de diagnostic violet.

                        • Si un port de conteneur a un ID d'attachement d'interface virtuelle (VIF) en double, lors de la migration de machines virtuelles à l'aide de vSphere Storage vMotion avec des ports de conteneur, la migration peut entraîner l'échec de l'hôte ESXi avec un écran de diagnostic violet.

                        • Lorsque vous utilisez la syntaxe pktcap-uw, un hôte ESXi peut échouer avec un écran de diagnostic violet à un point de capture UplinkRcv sur un CNA. Ce problème se produit en raison d'une condition rare lorsqu'un périphérique ne dispose pas d'un objet de liaison montante associé lors de la capture d'un paquet sur la liaison montante.

                        • La route basée sur la stratégie de chargement de carte réseau physique n'était pas prise en charge sur vSphere Distributed Switch version 6.6 avant ESXi 6.7 Update 3.

                        • Le démarrage réseau des machines virtuelles limite la distance entre une machine virtuelle et le serveur de démarrage réseau à 15 routeurs. Si votre système dispose de davantage de routeurs sur le chemin entre une machine virtuelle et un serveur nécessaire au démarrage (PXE, DHCP, DNS, TFTP), le démarrage échoue, car la demande de démarrage n'atteint pas le serveur.

                        • Chaque identifiant d'objet SNMPv3 peut recevoir des demandes GET bien qu'il y ait une authentification utilisateur. En conséquence, l'hôte ESXi peut cesser de répondre.

                        • vSphere Web Client ou vSphere Client peut afficher un profil d'hôte comme étant conforme même lorsqu'il a une valeur non conforme telle que la taille de l'unité de transmission maximale (MTU). La correction du profil fonctionne comme prévu, mais il n'est pas reflété dans vSphere Web Client ou vSphere Client.

                        • Vous pouvez arrêter par intermittence de voir des diagrammes de performances des hôtes ESXi dans l'instance intégrée de VMware Host Client ou dans n'importe quelle application Web qui se connecte au système vCenter Server, y compris vSphere Client et vSphere Web Client. Un problème interne entraîne la suppression des informations de compteurs de performance disponibles pour certains hôtes ESXi.

                        • Même si les états C sont activés dans la configuration du microprogramme d'un hôte ESXi, VMkernel ne détecte pas correctement tous les états C. L'écran d'alimentation de l'outil esxtop affiche les colonnes %C0 (pourcentage de temps passé en état C0) et %C1 (pourcentage de temps passé en état C1), mais n'affiche pas la colonne %C2. Par conséquent, les performances du système par watt de puissance ne sont pas optimisées.

                        • Si un hôte ESXi dispose d'une version de BIOS spécifique, un échec d'assertion peut se produire au début de la phase de démarrage de l'hôte, et lorsque le BIOS est activé dans le BIOS. L'échec d'assertion est du type :
                          Panic: ASSERT bora/vmkernel/vmkBoot/x86/vmkBootTxt.c:2235.

                        • Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une rare condition de concurrence lorsque l'hôte tente d'accéder à une zone de la mémoire dans l'intervalle exact où elle est libérée et allouée à une autre tâche.

                        • Lorsque vous utilisez l'adaptateur iSCSI logiciel, l'hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une condition de concurrence.

                        • Dans les charges de travail d'E/S lourdes, des différences dans la spécification AHCI du pilote vmw_ahci natif ESXi et du microprogramme du contrôleur AHCI tiers (tel que l'adaptateur DELL BOSS-S1) peuvent générer plusieurs erreurs, notamment des erreurs de pannes de stockage ou un écran de diagnostic violet.

                        • Les machines virtuelles peuvent perdre la connectivité lors de migrations entre clusters à l'aide de vSphere vMotion dans une installation NSX, car les filtres NetX peuvent bloquer le trafic vers les ports.

                        • Ce problème est spécifique aux banques de données vSphere Virtual Volumes lorsqu'un fichier VMDK est attribué à différentes cibles SCSI dans les snapshots. Le fichier de verrouillage du VMDK est réattribué sur différents snapshots et peut être supprimé de façon incorrecte lorsque vous restaurez la machine virtuelle vers un snapshot. En raison du fichier de verrouillage manquant, le disque ne s'ouvre pas et la machine virtuelle ne parvient pas à se mettre sous tension.

                        • Une machine virtuelle disposant de vNIC VMXNET3 ne peut pas démarrer à l'aide du démarrage de Citrix PVS. Cela est dû aux interruptions en attente sur le périphérique réseau virtuel qui ne sont pas gérées correctement lors de la transition du démarrage PXE au démarrage du système d'exploitation invité. Par conséquent, le système d'exploitation invité ne peut pas démarrer le périphérique réseau virtuel et le démarrage de la machine virtuelle échoue également.

                        • Si vous personnalisez les tailles d'anneau Rx et Tx des cartes réseau physiques pour améliorer les performances du réseau en utilisant les commandes suivantes :
                          esxcli network nic ring current set -n -t 
                          esxcli network nic ring current set -n -r 
                          les paramètres peuvent ne pas être persistants lors des redémarrages d'hôtes ESXi.

                        • Lorsque vous démarrez macOS 10.15 Developer Preview sur une machine virtuelle, le système d'exploitation peut échouer avec un écran vide affichant un logo Apple blanc. Une opération de mise sous tension en mode détaillé cesse de répondre après l'affichage du message d'erreur suivant :
                          Erreur lors de la désérialisation de l'utilitaire de prelink plist : OSUnserializeXML : erreur de syntaxe à proximité de la ligne 2
                          panic(...): « Pilote pour cette plate-forme introuvable : \"ACPI\".\n »@...

                        • Si vous modifiez NetworkNicTeamingPolicy ou SecurityPolicy d'un profil d'hôte pour revenir aux paramètres par défaut, vous risquez de ne pas pouvoir appliquer le profil d'hôte à un hôte ESXi et d'obtenir une erreur de ce type : Erreur : un paramètre spécifié n'était pas correct.

                        • Si la taille de l'unité de transmission maximale (MTU) d'un commutateur virtuel est inférieure à la taille MTU configurée pour le port VMkernel, les opérations vMotion peuvent échouer. Si une opération vMotion est immédiatement suivie d'une opération d'ajout à chaud ou Storage vMotion, l'hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • La taille maximale de segment de mémoire pour n'importe quel module est de 3 Go. Si la taille de la mémoire totale demandée est supérieure à 4 Go, un dépassement de capacité pour un entier se produit. Par conséquent, les adresses MAC des interfaces de machine virtuelle sont définies sur 00:00:00:00:00:00 et le périphérique VMXNET3 peut ne pas démarrer. Dans le journal VMkernel, vous pouvez voir une erreur semblable à celle-ci : Vmxnet3: 15204: Allocation de la mémoire échouée pour tq 0.

                        • Lors de l'exportation de plusieurs machines virtuelles vers un dossier, les noms VMDK peuvent être en conflit et être automatiquement renommés par le navigateur Web. Cela rend les fichiers OVF exportés non valides.

                        • Si vous utilisez une instance de vSphere Distributed Switch ou une instance de vSphere Distributed Switch gérée par NSX-T avec une fonctionnalité de conteneur activée, et si votre hôte ESXi est de version 6.7 ou de version antérieure, lors d'une opération de mise à niveau ou de migration, l'hôte ESXi peut échouer avec un violet écran de diagnostic.

                        • Vous devez ajouter manuellement les règles de réclamation à un hôte ESXi pour les baies de stockage Tegile afin de définir le paramètre Opérations d'E/S par seconde sur 1.

                        • Lors du provisionnement de clones instantanés dans vSphere Web Client ou vSphere Client, l'erreur Déconnecté de la machine virtuelle peut s'afficher. Les machines virtuelles ne peuvent pas être mises sous tension, car le processus d'exécution de la machine virtuelle (VMX) échoue.

                        • Si vIOMMU est activé, le système d'exploitation invité Linux peut cesser de répondre lors de l'initialisation du noyau kdump.

                        • Un hôte ESXi risque de ne pas parvenir à surveiller la santé de l'adaptateur de bus hôte (HBA) LSI et du stockage attaché. Par conséquent, le système vCenter Server ne peut pas afficher d'alarme lorsque la santé HBA est dégradée. Vous devez installer le fournisseur tiers LSI SMI-S CIM. Pour plus d'informations, reportez-vous à l'article 2001549 de la base de connaissances VMware.

                        • Vous pouvez utiliser la méthode SCSIBindCompletionWorlds() pour définir le nombre de files d'attente et de mondes d'un pilote. Cependant, si vous définissez le paramètre numQueues sur une valeur supérieure à 1 et que le paramètre numWorlds est égal ou inférieur à 1, l'appel d'API peut retourner sans libérer le verrou maintenu. Cela entraîne un blocage et l'hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Si une machine virtuelle fonctionne avec Windows 10 Version 1809, possède des snapshots et s'exécute sur une banque de données VMFS6, elle peut démarrer lentement ou cesser de répondre pendant la phase de démarrage.

                        • Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une erreur NullPointerException dans l'exécution des E/S lorsque la connectivité aux banques de données NFS41 échoue par intermittence.

                        • Si vous utilisez un hôte ESXi avec le modèle de lecteur de CD-ROM DU-8A5LH, le lecteur de CD-ROM peut signaler une exception Frame Information Structure (FIS) inconnue. Le pilote vmw_ahci ne gère pas l'exception correctement et crée des journaux d'exceptions PORT_IRQ_UNK_FIS répétés dans le noyau. Les journaux répétés provoquent une absence de pulsation de CPU physique et l'hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Une condition de concurrence dans les opérations de règle de pare-feu get-set pour les commutateurs virtuels DvFilter peut entraîner un débordement de tampon et une corruption du segment de mémoire. Par conséquent, un hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Une corruption de la mémoire peut se produire lors de la migration à chaud du calcul et du stockage de machines virtuelles disposant de vGPU NVIDIA GRID. La migration réussit, mais les applications en cours d'exécution peuvent ne pas reprendre sur l'hôte de destination. 

                        • La mise sous tension de machines virtuelles configurées avec un nombre maximal de périphériques virtuels et relais PCI peut échouer si la limite est dépassée.
                          Le problème est identifié par un journal de panique dans le fichier vmware.log semblable à celui-ci : vmx| E105: PANIC: VERIFY bora/devices/pci/pci.c:1529.

                        • ESXi 6.7 Update 2 introduit un correctif relatif à l'errata d'Intel pour les CPU Skylake. Le correctif a un impact sur la configuration matérielle et certains contrôles de santé sont déclenchés, de sorte que l'hôte ESXi effectue un redémarrage complet du système au lieu d'un démarrage rapide. Ce problème ne se produit qu'une seule fois, lors d'une mise à jour des hôtes ESXi depuis une version sans correctif vers une version incluant ce correctif, et lorsque le démarrage rapide est activé pour cette mise à jour.

                        • Plusieurs scripts Xorg peuvent s'exécuter en parallèle et interférer entre eux. Par conséquent, le démarrage du script Xorg peut échouer sur les systèmes disposant de plusieurs GPU.

                        • Lorsque vous utilisez la commande esxcli network nic get -n vmnicX pour obtenir l'état de négociation automatique sur des périphériques ConnectX5 Mellanox, vous pouvez voir l'état False même si la fonctionnalité est activée sur le commutateur physique.

                        • Lorsque vous mettez en veille les machines virtuelles qui exécutent Microsoft Windows Server 2008 ou version ultérieure, les snapshots de l'application mise au repos sont créés. Le nombre maximal de snapshots simultanés est de 32, ce qui est trop élevé, car un trop grand nombre de threads est utilisé dans le suivi des tâches de l'opération de snapshot. Par conséquent, le service hostd peut cesser de répondre.

                        • Le service hostd échoue parfois lors de la recomposition de pools VDI, avec le message d'erreur VmfsExtentCommonOpen: VmfsExtentParseExtentLine a échoué. Vous pouvez voir des fichiers hostd-worker-zdump générés dans le répertoire /var/core/ de l'hôte ESXi.

                        • Dans vSphere Web Client, une latence de lecture ou d'écriture incorrecte s'affiche pour les graphiques de performances des banques de données vSphere Virtual Volumes au niveau d'une machine virtuelle. Par conséquent, le service de surveillance indique que les machines virtuelles sont dans un état critique.

                        • Lors de la décompression de la page mémoire d'une machine virtuelle s'exécutant sur ESXi 6.7, la vérification de la taille de la fenêtre de compression peut échouer. En conséquence, la machine virtuelle peut cesser de répondre et redémarrer. Dans la trace de débogage du journal VMkernel, vous pouvez voir des entrées semblables à :
                          Unable to decompress BPN(0x1005ef842) from frameIndex(0x32102f0) block 0 for VM(6609526)

                          0x451a55f1baf0:[0x41802ed3d040]WorldPanicWork
                          0x451a55f1bb50:[0x41802ed3d285]World_Panic
                          0x451a55f1bcc0:[0x41802edb3002]VmMemIO_FaultCompressedPage
                          0x451a55f1bd20:[0x41802edbf72f]VmMemPfCompressed
                          0x451a55f1bd70:[0x41802edc033b]VmMemPfInt
                          0x451a55f1be10:[0x41802edc0d4f]VmMemPf
                          0x451a55f1be80:[0x41802edc108e]VmMemPfLockPageInt
                          0x451a55f1bef0:[0x41802edc3517]VmMemPf_LockPage
                          0x451a55f1bfa0:[0x41802ed356e6]VMMVMKCall_Call
                          0x451a55f1bfe0:[0x41802ed59e5d]VMKVMM_ArchEnterVMKernel

                        • Le nombre de contextes simultanés du gestionnaire de ressources d'un hôte ESXi peut dépasser le maximum de 512 en raison d'une erreur dans la logique de répartition. En cas de ralentissement d'hôte secondaire ou de problèmes réseau, cela peut provoquer des erreurs DiskQueue est saturé et l'échec de la synchronisation de machines virtuelles échoue dans des opérations exécutées par Site Recovery Manager.

                        • Si vous ne configurez pas de route par défaut dans l'hôte ESXi, l'adresse IP de l'agent SNMP ESXi peut être en ordre inverse dans la charge utile des interruptions SNMP envoyées. Par exemple, si l'agent SNMP dispose de l'adresse IP 172.16.0.10, dans la charge utile l'adresse IP est 10.0.16.172. Par conséquent, les interruptions SNMP atteignent la cible avec une adresse IP incorrecte de l'agent SNMP ESXi dans la charge utile.

                        • Si une machine virtuelle exécute des applications qui utilisent un état 3D et des nuanciers particuliers, et si l'accélération 3D logicielle est utilisée, la machine virtuelle peut cesser de répondre.

                        • Lorsque l'invité envoie un déchargement de total de contrôle IPv6 avec des en-têtes de routage activés, l'hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Lorsqu'un hôte ESXi supprime un conseil PShare d'une chaîne PShare, si la chaîne PShare est endommagée, l'hôte ESXi peut échouer avec un écran de diagnostic violet et une erreur semblable à :
                          0x43920bd9bdc0:[0x41800c5930d6]VmMemCow_PShareRemoveHint
                          0x43920bd9be00:[0x41800c593172]VmMemCowPFrameRemoveHint
                          0x43920bd9be30:[0x41800c594fc8]VmMemCowPShareFn@vmkernel
                          0x43920bd9bf80:[0x41800c500ef4]VmAssistantProcessTasks@vmkernel
                          0x43920bd9bfe0:[0x41800c6cae05]CpuSched_StartWorld@vmkernel

                        • Lorsqu'une machine virtuelle utilise un port série distant connecté à un concentrateur de ports série virtuel (vSPC), où un nom DNS est l'adresse du vSPC, si une panne de DNS se produit lors d'une migration à l'aide de vMotion, la machine virtuelle peut être mise hors tension.

                        • Lorsque vous modifiez le niveau de compatibilité matérielle d'une machine virtuelle avec un périphérique relais PCI, le périphérique peut être retiré de la machine virtuelle pendant la procédure.

                        • Lorsque vous utilisez la ligne de commande et exécutez la commande pour définir l'alias pNIC, l'adresse MAC enregistrée dans esx.conf pour le pNIC correspondant est incorrecte. La commande que vous utilisez est la suivante :
                          localcli --plugin-dir /usr/lib/vmware/esxcli/int/ deviceInternal alias store --bus-type pci --alias vmnicX --bus-address XX.

                        • Ce problème se produit uniquement lorsque le SATP est VMW_SATP_LOCAL. Dans ESXi 6.0, si une règle de réclamation SATP avec SATP défini sur VMW_SATP_LOCAL est ajoutée avec une option de configuration mal formatée, les plug-ins NMP/SATP ne reconnaissent pas l'option et ne parviennent pas à détecter le périphérique lors de la mise à niveau vers une version ultérieure d'ESXi.
                          Les journaux peuvent contenir des entrées semblables aux entrées suivantes :
                          2018-11-20T02:10:36.333Z cpu1:66089)WARNING: NMP: nmp_DeviceAlloc:2048: nmp_AddPathToDevice failed Bad parameter (195887111).
                          2018-11-20T02:10:36.333Z cpu1:66089)WARNING: ScsiPath: 6615: Plugin 'NMP' had an error (Bad parameter) while claiming path 'vmhba0:C0:T2:L0'. Skipping the path

                        • Une condition de concurrence dans les opérations get-set de règle de pare-feu pour les commutateurs virtuels DvFilter peut entraîner un débordement de mémoire tampon et une corruption du segment de mémoire. Par conséquent, un hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Un état de santé du matériel du système vCenter Server peut ne pas afficher les échecs sur les barrettes DIMM, que les contrôleurs de serveur affichent ou non un avertissement. Par exemple, le contrôleur d'accès à distance Dell dans un système Dell M630 Server peut afficher un avertissement dans un module DIMM, mais vous ne voyez aucune alerte ou alarme dans votre système vCenter Server.

                        • La mise à jour du pilote NVMe résout le problème de surcharge de performances sur les périphériques qui s'exécutent sur la série P4600 Intel SSD DC.

                        • Le pilote qlnativefc est mis à jour vers la version 3.1.8.0.

                        • Le pilote lsi_mr3 est mis à jour vers la version MR 7.8.

                        • Le pilote lsi_msgpt35 est mis à jour vers la version 09.00.00.00-5vmw.

                        • Le pilote i40en est mis à jour vers la version 1.8.1.9-2.

                        • Le pilote lsi_msgpt3 est mis à jour vers la version 17.00.02.00-1vmw.

                        • Le pilote lsi_msgpt2 est mis à jour vers la version 20.00.06.00-2.

                        • Le pilote ixgben ajoute le couplage de file d'attente pour optimiser l'efficacité du CPU.

                        • Le pilote smartpqi est mis à jour vers la version 1.0.1.553-28.

                        • ESXi 6.7 Update 3 ajoute la prise en charge des adaptateurs réseau Broadcom 100G et du flux multi-RSS au pilote bnxtnet.

                        • Un problème avec le pilote elxnet peut entraîner une perte de connectivité des cartes réseau qui utilisent ce pilote. Dans les journaux du noyau de l'hôte ESXi, des avertissements semblables à ceux-ci peuvent s'afficher : 
                          WARNING: elxnet: elxnet_workerThread:2122: [vmnic3] GetStats: MCC cmd timed out. timeout:36 
                          WARNING: elxnet: elxnet_detectDumpUe:416: [vmnic3] Recoverable HW error detected

                        • Le pilote nenic est mis à jour vers la version 1.0.29.0.

                        • Si vous modifiez NetworkNicTeamingPolicy ou SecurityPolicy d'un profil d'hôte pour revenir aux paramètres par défaut, vous risquez de ne pas pouvoir appliquer le profil d'hôte à un hôte ESXi et d'obtenir une erreur de ce type : Erreur : un paramètre spécifié n'était pas correct.

                        • Si vous personnalisez les tailles d'anneau Rx et Tx des cartes réseau physiques pour améliorer les performances du réseau en utilisant les commandes suivantes :
                          esxcli network nic ring current set -n -t 
                          esxcli network nic ring current set -n -r 
                          les paramètres peuvent ne pas être persistants lors des redémarrages d'hôtes ESXi.

                        • Si vous utilisez une instance de vSphere Distributed Switch ou une instance de vSphere Distributed Switch gérée par NSX-T avec une fonctionnalité de conteneur activée, et si votre hôte ESXi est de version 6.7 ou de version antérieure, lors d'une opération de mise à niveau ou de migration, l'hôte ESXi peut échouer avec un violet écran de diagnostic.

                        • Lorsque l'invité envoie un déchargement de total de contrôle IPv6 avec des en-têtes de routage activés, l'hôte ESXi peut échouer avec un écran de diagnostic violet.

                        • Lorsque vous utilisez la ligne de commande et exécutez la commande pour définir l'alias pNIC, l'adresse MAC enregistrée dans esx.conf pour le pNIC correspondant est incorrecte. La commande que vous utilisez est la suivante :
                          localcli --plugin-dir /usr/lib/vmware/esxcli/int/ deviceInternal alias store --bus-type pci --alias vmnicX --bus-address XX.

                        • Si le nom de la liaison montante n'est pas au format vmnicX, où X est un nombre, LACP ne fonctionne pas.

                        • Lorsque vous configurez le LAG, si un membre du bundle bascule, un message d'observation VMkernel incorrect peut s'afficher pour le LAG : Critères en échec : 0.

                        • Après la mise à jour du microcode, il est parfois nécessaire d'énumérer de nouveau le CPUID des machines virtuelles sur un serveur ESXi. À l'aide du paramètre de configuration vmx.reboot.powerCycle=TRUE, vous pouvez planifier l'exécution d'un cycle d'alimentation par les machines virtuelles si nécessaire.

                        • Lors de la création d'un snapshot, une machine virtuelle peut être mise hors tension et échouer avec une erreur semblable à celle-ci :
                          2019-01-01T01:23:40.047Z| vcpu-0| I125: DISKLIB-CTK : Failed to mmap change bitmap of size 167936: Cannot allocate memory.
                          2019-01-01T01:23:40.217Z| vcpu-0| I125: DISKLIB-LIB_BLOCKTRACK : Impossible d'ouvrir le suivi des modifications /vmfs/volumes/DATASTORE_UUID/VM_NAME/VM_NAME_1-ctk.vmdk: Mémoire insuffisante pour le suivi des modifications.
                          L'erreur est due à un manque de mémoire allouée pour la carte de bits CBT.

                        • Si le même pilote de carte réseau sur un hôte ESXi dispose de cartes réseau physiques qui ne prennent pas en charge SR-IOV et d'autres qui prennent en charge SR-IOV, vous pouvez voir des informations différentes à partir de l'ensemble de commandes EXCLI et dans vSphere Client ou vSphere Web Client. Par exemple, dans l'ensemble de commandes ESXCLI, vous pouvez voir que les vmnic 16, 17 et 18 disposent de SR-IOV configuré, alors que dans vSphere Client vous pouvez voir que SR-IOV est configuré sur vmnic 6, 7 et 8.
                      ESXi-6.7.0-20190801001s-standard
                      Nom du profil ESXi-6.7.0-20190801001s-standard
                      Build Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.
                      Fournisseur VMware, Inc.
                      Date de publication 20 août 2019
                      Niveau d'acceptation PartnerSupported
                      Matériel concerné S.O.
                      Logiciels concernés S.O.
                      VIB concernés
                      • VMware_bootbank_esx-base_6.7.0-2.69.14141615
                      • VMware_bootbank_esx-update_6.7.0-2.69.14141615
                      • VMware_bootbank_vsan_6.7.0-2.69.13808269
                      • VMware_bootbank_vsanhealth_6.7.0-2.69.13808270
                      • VMware_locker_tools-light_10.3.10.12406962-14141615
                      • VMware_bootbank_cpu-microcode_6.7.0-2.69.14141615
                      • VMware_bootbank_esx-ui_1.33.4-14093553
                      PR résolus 2307421, 2360047, 2300903, 2262288, 2313239
                      Numéros CVE associés S/O
                      • Ce correctif met à jour les problèmes suivants :

                        • Le démon NTP est mis à jour vers la version ntp-4.2.8p13.

                        • La bibliothèque ESXi userworld libcurl est mise à jour vers la version 7.64.1.

                        • Les hôtes ESXi peuvent répondre à toutes les demandes get SNMPv3 de l'utilisateur spécial "", qui est utilisé pour la découverte d'ID de moteur, même si l'utilisateur n'est pas authentifié ou mal authentifié.

                        • La bibliothèque ESXi userworld libxml2 a été mise à jour vers la version 2.9.9.

                        • La bibliothèque tierce Python est mise à jour vers la version 3.5.7.

                      ESXi-6.7.0-20190801001s-no-tools
                      Nom du profil ESXi-6.7.0-20190801001s-no-tools
                      Build Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.
                      Fournisseur VMware, Inc.
                      Date de publication 20 août 2019
                      Niveau d'acceptation PartnerSupported
                      Matériel concerné S.O.
                      Logiciels concernés S.O.
                      VIB concernés
                      • VMware_bootbank_esx-base_6.7.0-2.69.14141615
                      • VMware_bootbank_esx-update_6.7.0-2.69.14141615
                      • VMware_bootbank_vsan_6.7.0-2.69.13808269
                      • VMware_bootbank_vsanhealth_6.7.0-2.69.13808270
                      • VMware_bootbank_cpu-microcode_6.7.0-2.69.14141615
                      • VMware_bootbank_esx-ui_1.33.4-14093553
                      PR résolus 2307421, 2360047, 2300903, 2262288, 2313239
                      Numéros CVE associés S/O
                      • Ce correctif met à jour les problèmes suivants :

                        • Le démon NTP est mis à jour vers la version ntp-4.2.8p13.

                        • La bibliothèque ESXi userworld libcurl est mise à jour vers la version 7.64.1.

                        • Les hôtes ESXi peuvent répondre à toutes les demandes get SNMPv3 de l'utilisateur spécial "", qui est utilisé pour la découverte d'ID de moteur, même si l'utilisateur n'est pas authentifié ou mal authentifié.

                        • La bibliothèque ESXi userworld libxml2 a été mise à jour vers la version 2.9.9.

                        • La bibliothèque tierce Python est mise à jour vers la version 3.5.7.

                      Problèmes connus

                      Les problèmes connus sont classés comme suit :

                      Problèmes divers
                      • Le déclenchement manuel d'une interruption non masquable (NMI) risque de ne pas fonctionner sur un système vCenter Server disposant d'un processeur AMD EPYC série 7002

                        La demande d'une NMI depuis la console de gestion du matériel (BMC) ou en appuyant sur un bouton NMI physique devrait entraîner l'échec des hôtes ESXi avec un écran de diagnostic violet et un vidage mémoire. Au lieu de cela, rien ne se passe et ESXi continue de s'exécuter.

                        Solution : Désactivez l'utilisation du remappeur d'interruption en définissant l'option de démarrage du noyau iovDisableIR sur TRUE :

                        1. Définissez iovDisableIR=TRUE à l'aide de cette commande : # esxcli system settings kernel set -s iovDisableIR -v TRUE
                        2. Redémarrez l'hôte ESXi.
                        3. Après le redémarrage, vérifiez que iovDisableIR est défini sur TRUE : # esxcli system settings kernel list |grep iovDisableIR.

                        N'appliquez cette solution que s'il faut résoudre ce problème spécifique.

                      • Une machine virtuelle disposant d'un périphérique de relais PCI qui lui est attribué peut ne pas être mise sous tension dans un système vCenter Server disposant d'un processeur AMD EPYC série 7002

                        Dans des configurations et des périphériques spécifiques du système vCenter Server, tels que les processeurs AMD EPYC série 7002, une machine virtuelle à laquelle est attribué un périphérique de relais PCI peut ne pas être mise sous tension. Dans le journal vmkernel, un message semblable à l'exemple suivant peut s'afficher :
                        4512 2019-08-06T06:09:55.058Z cpu24:1001397137)AMDIOMMU: 611: IOMMU 0000:20:00.2: Failed to allocate IRTE for IOAPIC ID 243 vector 0x3f
                        4513 2019-08-06T06:09:55.058Z cpu24:1001397137)WARNING: IOAPIC: 1238: IOAPIC Id 243: Failed to allocate IRTE for vector 0x3f

                        Solution : Désactivez l'utilisation du remappeur d'interruption en définissant l'option de démarrage du noyau iovDisableIR sur TRUE :

                        1. Définissez iovDisableIR=TRUE à l'aide de cette commande : # esxcli system settings kernel set -s iovDisableIR -v TRUE
                        2. Redémarrez l'hôte ESXi.
                        3. Après le redémarrage, vérifiez que iovDisableIR est défini sur TRUE : # esxcli system settings kernel list |grep iovDisableIR.

                        N'appliquez cette solution que s'il faut résoudre ce problème spécifique.

                      Problèmes liés à Auto Deploy
                      • Les profils d'hôte ESXi 6.7 peuvent ne pas prendre en charge PEERDNS à partir de vmknic qui sont rattachés à un réseau opaque basé sur VMware NSX-T

                        Dans certains cas, les profils d'hôte sur ESXi 6.7 peuvent ne pas prendre en charge PEERDNS à partir de vmknic qui sont rattachés à un réseau opaque basé sur NSX-T. Le problème est spécifique d'un scénario lorsque vous accédez à Hôte > Configurer > Configuration TCP/IP > Par défaut > Configuration DNS > Obtenir les paramètres automatiquement à partir d'un adaptateur réseau VMkernel. Si vous sélectionnez un vmknic connecté à un réseau opaque basé sur NSX-T, les profils d'hôte extraits de cet hôte ne fonctionnent pas. De tels profils d'hôte ne disposent pas de la stratégie Groupe de ports supportant l'adaptateur réseau VMkernel à utiliser pour DNS dans le sous-profil DNS. La modification du profil d'hôte provoque une erreur de validation.

                        Solution : aucune. Ne sélectionnez pas PEERDNS depuis un vmknic connecté à un réseau opaque basé sur NSX-T. 

                      Problèmes de mise en réseau
                      • Certains adaptateurs réseau Intel peuvent ne pas être en mesure de recevoir des paquets LLDP

                        Les adaptateurs réseau Intel de la série X710, XL710, XXV710 et X722 peuvent ne pas être en mesure de recevoir des paquets LLDP. Cela est dû à un agent sur puce exécuté sur le microprogramme pour consommer des trames LLDP reçues des ports LAN. La consommation empêche les logiciels d'obtenir des paquets LLDP en fonction des trames LLDP, telles que les commutateurs distribués virtuels.

                        Solution : Pour permettre aux adaptateurs réseau Intel de recevoir des paquets LLDP, vous devez :

                        1. Utiliser une version de microprogramme >= 6.0
                        2. Utiliser une version de pilote >= 1.7.x
                        3. Configurez le paramètre de module LLDP d'i40en sur 0.

                          Par exemple, pour désactiver l'agent LLDP sur les 4 cartes réseau, exécutez la commande suivante :

                            # esxcli system module parameters set -p "LLDP=0,0,0,0" i40en
                        Le nombre de paramètres 0 doit être égal au nombre de liaisons montantes i40en sur l'hôte ESXi.

                      • Si vous utilisez SR-IOV (Single Root I/O Virtualization) et que vous modifiez une fonction physique (PF) pour le pilote ixgben, certaines machines virtuelles risquent de perdre la connectivité

                        Si vous utilisez SR-IOV et réinitialisez un PF (ou désactivez un PF, puis le réactivez), les machines virtuelles qui utilisent une fonction virtuelle SR-IOV pour la mise en réseau peuvent perdre leur connectivité.

                        Solution : Redémarrez le serveur ESXi, puis mettez sous tension les machines virtuelles. Cependant, si vous utilisez DHCP, les adresses IP des machines virtuelles peuvent changer.

                      • Si vous définissez une adresse MAC et une adresse de port de liaison montante identiques sur des périphériques utilisant le pilote i40en, les vmknic peut recevoir des modules dupliqués

                        Si vous définissez manuellement l'adresse MAC d'un vmknic sur celle du port de liaison montante sur des périphériques utilisant le pilote i40en, le vmknic peut recevoir des modules dupliqués dans un trafic intense.

                        Solution : Ne définissez pas l'adresse MAC d'un vmknic sur celle du port de liaison montante. Pour le réseau de gestion vmk0, sur lequel l'adresse MAC et l'adresse de port de liaison montante sont identiques par défaut, n'utilisez pas les vmnic pour les charges de travail intenses.

                      Problèmes connus des versions antérieures

                      Pour afficher la liste des problèmes connus précédents, cliquez ici.

                      check-circle-line exclamation-circle-line close-line
                      Scroll to top icon