ESXi 7.0 Update 3f | 12 juillet 2022 | Build ISO 20036589

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 :

IMPORTANT : si votre système source contient des hôtes de versions comprises entre ESXi 7.0 Update 2 et Update 3c, et inclut des pilotes Intel, avant de procéder à la mise à niveau vers ESXi 7.0 Update 3f, reportez-vous à la section Nouveautés des notes de mise à jour de VMware vCenter Server 7.0 Update 3c, car tout le contenu de cette section s'applique également à vSphere 7.0 Update 3f. Consultez également les articles associés de la base de connaissances VMware : 86447, 87258 et 87308. 

Nouveautés

  • Cette version résout les vulnérabilités critiques CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 et CVE-2022-29901. Pour plus d'informations sur ces vulnérabilités et leur impact sur les produits VMware, reportez-vous à la page VMSA-2022-0020.
  • ESXi 7.0 Update 3f prend en charge vSphere Quick Boot sur les serveurs suivants :

    • Cisco Systems Inc :

      • UCSC-C220-M6N
      • UCSC-C225-M6N
      • UCSC-C240-M6L
      • UCSC-C240-M6N
      • UCSC-C240-M6SN
      • UCSC-C240-M6SX

    • Dell Inc :

      • PowerEdge XR11
      • PowerEdge XR12
      • PowerEdge XE8545
    • HPE :
      • Edgeline e920
      • Edgeline e920d
      • Edgeline e920t
      • ProLiant DL20 Gen10 Plus
      • ProLiant DL110 Gen10 Plus
      • ProLiant ML30 Gen10 Plus
    • Lenovo :
      • ThinkSystem SR 860 V2

Versions antérieures d'ESXi 7.0

Les nouvelles fonctionnalités ainsi que les problèmes résolus et connus d'ESXi sont décrits dans les notes de mise à jour de chaque version. Notes de mise à jour des versions antérieures à ESXi 7.0 :

Pour plus d'informations sur l'internationalisation, la compatibilité et les composants open source, consultez les Notes de mise à jour de VMware vSphere 7.0.

Correctifs contenus dans cette version

La version 7.0 Update 3f d'ESXi fournit les correctifs suivants :

Détails de la build

Nom de fichier de téléchargement : VMware-ESXi-7.0U3f-20036589-depot
Build : 20036589
Taille du téléchargement : 575,2 Mo
md5sum : 8543deb5d6d71bc7cc6d6c21977b1181
sha256checksum : b4cd253cbc28abfa01fbe8e996c3b0fd8b6be9e442a4631f35616eb34e9e01e9
Redémarrage de l'hôte requis : Oui
Migration ou arrêt de la machine virtuelle requis : Oui

Composants

Composant Bulletin Catégorie Gravité
Composant ESXi - VIB ESXi principaux ESXi_7.0.3-0.50.20036589 Correctif de bogues Critique
Composant d'installation/mise à niveau d'ESXi esx-update_7.0.3-0.50.20036589 Correctif de bogues Critique
Pilotes Broadcom NetXtreme-E Network et ROCE/RDMA pour VMware ESXi Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.703.0.50.20036589 Correctif de bogues Critique
Pilote réseau pour adaptateurs Intel(R) E810 Intel-icen_1.4.1.20-1vmw.703.0.50.20036589 Correctif de bogues Critique
Pilote réseau pour adaptateurs RDMA basés sur Intel(R) X722 et E810 Intel-irdman_1.3.1.22-1vmw.703.0.50.20036589 Correctif de bogues Critique
Pilote VMware iSER natif VMware-iser_1.1.0.1-1vmw.703.0.50.20036589 Correctif de bogues Critique
Pilote lpfc Broadcom Emulex Connectivity Division pour adaptateurs FC Broadcom-ELX-lpfc_14.0.169.26-5vmw.703.0.50.20036589 Correctif de bogues Critique
Plug-in de gestion de PILOTES LSU NATIFS LSI Broadcom-lsiv2-drivers-plugin_1.0.0-12vmw.703.0.50.20036589 Correctif de bogues Critique
Pilote de mise en réseau pour adaptateurs de la famille Intel PRO/1000 Intel-ne1000_0.9.0-1vmw.703.0.50.20036589 Correctif de bogues Critique
Pilote USB VMware-vmkusb_0.1-7vmw.703.0.50.20036589 Correctif de bogues Critique
Composant ESXi - VIB ESXi principaux ESXi_7.0.3-0.45.20036586 Sécurité Critique
Composant d'installation/mise à niveau d'ESXi esx-update_7.0.3-0.45.20036586 Sécurité Critique
VMware-VM-Tools VMware-VM-Tools_12.0.0.19345655-20036586 Sécurité Critique

IMPORTANT :

  • À partir de vSphere 7.0, VMware utilise des composants pour le conditionnement des VIB avec des bulletins. Les bulletins ESXi et esx-update sont interdépendants. Incluez toujours les deux dans une ligne de base de correctifs d'hôte ESXi ou incluez le bulletin de cumul dans la ligne de base pour éviter un échec pendant le correctif de l'hôte. 
  • Lorsque vous appliquez un correctif aux hôtes ESXi à l'aide de VMware Update Manager à partir d'une version antérieure à ESXi 7.0 Update 2, il est vivement recommandé d'utiliser le bulletin de cumul dans la ligne de base de correctifs. Si vous ne pouvez pas utiliser le bulletin de cumul, assurez-vous d'inclure tous les modules suivants dans la ligne de base de correctifs. Si les modules suivants ne sont pas inclus dans la ligne de base, l'opération de mise à jour échoue :
    • VMware-vmkusb_0.1-1vmw.701.0.0.16850804 ou version ultérieure
    • VMware-vmkata_0.1-1vmw.701.0.0.16850804 ou version ultérieure
    • VMware-vmkfcoe_1.0.0.2-1vmw.701.0.0.16850804 ou version ultérieure
    • VMware-NVMeoF-RDMA_1.0.1.2-1vmw.701.0.0.16850804 ou version ultérieure

Bulletin de cumul

Ce bulletin de cumul contient les derniers VIB avec tous les correctifs postérieurs à la publication initiale d'ESXi 7.0.

ID de bulletin Catégorie Gravité Détails
ESXi70U3f-20036589 Correctif de bogues Critique Sécurité et correctif de bogues
ESXi70U3sf-20036586 Sécurité Critique Sécurité uniquement

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-7.0U3f-20036589-standard
ESXi-7.0U3f-20036589-no-tools
ESXi-7.0U3sf-20036586-standard
ESXi-7.0U3sf-20036586-no-tools

Image ESXi

Nom et version Date de publication Catégorie Détail
ESXi70U3f-20036589 12 juillet 2022 Correctif de bogues Image de sécurité et de résolutions de bogues
ESXi70U3sf-20036586 12 juillet 2022 Sécurité Image de sécurité uniquement

Pour plus d'informations sur les composants et bulletins individuels, reportez-vous à la page Correctifs de produits et à la section Problèmes résolus.

Téléchargement et installation de correctifs

Dans vSphere 7.x, le plug-in Update Manager, utilisé pour l'administration de vSphere Update Manager, est remplacé par le plug-in Lifecycle Manager. Les opérations d'administration pour vSphere Update Manager sont toujours disponibles sous le plug-in Lifecycle Manager, avec de nouvelles capacités pour vSphere Lifecycle Manager.
La manière habituelle d'appliquer des correctifs aux hôtes ESXi 7.x consiste à utiliser vSphere Lifecycle Manager. Pour plus d'informations, consultez À propos de vSphere Lifecycle Manager et Lignes de base et images de vSphere Lifecycle Manager.
Vous pouvez également mettre à jour des hôtes ESXi sans utiliser le plug-in Lifecycle Manager et utiliser un profil d'image à la place. Pour ce faire, vous devez télécharger manuellement le fichier ZIP du bundle hors ligne du correctif à partir de VMware Customer Connect. Dans le menu déroulant Sélectionner un produit, sélectionnez ESXi (intégré et installable), puis, dans le menu déroulant Sélectionner une version, sélectionnez 7.0. Pour plus d'informations, consultez Mise à niveau des hôtes à l'aide des commandes ESXCLI et le guide Mise à niveau de VMware ESXi.

Problèmes résolus

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

ESXi_7.0.3-0.50.20036589
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_esxio-combiner_7.0.3-0.50.20036589
  • VMware_bootbank_esx-ui_1.43.8-19798623
  • VMware_bootbank_esx-xserver_7.0.3-0.50.20036589
  • VMware_bootbank_cpu-microcode_7.0.3-0.50.20036589
  • VMware_bootbank_trx_7.0.3-0.50.20036589
  • VMware_bootbank_vsanhealth_7.0.3-0.50.20036589
  • VMware_bootbank_esx-base_7.0.3-0.50.20036589
  • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.50.20036589
  • VMware_bootbank_gc_7.0.3-0.50.20036589
  • VMware_bootbank_native-misc-drivers_7.0.3-0.50.20036589
  • VMware_bootbank_bmcal_7.0.3-0.50.20036589
  • VMware_bootbank_vsan_7.0.3-0.50.20036589
  • VMware_bootbank_vdfs_7.0.3-0.50.20036589
  • VMware_bootbank_crx_7.0.3-0.50.20036589
PR résolus 2916848, 2817702, 2937074, 2957732, 2984134, 2944807, 2985369, 2907963, 2949801, 2984245, 2911320, 2915911, 2990593, 2992648, 2905357, 2980176, 2974472, 2974376, 2972059, 2973031, 2967359, 2860126, 2878245, 2876044, 2968157, 2960242, 2970238, 2966270, 2966783, 2963328, 2939395, 2966362, 2946550, 2958543, 2966628, 2961584, 2911056, 2965235, 2952427, 2963401, 2965146, 2963038, 2963479, 2949375, 2961033, 2958926, 2839515, 2951139, 2878224, 2954320, 2952432, 2961346, 2857932, 2960949, 2960882, 2957966, 2929443, 2956080, 2959293, 2944919, 2948800, 2928789, 2957769, 2928268, 2957062, 2792139, 2934102, 2953709, 2950686, 2953488, 2949446, 2955016, 2953217, 2956030, 2949902, 2944894, 2944521, 2911363, 2952205, 2894093, 2910856, 2953754, 2949777, 2925733, 2951234, 2915979, 2904241, 2935355, 2941263, 2912661, 2891231, 2928202, 2928268, 2867146, 2244126, 2912330, 2898858, 2906297, 2912213, 2910340, 2745800, 2912182, 2941274, 2912230, 2699748, 2882789, 2869031, 2913017, 2864375, 2925133 et 2965277
Numéros CVE S.O.

Les bulletins ESXi et esx-update sont interdépendants. Incluez toujours les deux dans une ligne de base de correctifs d'hôte ESXi ou incluez le bulletin de cumul dans la ligne de base pour éviter un échec pendant le correctif de l'hôte.
Met à jour les VIB esxio-combiner, esx-ui, esx-xserver, cpu-microcode, trx, vsanhealth, esx-base, esx-dvfilter-generic-fastpath, gc, native-misc-drivers, bmcal, vsan, vdfs et crx pour résoudre les problèmes suivants :

  • NOUVEAU : PR 2965277 : les machines virtuelles avec prise en charge de la virtualisation imbriquée sur lesquelles la sécurité basée sur la virtualisation (VBS) est activée peuvent afficher une utilisation atteignant 100 % du CPU

    Dans certaines conditions, telles que l'augmentation du partage de page ou la désactivation de l'utilisation de grandes pages au niveau de la machine virtuelle ou de l'hôte ESXi, vous pouvez constater une utilisation du CPU de machines virtuelles compatibles VBS Windows atteignant 100 %.

    Ce problème est résolu dans cette version. Le correctif empêche le partage de page dans certains cas spécifiques afin d'éviter le problème. 

  • PR 2839515 : l'appel python SDK (pyVmomi) à EnvironmentBrowser.QueryConfigOptionEx échoue avec le message UnknownWsdlTypeError

    Les appels pyVmomi à l'API vSphere EnvironmentBrowser.QueryConfigTargetEx peuvent échouer avec le message UnknownWsdlTypeError.

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

  • PR 2911320 : l'état Inconnu s'affiche pour les capteurs de type Événement système dans l'écran de surveillance de la santé du matériel dans vSphere Client

    Le module de santé du matériel d'ESXi peut ne pas parvenir à décoder certains capteurs de type Événement système lorsque le nom d'un serveur physique est modifié. Par conséquent, dans vSphere Client, vous voyez l'état Inconnu pour les capteurs de type Événement système sous Surveiller > Santé du matériel.

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

  • PR 2910340 : si une machine virtuelle avec vmx.reboot.powerCycle=TRUE redémarre pendant la migration, il se peut qu'elle ne se mette pas sous tension

    Si vous définissez le paramètre avancé vmx.reboot.powerCycle sur une machine virtuelle sur TRUE, lorsque le SE invité initie un redémarrage, la machine virtuelle se met hors tension, puis se met sous tension. Cependant, si un cycle d'alimentation se produit pendant une migration à l'aide de vSphere vMotion, l'opération échoue et la machine virtuelle sur l'hôte source peut ne pas se mettre sous tension.

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

  • PR 2916848 : les hôtes ESXi peuvent échouer avec un écran de diagnostic violet en raison d'une concurrence de données dans les sockets de domaine UNIX

    Si une socket rencontre un échec de connexion alors qu'elle est interrogée lors de la communication interne entre des sockets de domaine UNIX, une concurrence de données peut se produire. Par conséquent, dans certains cas, l'hôte ESXi peut accéder à une région de mémoire non valide et échouer avec un écran de diagnostic violet avec #PF Exception 14 et des erreurs semblables à UserDuct_PollSize() et UserSocketLocalPoll().

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

  • PR 2891231 : vous ne pouvez pas créer un profil d'hôte à partir d'un hôte ESXi qui utilise un adaptateur iSCSI matériel avec une pseudo carte réseau

    Si un adaptateur iSCSI matériel sur un hôte ESXi de votre environnement utilise des pseudo cartes réseau, il se peut que vous ne puissiez pas créer un profil d'hôte à partir d'un tel hôte, car les pseudo cartes réseau ne disposent pas de l'adresse PCI et du nom de fournisseur requis pour un profil.

    Ce problème est résolu dans cette version. Pour les pseudo cartes réseau, le correctif supprime l'exigence pour les valeurs d'adresse PCI et de nom de fournisseur PCI.

  • PR 2898858 : les machines virtuelles peuvent cesser de répondre en raison de problèmes de stockage sous-jacents sur un adaptateur iSCSI logiciel

    Les conditions de concurrence dans le pilote iscsi_vmk peuvent entraîner des opérations d'E/S bloquées ou des délais d'expiration de pulsation sur une banque de données VMFS. Par conséquent, certaines machines virtuelles peuvent cesser de répondre.

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

  • PR 2792139 : le débit avec les adaptateurs iSCSI logiciels est limité en raison des tailles de tampon d'envoi et de réception codées en dur

    Le débit avec les adaptateurs iSCSI logiciels est limité en raison des tailles de tampon d'envoi et de réception codées en dur, respectivement 600 Ko pour le tampon d'envoi et 256 Ko pour le tampon de réception. Par conséquent, les performances de l'adaptateur iscsi_vmk ne sont pas optimales.

    Ce problème est résolu dans cette version. Le correctif définit les tailles de tampon d'envoi et de réception des paramètres ajustables des connexions iSCSI. Vous pouvez définir la taille du tampon d'envoi à l'aide de la commande ESXCLI esxcli system settings advanced set -o /ISCSI/SocketSndBufLenKB -i <votre taille> avec une limite de 6 144 Ko. Vous pouvez définir la taille du tampon de réception à l'aide de la commande esxcli system settings advanced set -o /ISCSI/SocketRcvBufLenKB -i <votre taille> avec une limite de 6 144 Ko.

  • PR 2904241 : les machines virtuelles sur lesquelles NVIDIA virtual GPU (vGPU) est activé peuvent ne pas détruire toutes les ressources GPU à plusieurs instances lors de la mise hors tension de la machine virtuelle

    Lorsque plusieurs machines virtuelles NVIDIA vGPU se mettent hors tension simultanément, il arrive parfois que certaines ressources GPU à plusieurs instances (MIG) ne soient pas détruites. Par conséquent, la mise sous tension ultérieure de la VM vGPU peut échouer en raison des ressources MIG résiduelles.

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

  • PR 2944894 : les machines virtuelles sur les banques de données NFSv4.1 cessent de répondre pendant quelques secondes lors du basculement du stockage

    Dans de rares cas, lorsqu'un serveur NFSv4.1 renvoie une erreur temporaire lors du basculement du stockage, les machines virtuelles peuvent cesser de répondre pendant 10 secondes avant le redémarrage de l'opération.

    Ce problème est résolu dans cette version. Le correctif réduit le temps d'attente pour la récupération lors du basculement du stockage.

  • PR 2916980 : un hôte ESXi peut échouer avec un écran de diagnostic violet en raison de l'achèvement de paquets sur un ensemble de ports différent

    En de rares occasions, l'achèvement de paquets peut ne pas se produire sur le port ou l'ensemble de ports d'origine, mais sur un ensemble de ports différent, ce qui entraîne une boucle susceptible d'endommager la liste de paquets avec un pointeur non valide. Par conséquent, un hôte ESXi peut échouer avec un écran de diagnostic violet. Dans les journaux, vous voyez une erreur telle que PF Exception 14 in world 61176327:nsx.cp.tx IP 0xxxxxx addr 0x3c.

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

  • PR 2925733 : dans vSphere API, le champ memoryRangeLength de NumaNodeInfo ne compte pas toujours toute la mémoire dans le nœud NUMA d'hôte ESXi associé

    La mémoire d'un nœud NUMA d'hôte ESXi peut être composée de plusieurs plages physiques. Dans les versions d'ESXi antérieures à la version 7.0 Update 3f, les champs memoryRangeBegin et memoryRangeLength dans NumaNodeInfo donnent l'adresse physique de début d'hôte et la longueur d'une plage dans le nœud NUMA, en ignorant les plages supplémentaires.

    Ce problème est résolu dans cette version. Le champ memoryRangeLength est défini sur la quantité totale de mémoire dans le nœud NUMA, additionnée sur toutes les plages physiques. Le champ memoryRangeBegin est défini sur 0, car ces informations ne sont pas significatives en cas de plages multiples. 

  • PR 2932736 : si vous activez le chemin d'accès rapide sur High-Performance Plug-in (HPP) pour les périphériques logiciels 4KN 512e, les E/S peuvent échouer

    Si vous activez le chemin d'accès rapide sur HPP pour les périphériques logiciels 4KN 512e, il ne fonctionne pas comme prévu, car le chemin d'accès rapide ne gère pas Read-Modify-Write (R-M-W), qui doit utiliser un chemin lent. L'utilisation du chemin d'accès rapide sur les périphériques 4KN n'est pas prise en charge.

    Ce problème est résolu dans cette version. Le correctif s'assure que même si le chemin d'accès rapide est activé pour les périphériques logiciels 4KN 512e, le paramètre est ignoré et les E/S utilisent le chemin lent.

  • PR 2860126 : la suppression de snapshots de disques virtuels volumineux peut bloquer temporairement une machine virtuelle en cours d'exécution

    Si vous disposez d'une machine virtuelle en cours d'exécution avec des disques virtuels d'une capacité supérieure à 1 To et que vous supprimez un snapshot des disques sur cette machine virtuelle, celle-ci peut se bloquer pendant quelques secondes, voire quelques minutes. La machine virtuelle récupère finalement, mais ses charges de travail peuvent subir des interruptions. Ce problème se produit, car l'opération de suppression déclenche la consolidation des snapshots en arrière-plan, ce qui entraîne le retard. Ce problème est plus susceptible de se produire sur un stockage plus lent, tel que NFS.

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

  • PR 2875070 : des hôtes ESXi peuvent échouer avec un écran de diagnostic violet en raison de la mauvaise gestion des paquets DVFilter

    Les paquets DVFilter peuvent être transférés de manière incorrecte vers un port réseau, sur lequel le code d'achèvement de paquets ne parvient pas à s'exécuter. Par conséquent, des hôtes ESXi échouent avec un écran de diagnostic violet et l'erreur PF Exception 14 Vmxnet3VMKDevTxCompleteOne E1000DevTxCompleteOneWork.

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

  • PR 2883317 : les machines virtuelles peuvent perdre la connectivité par intermittence en raison d'un problème rare avec le pare-feu distribué (DFW)

    Dans de rares cas, DFW peut envoyer une liste de paquets à un ensemble de ports incorrect. Par conséquent, le service VMkernel peut échouer et les machines virtuelles perdent la connectivité. Dans le fichier vmkernel.log, vous voyez des messages tels que :
    2021-09-27T04:29:53.170Z cpu84:xxxx)NetPort: 206: Failure: lockModel[0] vs psWorldState->lockModel[0] there is no portset lock holding.

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

  • PR 2944521 : vous ne pouvez pas renommer des périphériques réclamés par High-Performance Plug-in (HPP)

    À partir de vSphere 7.0 Update 2, HPP devient le plug-in par défaut pour les périphériques NVMe et SCSI locaux, mais vous pouvez le remplacer par le plug-in ESX NMP (Native Multipathing Plug-in). Cependant, dans certains environnements, le passage de NMP à HPP rend inaccessibles certaines propriétés de périphériques réclamés par HPP, telles que le nom complet.

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

  • PR 2945697 : vous pouvez voir des états de chemin obsolètes vers des périphériques ALUA sur un hôte ESXi

    Dans une cible ALUA, si les ID de groupe de ports (TPGID) cibles sont modifiés pour un LUN, la réponse d'identification du périphérique mis en cache que SATP utilise peut ne pas se mettre à jour en conséquence. Par conséquent, ESXi peut ne pas refléter les états de chemin corrects pour le périphérique correspondant.

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

  • PR 2946036 : RTPG pour tous les chemins vers un volume signale le même état d'accès ALUA pour les périphériques enregistrés à l'aide de la traduction NVMe-SCSI sur un LUN

    Si vous utilisez la pile de traduction NVMe-SCSI pour enregistrer des périphériques NVMe dans votre système, les propriétés targetPortGroup et relativeTargetPortId obtiennent un ID de contrôleur de 0 pour tous les chemins. Par conséquent, une commande RTPG renvoie le même état d'accès ALUA pour tous les chemins d'accès de l'espace de noms, car chaque chemin d'accès tpgID correspond au premier descripteur, qui est 0.

    Ce problème est résolu dans cette version. Si vous utilisez des plug-ins tiers et qu'aucun tpgID pour le chemin n'est présent dans les descripteurs tpg (qui est une page ANA vierge pour le contrôleur), vous devez exécuter la commande RTPG sur ce chemin particulier pour remplir la page ANA de ce contrôleur et obtenir le descripteur tpg et l'état ALUA pour le chemin.

  • PR 2943674 : le contrôle de santé du service de fichiers vSAN comporte un avertissement après la modification du mot de passe du domaine d'utilisateur AD : Serveur de fichiers introuvable

    Si le mot de passe de l'administrateur du service de fichiers est modifié sur le serveur Active Directory, le mot de passe dans la configuration du domaine du service de fichiers vSAN peut ne pas correspondre. Si les mots de passe ne correspondent pas ou si le compte est verrouillé, certains partages de fichiers peuvent être inaccessibles. Le service de santé vSAN affiche l'avertissement suivant : Service de fichiers : Serveur de fichiers introuvable.

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

  • PR 2944919 : des disques de machine virtuelle (VMDK) avec liaison périmée s'affichent dans les banques de données vSphere Virtual Volumes

    Lorsque vous réinstallez un hôte ESXi après une panne, étant donné que l'instance ayant échoué ne redémarre jamais, les liaisons périmées des disques de machine virtuelle restent intactes sur le fournisseur VASA et les banques de données vSphere Virtual Volumes. Par conséquent, lorsque vous réinstallez l'hôte, vous ne pouvez pas supprimer les disques de machine virtuelle en raison de la liaison existante. Au fil du temps, de nombreux disques de machine virtuelle peuvent s'accumuler et consommer de l'espace de stockage inactif.

    Ce problème est résolu dans cette version. Toutefois, vous devez contacter le service VMware GSS (Global Support Services) pour implémenter la tâche.

  • PR 2912213 : le service hostd peut échouer à plusieurs reprises sur des machines virtuelles avec des périphériques série sans propriété fileName ni propriété serial.autodetect définie sur FALSE

    Dans de rares cas, un périphérique série sur une machine virtuelle peut ne pas avoir une propriété serial<N>.fileName et la propriété serial<N>.autodetect définie sur FALSE. Par conséquent, le service hostd peut échouer à plusieurs reprises.

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

  • PR 2951234 : si vous définissez une option de commutateur de stratégie de paramétrage du trafic ou de niveau de groupe de ports dont la taille est supérieure à 2 147 483 Kbits/s, les paramètres ne sont pas enregistrés

    Dans vSphere Client, si vous définissez l'une des options de paramétrage du trafic, comme Bande passante moyenne, Bande passante maximale ou Ampleur du pic, sur une valeur supérieure à 2 147 483 Kbits/s, les paramètres ne sont pas conservés.

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

  • PR 2945707 : les opérations de vSphere vMotion échouent après la mise à niveau vers ESXi 7.x pour les environnements configurés avec les API VAAI (vSphere APIs for Array Integration) pour le stockage relié au réseau (NAS)

    En raison du nombre faible de descripteurs de fichiers par défaut, certaines fonctionnalités telles que vSphere vMotion peuvent échouer dans VAAI pour les environnements NAS après la mise à niveau vers ESXi 7.x, en raison du nombre insuffisant de fichiers de disques de machine virtuelle pouvant être utilisés simultanément. Vous voyez des erreurs telles que Too many open files dans les journaux du démon vaai-nas dans le fichier syslog.log.

    Ce problème est résolu dans cette version. Le nombre par défaut de descripteurs de fichiers atteint le chiffre maximal de 64 000, contre 256 actuellement.

  • PR 2952427 : les machines virtuelles peuvent cesser de répondre en raison d'un problème de blocage rare dans un volume VMFS6

    Dans de rares cas, si une demande d'E/S s'exécute en parallèle avec une opération de suppression du mappage déclenchée par le SE invité sur une machine virtuelle à provisionnement dynamique, un blocage peut se produire dans un volume VMFS6. Par conséquent, les machines virtuelles sur ce volume cessent de répondre.

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

  • PR 2876044 : les opérations de vSphere Storage vMotion ou d'ajout à chaud peuvent échouer sur les machines virtuelles dont la taille de mémoire virtuelle est supérieure à 300 Go

    Pendant les opérations de vSphere Storage vMotion ou d'ajout à chaud sur une machine virtuelle disposant de plus de 300 Go de mémoire, le délai de basculement peut approcher de 2 minutes, ce qui entraîne un échec du délai d'expiration.

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

  • PR 2952003 : lors du démarrage, la restauration des configurations iSCSI peut échouer, et vous ne voyez pas certains LUN ou certaines banques de données après le démarrage

    Si vous ne supprimez pas la liaison de port après avoir supprimé une carte réseau VMkernel liée à un adaptateur iSCSI, la liaison de port périmée peut entraîner des problèmes après un redémarrage de l'hôte ESXi. Lors du démarrage, la liaison de la carte réseau VMkernel non existante à l'adaptateur iSCSI échoue et les configurations iSCSI ne peuvent pas être restaurées pendant le démarrage. Par conséquent, une fois le redémarrage terminé, il se peut que vous ne voyiez pas certains LUN ou certaines banques de données.

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

  • PR 2957062 : la banque de données NFSv4.1 reste dans l'état Inaccessible après un basculement du stockage

    Après un basculement de stockage, le client ESXi NFSv4.1 peut identifier par erreur le serveur NFS comme une entité différente et ignorer la récupération. Par conséquent, la banque de données NFSv4.1 reste à l'état Inaccessible.

    Ce problème est résolu dans cette version. Le correctif s'assure que le client NFSv4.1 identifie le serveur NFS après un basculement.

  • PR 2961033 : si un périphérique NVMe signale un avertissement critique, l'initialisation sur ESXi échoue et le périphérique est mis hors ligne

    Dans certains cas, comme la température dépassant le seuil, un périphérique NVMe peut signaler un avertissement critique et le contrôleur ESXi NVMe n'enregistre pas le périphérique et le met hors ligne.

    Ce problème est résolu dans cette version. Le correctif s'assure que les périphériques NVMe s'enregistrent dans le contrôleur ESXi NVMe, quels que soient les avertissements critiques. Si le périphérique est défectueux et n'est pas un état transitoire tel qu'une température élevée, le microprogramme du contrôleur NVMe doit envoyer les codes d'erreur appropriés lors du traitement d'une commande d'administration d'E/S.

  • PR 2928202 : vous ne pouvez pas accéder à certains partages dans le service de fichiers vSAN et voir les avertissements du démon VDFS

    Un problème rare lorsque le cache de blocs utilisé dépasse le cache réservé peut entraîner des problèmes de réservation dans le service de fichiers vSAN. Par conséquent, vous ne pouvez pas accéder à certains partages de fichiers, et le contrôle de santé affiche l'erreur Le démon VDFS n'est pas en cours d'exécution. Dans les journaux vdfsd-server, vous voyez des erreurs telles que :
    PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:621
    PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:626

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

  • PR 2949902 : les fichiers OVF peuvent être modifiés de manière inattendue et les machines virtuelles ne peuvent pas être importées

    Dans de rares cas, les requêtes de recherche en arrière-plan exécutées par le système vCenter Server sur un hôte ESXi ayant accès aux fichiers de disques de machine virtuelle des machines virtuelles exportées au format OVF peuvent accidentellement modifier les fichiers. Par conséquent, vous ne pouvez pas importer les machines virtuelles.

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

  • PR 2963401 : vous ne pouvez pas ajouter une règle de réclamation PSA de gestion multivoie à l'aide de l'outil de démarrage rapide

    En raison d'un problème de chargement de composant, l'ajout d'une règle de réclamation PSA de gestion multivoie à l'ensemble de règles de réclamation sur un système vCenter Server à l'aide de l'outil de démarrage rapide peut échouer.

    Ce problème est résolu dans cette version. Le correctif s'assure que tous les composants requis se chargent pour activer l'utilisation de l'outil de démarrage rapide.

  • PR 2965235 : des intrusions de LUN peuvent se produire sur les baies ALUA (Asymmetric Logical Unit Access) lors de l'arrêt ou du démarrage d'hôtes ESXi 7.x

    Après un arrêt ou un démarrage contrôlé d'un serveur dans un cluster de serveurs ESXi attachés à une baie ALUA, tous les LUN auxquels ce serveur a accès peuvent s'introduire sur un processeur de stockage sur la baie. Par conséquent, les performances des autres serveurs ESXi accédant aux LUN se dégradent.

    Ce problème est résolu dans cette version. Le correctif ajoute une vérification avant d'activer le dernier chemin sur la cible pendant la phase d'arrêt afin d'éviter l'intrusion des LUN.

  • PR 2966783 : l'hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'un problème rare avec un échec d'allocation de mémoire par PSA

    Dans de rares cas, lorsqu'un hôte ESXi subit une forte sollicitation de la mémoire, PSA ne gère pas correctement les échecs d'allocation de mémoire. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet avec une erreur telle que #PF Exception 14 in world 2098026:SCSI path sc IP / SCSI path scan helpers.

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

  • PR 2984134 : si une machine virtuelle redémarre alors qu'un snapshot est supprimé, elle peut échouer avec un vidage de mémoire

    Si une machine virtuelle en cours d'exécution redémarre lors d'une opération de suppression de snapshots, les disques de machine virtuelle peuvent être rouverts et fermés de manière incorrecte lors de la consolidation des snapshots. En conséquence, la machine virtuelle peut échouer. Cependant, il s'agit d'un problème de synchronisation qui se produit accidentellement.

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

  • PR 2929443 : le montage de banques de données VMFS6 avec la prise en charge de disques de machine virtuelle en cluster activée peut échouer de manière aléatoire

    Lors de la détection de périphériques, un conflit de réservation peut entraîner le signalement erroné d'ATS comme non pris en charge et, pour cette raison, ESXi utilise la réservation SCSI-2 au lieu d'ATS. Par conséquent, le montage de banques de données VMFS6 avec la prise en charge de disques de machine virtuelle en cluster activée peut échouer de manière aléatoire.

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

  • PR 2957732 : les serveurs de services de fichiers vSAN ne peuvent pas démarrer après la modification de l'UUID de l'hôte

    Certaines opérations peuvent modifier l'UUID de l'hôte. Par exemple, si vous réinstallez le logiciel ESXi ou que vous déplacez l'hôte entre les clusters, l'UUID de l'hôte peut changer. Si l'UUID de l'hôte change pendant la durée d'interruption de service de fichiers vSAN, les serveurs de services de fichiers vSAN ne peuvent pas démarrer.

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

  • PR 2955688 : le service de fichiers vSAN peut ne pas fonctionner comme prévu après sa désactivation et sa réactivation

    Si vous désactivez le service de fichiers vSAN sans partage de fichiers existant, vSAN supprime le domaine du service de fichiers. Un échec de suppression d'un serveur peut interrompre le processus et laisser certaines métadonnées. Lorsque vous réactivez le service de fichiers, les anciennes métadonnées peuvent empêcher le service de fichiers de fonctionner comme prévu.

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

  • PR 2965146 : la valeur DURÉE DE TRANSITION IMPLICITE renvoyée à partir de la commande SCSI Report Target Port Groups peut ne pas être correcte

    La commande Report Target Port Groups peut renvoyer une valeur incorrecte dans le champ DURÉE DE TRANSITION IMPLICITE, ce qui affecte la couche de translation SCSI vers NVMe. Dans des cas tels que la migration de plusieurs dispositifs, la durée de transition ALUA est critique pour certains logiciels de gestion multivoie, par exemple PowerPath, pour effectuer des opérations correctes.

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

  • PR 2992648 : latences élevées observées après le redémarrage ou le remontage du groupe de disques

    Les annulations de mappages de petite taille en attente peuvent être bloquées lorsque vous redémarrez un hôte ou que vous remontez un groupe de disques. Les annulations de mappage en attente peuvent entraîner un encombrement des journaux, ce qui entraîne une latence d'E/S.

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

  • PR 2964856 : le chemin d'accès au répertoire /productLocker d'une banque de données est tronqué après l'application du correctif ESXi 7.x

    Après la première mise à niveau ou mise à jour de votre système vers ESXi 7.x, avec chaque mise à jour consécutive, également appelée correctif, vous pouvez voir une troncation dans le chemin d'accès au répertoire /productLocker d'une banque de données. Par exemple, si votre premier correctif sur ESXi 7.x est de la version 7.0 Update 2 à la version 7.0 Update 3, le chemin d'accès au répertoire /productLocker est semblable à l'origine à /vmfs/volumes/xxx/VMware-Tools/productLocker/. Cependant, pour chaque correctif consécutif, par exemple de la version 7.0 Update 3 à la version 7.0 Update 3c, le chemin devient semblable à /VMware-Tools/productLocker/.

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

  • PR 2963038 : objet inaccessible sur un cluster vSAN étendu ou à deux nœuds

    Dans un cluster vSAN étendu ou un cluster à deux nœuds, les votes de quorum peuvent ne pas être distribués correctement pour les objets avec un PFTT de 1 et un SFTT de 1 ou plus. Si un site tombe en panne et qu'un hôte ou un disque supplémentaire échoue sur le site actif, l'objet peut perdre le quorum et devenir inaccessible.

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

  • PR 2961832 : les hôtes ESXi peuvent échouer lors du redimensionnement d'un disque de machine virtuelle non aligné sur 512 octets

    Une demande de redimensionnement d'objet peut échouer si la nouvelle taille n'est pas alignée sur 512 octets. Ce problème peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet.

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

  • PR 2935355 : vous pouvez voir une augmentation de la consommation de CPU sur un hôte ESXi en raison d'une fuite de l'utilitaire PacketCapture (pktcap-uw)

    Dans certains cas, par exemple lorsqu'une machine virtuelle redémarre, une session de protocole SSH en cours d'exécution que l'utilitaire pktcap-uw utilise pour surveiller et valider les configurations de commutateur sur l'hôte ESXi peut se terminer, mais l'utilitaire pktcap-uw peut continuer à essayer de traiter les paquets. Par conséquent, l'utilitaire commence à consommer plus de CPU que d'habitude. Vous pouvez utiliser la commande esxtop -a pour suivre les performances du CPU.

    Ce problème est résolu dans cette version. Le correctif empêche les fuites de l'utilitaire pktcap-uw qui entraînent une augmentation de la consommation de CPU. Vous pouvez utiliser la commande ps -u | grep pktcap pour voir si un processus utilitaire pktcap-uw en arrière-plan s'exécute, bien qu'il n'ait aucune incidence sur les performances du CPU. Si un processus zombie s'exécute toujours, vous pouvez utiliser la commande kill -9 pour y mettre fin.

  • PR 2973031 : le contrôle de santé vSAN indique que le périphérique NVMe certifié n'est pas certifié

    Dans l'instance de vCenter Server exécutant la version 7.0 Update 3, un périphérique NVMe certifié peut présenter l'avertissement de contrôle de santé suivant : NVMe device is not VMware certified. L'avertissement de contrôle de santé suivant peut également s'afficher : NVMe device can not be identified.

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

  • PR 2968157 : la commande ESXCLI hardware ipmi bmc get ne renvoie pas l'adresse IPv6 d'un contrôleur BMC (Baseboard Management Controller) IPMI

    La commande ESXCLI hardware ipmi bmc get ne renvoie pas l'adresse IPv6 d'un contrôleur BMC en raison d'une analyse incorrecte.

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

  • PR 2963328 : l'assistant d'arrêt échoue pour un cluster vSAN étendu ou à deux nœuds avec l'erreur : Hôte déconnecté trouvé à partir d'orch

    Si l'hôte témoin n'est pas accessible par les hôtes du cluster, l'assistant d'arrêt du cluster vSAN peut échouer pour un cluster étendu ou des clusters à deux nœuds. Ce problème se produit lorsque le trafic de données vSAN et le trafic témoin utilisent des cartes vmknic différentes. Dans vSphere Client, le message d'erreur suivant s'affiche sur la page Services vSAN : Disconnected host found from orch <adresse IP du témoin>. Si vCenter est hébergé sur le cluster, vSphere Client n'est pas disponible lors de l'arrêt et le message d'erreur est disponible dans l'instance de Host Client dans laquelle la machine virtuelle vCenter réside.

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

  • PR 2882789 : lors de l'exploration d'une banque de données vSphere Virtual Volumes, vous voyez l'UUID de certaines machines virtuelles au lieu de leur nom

    Dans vSphere Client, lorsque vous cliquez avec le bouton droit sur une banque de données, vous pouvez voir l'UUID de certaines machines virtuelles dans une banque de données vSphere Virtual Volumes, par exemple naa.xxxx, au lieu de leur nom. Ce problème se produit rarement dans des environnements à grande échelle comportant un grand nombre de conteneurs et de machines virtuelles sur une banque de données vSphere Virtual Volumes. Le problème n'a aucun impact fonctionnel, tel qu'une incidence sur les opérations de machine virtuelle, la sauvegarde ou toute autre valeur que l'affichage de machine virtuelle dans vSphere Client.

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

  • PR 2928268 : en raison d'un problème rare lié à l'infrastructure, des hôtes ESXi peuvent cesser de répondre

    En raison d'un problème rare avec l'infrastructure ESXi, un fournisseur VASA lent peut entraîner une situation dans laquelle les banques de données vSphere Virtual Volumes sont inaccessibles et l'hôte ESXi cesse de répondre.

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

  • PR 2946550 : lorsque vous arrêtez un hôte ESXi, il ne se met pas hors tension et un message d'erreur s'affiche

    Dans certains environnements, lorsque vous arrêtez un hôte ESXi, il ne se met pas hors tension et un écran s'affiche avec le message This system has been halted. Il est recommandé d'utiliser le bouton de réinitialisation ou d'alimentation pour redémarrer.

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

  • PR 2949777 : si le paramètre LargeBAR d'un périphérique vmxnet3 est activé sur ESX 7.0 Update 3 et versions ultérieures, les machines virtuelles peuvent perdre la connectivité

    Le paramètre LargeBAR qui étend le registre d'adresses de base (BAR) sur un périphérique vmxnet3 prend en charge le relais uniforme (UPT). Toutefois, UPT n'est pas pris en charge sur ESX 7.0 Update 3 et versions ultérieures, et si le pilote vmxnet3 est rétrogradé vers une version antérieure à la version 7.0 et que le paramètre LargeBAR est activé, les machines virtuelles peuvent perdre la connectivité.

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

  • PR 2984245 : les fichiers journaux redondants prennent beaucoup d'espace de stockage

    Si vous supprimez à chaud des disques indépendants non persistants d'une machine virtuelle sur laquelle le paramètre de configuration vmx.reboot.PowerCycle est activé, ESXi stocke un fichier journal redo. Si une telle machine virtuelle est une machine virtuelle proxy de sauvegarde, vous pouvez voir un grand nombre de fichiers journaux redondants pour prendre une quantité importante de stockage.

    Solution : désactivez le paramètre vmx.reboot.PowerCycle sur les machines virtuelles proxy de sauvegarde en effectuant un cycle d'alimentation sur la machine virtuelle ou en utilisant la commande cmdlet PowerCLI Set-AdvancedSetting. Supprimez les fichiers journaux redo redondants.

  • PR 2939395 : les hôtes ESXi échouent par intermittence avec un écran de diagnostic violet avec un vidage de mémoire indiquant des erreurs J3_DeleteTransaction et J6ProcessReplayTxnList

    Dans de rares cas, lorsqu'un hôte ESXi tente d'accéder à une entrée sans mise en cache à partir d'un cache de pool de ressources, l'hôte échoue par intermittence avec un écran de diagnostic violet PF Exception 14 et un fichier de vidage de mémoire. Dans le fichier de vidage, vous voyez des erreurs pour les modules J3_DeleteTransaction et J6ProcessReplayTxnList qui indiquent le problème.

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

  • PR 2952432 :  des hôtes ESXi peuvent cesser de répondre en raison d'un problème rare avec VMFS qui entraîne une contention de verrouillage élevée des threads de service hostd

    Un problème rare avec VMFS peut entraîner une contention de verrouillage élevée des threads de service hostd, voire des blocages, pour les appels de système de fichiers de base tels que open, access ou rename. Par conséquent, l'hôte ESXi cesse de répondre.

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

  • PR 2960882 : si le protocole d'authentification dans une configuration d'agent SNMP ESXi est MD5, les mises à niveau vers ESXi 7.x peuvent échouer

    Étant donné que le protocole d'authentification MD5 est obsolète à compter d'ESXi 7.x, si une configuration d'agent SNMP ESXi utilise le protocole d'authentification MD5, les mises à niveau vers ESXi 7.x échouent.

    Ce problème est résolu dans cette version. Le correctif supprime le protocole d'authentification MD5 et vous voyez un message VOB (VMkernel Observation), tel que Upgrade detected a weak crypto protocol (MD5) and removed it. Regénérez les utilisateurs v3.

  • PR 2957966 : les espaces du paramètre Syslog.global.logHost peuvent entraîner l'échec des mises à niveau vers ESXi 7.x

    Dans ESXi 7.x, le paramètre Syslog.global.logHost, qui définit une liste délimitée par des virgules d'hôtes distants et de spécifications pour les transmissions de messages, ne tolère pas d'espaces après la virgule. Les versions d'ESXi antérieures à 7.x tolèrent un espace après la virgule dans le paramètre Syslog.global.logHost. Par conséquent, les mises à niveau vers ESXi 7.x peuvent échouer.

    Ce problème est résolu dans cette version. Le correctif autorise des espaces après la virgule.

  • PR 2967359 : vous pouvez voir une erreur d'E/S basée sur la cohérence logique pour les machines virtuelles exécutées sur un snapshot

    Un problème lié à l'utilisation de la structure de données probabiliste du filtre de Bloom qui vise à optimiser les E/S de lecture pour les machines virtuelles s'exécutant sur un snapshot peut entraîner une erreur d'E/S basée sur la cohérence logique lorsque la machine virtuelle est en cours d'exécution sur un snapshot. Le problème est limité et se produit uniquement si vous exécutez SQL Server sur un snapshot.

    Ce problème est résolu dans cette version. Le correctif désactive l'utilisation de la fonctionnalité de filtre de Bloom jusqu'à ce que la cause principale du problème soit résolue.

  • PR 2974376 : les hôtes ESXi échouent avec un écran de diagnostic violet avec une erreur NMI en raison d'un verrouillage de CPU rare

    Un problème lié au processus d'analyse des banques de données pour aider les allocations de blocs de fichiers pour les fichiers légers peut entraîner un verrouillage de CPU dans certains cas. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet avec une erreur semblable à PSOD - @BlueScreen: NMI.

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

  • PR 2905357 : vous voyez un nombre anormalement élevé de messages Tâche créée et Tâche terminée dans les fichiers journaux hostd

    Les fichiers journaux du service hostd peuvent obtenir un nombre anormalement élevé de messages Tâche créée et Tâche terminée pour des tâches invisibles, ce qui peut à son tour réduire la durée de conservation des journaux. 

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

  • PR 2956080 : les opérations de lecture et d'écriture dans une banque de données vSphere Virtual Volumes peuvent échouer

    Si une commande SCSI sur un point de terminaison de protocole d'une banque de données vSphere Virtual Volumes échoue, le point de terminaison peut obtenir un état Non pris en charge, qui peut être mis en cache. Par conséquent, les commandes SCSI suivantes sur ce point de terminaison de protocole échouent avec un code d'erreur tel que 0x5 0x20, et les opérations de lecture et d'écriture sur une banque de données vSphere Virtual Volumes échouent.

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

  • PR 2985369 : si le contrôleur NVMe signale un état ÉCHEC, il peut perdre la connectivité aux hôtes ESXi

    Dans certains cas, comme une erreur de port hors service, les hôtes ESXi peuvent perdre la connectivité au contrôleur NVMe bien que certaines files d'attente d'E/S soient toujours actives.

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

  • PR 2892901 : si le disque d'une machine virtuelle répliquée n'est pas aligné sur 512, la mise sous tension de la machine virtuelle peut échouer

    Si vous répliquez une machine virtuelle à l'aide de vSphere Replication et que le nombre de disques de la machine virtuelle augmente à un nombre qui n'est pas aligné sur 512, la machine virtuelle ne peut pas être mise sous tension.

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

  • PR 2912230 : si le nombre de CPU n'est pas un multiple du nombre de cœurs par socket dans la configuration d'une machine virtuelle, la machine virtuelle ne peut pas être mise sous tension

    Si le nombre de CPU que vous définissez avec le paramètre ConfigSpec#numCPU n'est pas un multiple du nombre de cœurs par socket que vous définissez avec le paramètre ConfigSpec#numCoresPerSocket dans la configuration d'une machine virtuelle, la machine virtuelle ne se met pas sous tension.

    Ce problème est résolu dans cette version. Le correctif vous empêche de définir une valeur numCPU qui n'est pas un multiple de la valeur numCoresPerSocket.

  • PR 2949375 : l'hôte vSAN dans le cluster étendu ne parvient pas à passer en mode de maintenance avec le mode Assurer l'accessibilité

    Ce problème affecte les hôtes des clusters étendus avec les paramètres de stratégie locality=Aucun, HFT=0, SFT=1 ou SFT=2. Lorsque vous placez un hôte en mode de maintenance avec Assurer l'accessibilité, l'opération peut rester à 100 % pendant un long moment ou échouer après 60 minutes.

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

  • PR 2950686 : alarmes de latence réseau vSAN fréquentes après la mise à niveau vers ESXi 7.0 Update 2

    Après la mise à niveau d'un hôte ESXi vers la version 7.0 Update 2, vous pouvez remarquer de fréquentes alarmes de latence réseau vSAN sur le cluster lorsque le service de performances vSAN est activé. Les résultats de latence indiquent que la plupart des alarmes sont émises par le nœud vSAN principal.

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

  • PR 2928789 : le stockage NVMe over RDMA devient inaccessible après la mise à jour d'ESXi 7.0, 7.0 Update 1 ou 7.0 Update 2 vers la version 7.0 Update 3c

    En raison d'une modification de la taille de la file d'attente d'administration par défaut pour les contrôleurs NVMe over RDMA dans ESXi 7.0 Update 3c, les mises à jour d'ESXi 7.0, 7.0 Update 1 ou 7.0 Update 2 vers la version 7.0 Update 3c peuvent rendre le stockage NVMe over RDMA inaccessible.

    Ce problème est résolu dans cette version. Si vous devez effectuer une mise à jour vers ESXi 7.0 Update 3c, vous pouvez exécuter le script joint dans l'article 88938 de la base de connaissances VMware avant la mise à jour pour vous assurer que le problème est résolu.

  • PR 2983089 : un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une condition de concurrence dans les ports de conteneur

    En raison d'une condition de concurrence rare, lorsqu'un port de conteneur tente de réacquérir un verrouillage qu'il détient déjà, un hôte ESXi peut échouer avec un écran de diagnostic violet lorsque des machines virtuelles avec des ports de conteneur sont mises hors tension ou migrées à l'aide de vSphere vMotion. Ce problème se produit en raison d'une duplication des ID de port.

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

  • PR 2925133 : lorsque vous désactivez ou interrompez vSphere Fault Tolerance, l'envoi d'un ping aux machines virtuelles peut expirer

    Lorsque vous désactivez ou interrompez vSphere FT, les machines virtuelles peuvent perdre temporairement la connectivité et ne pas répondre aux commandes ping ou à tout trafic réseau. L'envoi d'une commande ping aux machines virtuelles peut expirer successivement sur une courte période, par exemple 20 secondes.

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

esx-update_7.0.3-0.50.20036589
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_7.0.3-0.50.20036589
  • VMware_bootbank_loadesx_7.0.3-0.50.20036589
PR résolus  S.O.
Numéros CVE S.O.

Met à jour les VIB loadesx et esx-update.

    Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.703.0.50.20036589
    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
    • VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.50.20036589
    • VMW_bootbank_bnxtnet_216.0.50.0-44vmw.703.0.50.20036589
    PR résolus  S.O.
    Numéros CVE S.O.

    Met à jour le VIB bnxtnet.

      Broadcom-ELX-lpfc_14.0.169.26-5vmw.703.0.50.20036589
      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
      • VMW_bootbank_lpfc_14.0.169.26-5vmw.703.0.50.20036589
      PR résolus  2929821
      Numéros CVE S.O.

      Met à jour le VIB lpfc pour résoudre le problème suivant :
      • PR 2929821 : des hôtes ESXi perdent l'accès aux baies de stockage Dell EMC Unity après la mise à niveau du pilote lpfc vers la version 14.0.x.x

        des hôtes ESXi peuvent perdre l'accès aux baies de stockage Unity après la mise à niveau du pilote lpfc vers la version 14.0.x.x. Vous voyez des erreurs telles que protocol failure detected during processing of FCP I/O et rspInfo3 x2 dans les journaux du pilote.

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

      Broadcom-lsiv2-drivers-plugin_1.0.0-12vmw.703.0.50.20036589
      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 Non
      Matériel concerné S.O.
      Logiciels concernés S.O.

      VIB inclus
      • VMware_bootbank_lsuv2-lsiv2-drivers-plugin_1.0.0-12vmw.703.0.50.20036589
      PR résolus  2960435
      Numéros CVE S.O.

      Met à jour le VIB lsuv2-lsiv2-drivers-plugin.
      • PR 2960435 : les modifications de l'emplacement du disque prennent beaucoup de temps pour s'afficher à partir de vSphere Client ou à l'aide d'ESXCLI

        Pour les pilotes liés à LSI, lorsqu'un serveur ESXi démarre, si vous débranchez un disque et le branchez dans un autre emplacement sur le même hôte, les modifications de l'emplacement du disque peuvent prendre un certain temps à s'afficher à partir de vSphere Client ou à l'aide de la commande ESXCLI esxcli storage core device physical get -d. Le problème est spécifique aux pilotes avec de nombreux disques connectés au pilote, 150 et plus, et il est résolu dans les 5 minutes qui suivent.

        Ce problème est résolu dans cette version. Le correctif ajoute un cache de tous les périphériques connectés à un contrôleur LSI au moment du démarrage pour s'assurer que les appels à l'inventaire strange sont rapidement traités.

      Intel-icen_1.4.1.20-1vmw.703.0.50.20036589
      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
      • VMW_bootbank_icen_1.4.1.20-1vmw.703.0.50.20036589
      PR résolus 2965878
      Numéros CVE S.O.

      Met à jour le VIB icen.

      • Avec ESXi 7.0 Update 3f, le pilote Intel-icen prend en charge les fonctions de mise en réseau sur les cartes réseau E822/E823 pour les plates-formes Intel Icelake-D. Les fonctions ENS (Enhanced Network Stack) et RDMA sur ces périphériques ne sont pas prises en charge.

      Intel-irdman_1.3.1.22-1vmw.703.0.50.20036589
      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
      • VMW_bootbank_irdman_1.3.1.22-1vmw.703.0.50.20036589
      PR résolus S.O.
      Numéros CVE S.O.

      Met à jour le VIB irdman.

        Intel-ne1000_0.9.0-1vmw.703.0.50.20036589
        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 Non
        Matériel concerné S.O.
        Logiciels concernés S.O.
        VIB inclus
        • VMW_bootbank_ne1000_0.9.0-1vmw.703.0.50.20036589
        PR résolus 2957673
        Numéros CVE S.O.

        Met à jour le VIB ne1000

        • ESXi 7.0 Update 3f met à niveau le pilote Intel-ne1000 pour prendre en charge les périphériques Intel I219-LM requis pour les modèles de serveur plus récents, tels que la plate-forme Intel Lake-S. Le déchargement de segmentation TCP pour les périphériques I219 est désactivé en raison de problèmes connus dans le DMA matériel.

        VMware-iser_1.1.0.1-1vmw.703.0.50.20036589
        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
        • VMW_bootbank_iser_1.1.0.1-1vmw.703.0.50.20036589
        PR résolus 2921564
        Numéros CVE S.O.

        Met à jour le VIB iser.

        • PR 2921564 : des hôtes ESXi disposant d'initiateurs iSER connectés à des baies IBM FlashSystem V9000 peuvent échouer avec un écran de diagnostic violet en raison d'un problème rare

          Un problème d'erreur de pointeur null très rare peut entraîner l'échec des hôtes ESXi sur les baies IBM FlashSystem V9000 avec un écran de diagnostic violet et une erreur telle que #PF Exception 14 in world 2098414:CqWorld IP 0xxxxx addr 0xxxx.

          Ce problème est résolu dans cette version. Le correctif ajoute un traitement spécial à un état d'erreur RDMA pour l'une des commandes de gestion SCSI.

        VMware-vmkusb_0.1-7vmw.703.0.50.20036589
        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
        • VMW_bootbank_vmkusb_0.1-7vmw.703.0.50.20036589
        PR résolus S.O.
        Numéros CVE S.O.

        Met à jour le VIB vmkusb.

          ESXi_7.0.3-0.45.20036586
          Catégorie des correctifs Sécurité
          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_native-misc-drivers_7.0.3-0.45.20036586
          • VMware_bootbank_bmcal_7.0.3-0.45.20036586
          • VMware_bootbank_esx-ui_1.43.8-19798623
          • VMware_bootbank_vsanhealth_7.0.3-0.45.20036586
          • VMware_bootbank_esxio-combiner_7.0.3-0.45.20036586
          • VMware_bootbank_esx-xserver_7.0.3-0.45.20036586
          • VMware_bootbank_trx_7.0.3-0.45.20036586
          • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.45.20036586
          • VMware_bootbank_vdfs_7.0.3-0.45.20036586
          • VMware_bootbank_vsan_7.0.3-0.45.20036586
          • VMware_bootbank_cpu-microcode_7.0.3-0.45.20036586
          • VMware_bootbank_esx-base_7.0.3-0.45.20036586
          • VMware_bootbank_gc_7.0.3-0.45.20036586
          • VMware_bootbank_crx_7.0.3-0.45.20036586
          PR résolus 2920287, 2946147, 2946217, 2946222, 2946671, 2946863, 2947156, 2951864, 2951866, 2972147, 2972151
          Numéros CVE CVE-2004-0230, CVE-2020-7451, CVE-2015-2923, CVE-2015-5358, CVE-2013-3077, CVE-2015-1414, CVE-2018-6918, CVE-2020-7469, CVE-2019-5611, CVE-2020-7457, CVE-2018-6916, CVE-2019-5608, CVE-2022-23816, CVE-2022-23825, CVE-2022-28693, CVE-2022-29901

          Les bulletins ESXi et esx-update sont interdépendants. Incluez toujours les deux dans une ligne de base de correctifs d'hôte ESXi ou incluez le bulletin de cumul dans la ligne de base pour éviter un échec pendant le correctif de l'hôte.
          Met à jour les VIB native-misc-drivers, bmcal, esx-ui, vsanhealth, esxio-combiner, esx-xserver, trx, esx-dvfilter-generic-fastpath, vdfs, vsan, cpu-microcode, esx-base, gc et crx pour résoudre les problèmes suivants :

          • ESXi 7.0 Update 3f fournit les mises à jour de sécurité suivantes :
            • L'analyseur XML Expat a été mis à jour vers la version 2.4.7.
            • La base de données SQLite a été mise à jour vers la version 3.37.2.
            • La bibliothèque cURL a été mise à jour vers la version 7.81.0.
            • Le module OpenSSL a été mis à jour vers la version openssl-1.0.2ze.
            • La bibliothèque ESXi userworld libxml2 a été mise à jour vers la version 2.9.14.
            • Le module Python a été mis à jour vers la version 3.8.13.
            • La bibliothèque zlib a été mise à jour vers la version 1.2.12.
            • Cette version résout la vulnérabilité critique CVE-2004-0230. VMware a évalué que ce problème se situe dans la plage de gravité faible avec un score de base CVSSv3 maximal de 3,7.
            • Cette version résout la vulnérabilité critique CVE-2020-7451. VMware a évalué que ce problème se situe dans la plage de gravité moyenne avec un score de base CVSSv3 maximal de 5,3.
            • Cette version résout la vulnérabilité critique CVE-2015-2923. VMware a évalué que ce problème se situe dans la plage de gravité moyenne avec un score de base CVSSv3 maximal de 6,5.
            • Cette version résout la vulnérabilité critique CVE-2015-5358. VMware a évalué que ce problème se situe dans la plage de gravité moyenne avec un score de base CVSSv3 maximal de 6,5.
            • Cette version résout la vulnérabilité critique CVE-2013-3077. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,0.
            • Cette version résout la vulnérabilité critique CVE-2015-1414. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5.  
            • Cette version résout la vulnérabilité critique CVE-2018-6918. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5.
            • Cette version résout la vulnérabilité critique CVE-2020-7469. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5.
            • Cette version résout la vulnérabilité critique CVE-2019-5611. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5. 
            • Cette version résout la vulnérabilité critique CVE-2020-7457. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,8. 
            • Cette version résout la vulnérabilité critique CVE-2018-6916. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 8,1.
            • Cette version résout la vulnérabilité critique CVE-2019-5608. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 8,1.

          • Cette version résout les vulnérabilités critiques CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 et CVE-2022-29901. Pour plus d'informations sur ces vulnérabilités et leur impact sur les produits VMware, reportez-vous à la page VMSA-2022-0020.

          esx-update_7.0.3-0.45.20036586
          Catégorie des correctifs Sécurité
          Gravité des correctifs Critique
          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-update_7.0.3-0.45.20036586
          • VMware_bootbank_loadesx_7.0.3-0.45.20036586
          PR résolus S.O.
          Numéros CVE S.O.

          Met à jour les VIB loadesx et esx-update.

            VMware-VM-Tools_12.0.0.19345655-20036586
            Catégorie des correctifs Sécurité
            Gravité des correctifs Critique
            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_12.0.0.19345655-20036586
            PR résolus S.O.
            Numéros CVE S.O.

            Met à jour le VIB tools-light.

              ESXi-7.0U3f-20036589-standard
              Nom du profil ESXi-7.0U3f-20036589-standard
              Build Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.
              Fournisseur VMware, Inc.
              Date de publication 12 juillet 2022
              Niveau d'acceptation PartnerSupported
              Matériel concerné S.O.
              Logiciels concernés S.O.
              VIB concernés
              • VMware_bootbank_esxio-combiner_7.0.3-0.50.20036589
              • VMware_bootbank_esx-ui_1.43.8-19798623
              • VMware_bootbank_esx-xserver_7.0.3-0.50.20036589
              • VMware_bootbank_cpu-microcode_7.0.3-0.50.20036589
              • VMware_bootbank_trx_7.0.3-0.50.20036589
              • VMware_bootbank_vsanhealth_7.0.3-0.50.20036589
              • VMware_bootbank_esx-base_7.0.3-0.50.20036589
              • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.50.20036589
              • VMware_bootbank_gc_7.0.3-0.50.20036589
              • VMware_bootbank_native-misc-drivers_7.0.3-0.50.20036589
              • VMware_bootbank_bmcal_7.0.3-0.50.20036589
              • VMware_bootbank_vsan_7.0.3-0.50.20036589
              • VMware_bootbank_vdfs_7.0.3-0.50.20036589
              • VMware_bootbank_crx_7.0.3-0.50.20036589
              • VMware_bootbank_esx-update_7.0.3-0.50.20036589
              • VMware_bootbank_loadesx_7.0.3-0.50.20036589
              • VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.50.20036589
              • VMW_bootbank_bnxtnet_216.0.50.0-44vmw.703.0.50.20036589
              • VMW_bootbank_lpfc_14.0.169.26-5vmw.703.0.50.20036589
              • VMware_bootbank_lsuv2-lsiv2-drivers-plugin_1.0.0-12vmw.703.0.50.20036589
              • VMW_bootbank_icen_1.4.1.20-1vmw.703.0.50.20036589
              • VMW_bootbank_irdman_1.3.1.22-1vmw.703.0.50.20036589
              • VMW_bootbank_ne1000_0.9.0-1vmw.703.0.50.20036589
              • VMW_bootbank_iser_1.1.0.1-1vmw.703.0.50.20036589
              • VMW_bootbank_vmkusb_0.1-7vmw.703.0.50.20036589
              • VMware_locker_tools-light_12.0.0.19345655-20036586
              PR résolus 2916848, 2817702, 2937074, 2957732, 2984134, 2944807, 2985369, 2907963, 2949801, 2984245, 2915911, 2990593, 2992648, 2905357, 2980176, 2974472, 2974376, 2972059, 2973031, 2967359, 2860126, 2878245, 2876044, 2968157, 2960242, 2970238, 2966270, 2966783, 2963328, 2939395, 2966362, 2946550, 2958543, 2966628, 2961584, 2911056, 2965235, 2952427, 2963401, 2965146, 2963038, 2963479, 2949375, 2961033, 2958926, 2839515, 2951139, 2878224, 2954320, 2952432, 2961346, 2857932, 2960949, 2960882, 2957966, 2929443, 2956080, 2959293, 2944919, 2948800, 2928789, 2957769, 2928268, 2957062, 2792139, 2934102, 2953709, 2950686, 2953488, 2949446, 2955016, 2953217, 2956030, 2949902, 2944894, 2944521, 2911363, 2952205, 2894093, 2910856, 2953754, 2949777, 2925733, 2951234, 2915979, 2904241, 2935355, 2941263, 2912661, 2891231, 2928202, 2928268, 2867146, 2244126, 2912330, 2898858, 2906297, 2912213, 2910340, 2745800, 2912182, 2941274, 2912230, 2699748, 2882789, 2869031, 2913017, 2864375, 2929821, 2957673, 2921564, 2925133 et 2965277
              Numéros CVE associés S/O
              • Ce correctif met à jour les problèmes suivants :

                • Les appels pyVmomi à vSphere API EnvironmentBrowser.QueryConfigTargetEx peuvent échouer avec le message UnknownWsdlTypeError.

                • Le module de santé du matériel d'ESXi peut ne pas parvenir à décoder certains capteurs de type Événement système lorsque le nom d'un serveur physique est modifié. Par conséquent, dans vSphere Client, vous voyez l'état Inconnu pour les capteurs de type Événement système sous Surveiller > Santé du matériel.

                • Si vous définissez le paramètre avancé vmx.reboot.powerCycle sur une machine virtuelle sur TRUE, lorsque le SE invité initie un redémarrage, la machine virtuelle se met hors tension, puis se met sous tension. Cependant, si un cycle d'alimentation se produit pendant une migration à l'aide de vSphere vMotion, l'opération échoue et la machine virtuelle sur l'hôte source peut ne pas se mettre sous tension.

                • Si un socket rencontre un échec de connexion alors qu'il est interrogé lors de la communication interne entre des sockets de domaine UNIX, une concurrence de données peut se produire. Par conséquent, dans certains cas, l'hôte ESXi peut accéder à une région de mémoire non valide et échouer avec un écran de diagnostic violet avec le message #PF Exception 14 et des erreurs semblables à UserDuct_PollSize() et UserSocketLocalPoll().

                • Si un adaptateur iSCSI matériel sur un hôte ESXi de votre environnement utilise des pseudo cartes réseau, il se peut que vous ne puissiez pas créer un profil d'hôte à partir d'un tel hôte, car les pseudo cartes réseau ne disposent pas de l'adresse PCI et du nom de fournisseur requis pour un profil.

                • Les conditions de concurrence dans le pilote iscsi_vmk peuvent entraîner des opérations d'E/S bloquées ou des délais d'expiration de pulsation sur une banque de données VMFS. Par conséquent, certaines machines virtuelles peuvent cesser de répondre.

                • Le débit avec les adaptateurs iSCSI logiciels est limité en raison des tailles de tampon d'envoi et de réception codées en dur, respectivement 600 Ko pour le tampon d'envoi et 256 Ko pour le tampon de réception. Par conséquent, les performances de l'adaptateur iscsi_vmk ne sont pas optimales.

                • Lorsque plusieurs machines virtuelles NVIDIA vGPU se mettent hors tension simultanément, il arrive parfois que certaines ressources GPU à plusieurs instances (MIG) ne soient pas détruites. Par conséquent, la mise sous tension ultérieure de la VM vGPU peut échouer en raison des ressources MIG résiduelles.

                • Dans de rares cas, lorsqu'un serveur NFSv4.1 renvoie une erreur temporaire lors du basculement du stockage, les machines virtuelles peuvent cesser de répondre pendant 10 secondes avant le redémarrage de l'opération.

                • En de rares occasions, l'achèvement de paquets peut ne pas se produire sur le port ou l'ensemble de ports d'origine, mais sur un ensemble de ports différent, ce qui entraîne une boucle susceptible d'endommager la liste de paquets avec un pointeur non valide. Par conséquent, un hôte ESXi peut échouer avec un écran de diagnostic violet. Dans les journaux, vous voyez une erreur telle que PF Exception 14 in world 61176327:nsx.cp.tx IP 0xxxxxx addr 0x3c.

                • La mémoire d'un nœud NUMA d'hôte ESXi peut être composée de plusieurs plages physiques. Dans les versions d'ESXi antérieures à la version 7.0 Update 3f, les champs memoryRangeBegin et memoryRangeLength dans NumaNodeInfo donnent l'adresse physique de début d'hôte et la longueur d'une plage dans le nœud NUMA, en ignorant les plages supplémentaires.

                • Si vous activez le chemin d'accès rapide sur HPP pour les périphériques logiciels 4KN 512e, il ne fonctionne pas comme prévu, car le chemin d'accès rapide ne gère pas Read-Modify-Write (R-M-W), qui doit utiliser un chemin lent. L'utilisation du chemin d'accès rapide sur les périphériques 4KN n'est pas prise en charge.

                • Si vous disposez d'une machine virtuelle en cours d'exécution avec des disques virtuels d'une capacité supérieure à 1 To et que vous supprimez un snapshot des disques sur cette machine virtuelle, celle-ci peut se bloquer pendant quelques secondes, voire quelques minutes. La machine virtuelle récupère finalement, mais ses charges de travail peuvent subir des interruptions. Ce problème se produit, car l'opération de suppression déclenche la consolidation des snapshots en arrière-plan, ce qui entraîne le retard. Ce problème est plus susceptible de se produire sur un stockage plus lent, tel que NFS.

                • Les paquets DVFilter peuvent être transférés de manière incorrecte vers un port réseau, sur lequel le code d'achèvement de paquets ne parvient pas à s'exécuter. Par conséquent, des hôtes ESXi échouent avec un écran de diagnostic violet et l'erreur PF Exception 14 Vmxnet3VMKDevTxCompleteOne E1000DevTxCompleteOneWork.

                • Dans de rares cas, DFW peut envoyer une liste de paquets à un ensemble de ports incorrect. Par conséquent, le service VMkernel peut échouer et les machines virtuelles perdent la connectivité. Dans le fichier vmkernel.log, vous voyez des messages tels que :
                  2021-09-27T04:29:53.170Z cpu84:xxxx)NetPort: 206: Failure: lockModel[0] vs psWorldState->lockModel[0] there is no portset lock holding.

                • À partir de vSphere 7.0 Update 2, HPP devient le plug-in par défaut pour les périphériques NVMe et SCSI locaux, mais vous pouvez le remplacer par le plug-in ESX NMP (Native Multipathing Plug-in). Cependant, dans certains environnements, le passage de NMP à HPP rend inaccessibles certaines propriétés de périphériques réclamés par HPP, telles que le nom complet.

                • Dans une cible ALUA, si les ID de groupe de ports (TPGID) cibles sont modifiés pour un LUN, la réponse d'identification du périphérique mis en cache que SATP utilise peut ne pas se mettre à jour en conséquence. Par conséquent, ESXi peut ne pas refléter les états de chemin corrects pour le périphérique correspondant.

                • Si vous utilisez la pile de traduction NVMe-SCSI pour enregistrer des périphériques NVMe dans votre système, les propriétés targetPortGroup et relativeTargetPortId obtiennent un ID de contrôleur de 0 pour tous les chemins. Par conséquent, une commande RTPG renvoie le même état d'accès ALUA pour tous les chemins d'accès de l'espace de noms, car chaque chemin d'accès tpgID correspond au premier descripteur, qui est 0.

                • Si le mot de passe de l'administrateur du service de fichiers est modifié sur le serveur Active Directory, le mot de passe dans la configuration du domaine du service de fichiers vSAN peut ne pas correspondre. Si les mots de passe ne correspondent pas ou si le compte est verrouillé, certains partages de fichiers peuvent être inaccessibles. Le service de santé vSAN affiche l'avertissement suivant : Service de fichiers : Serveur de fichiers introuvable.

                • Lorsque vous réinstallez un hôte ESXi après une panne, étant donné que l'instance ayant échoué ne redémarre jamais, les liaisons périmées des disques de machine virtuelle restent intactes sur le fournisseur VASA et les banques de données vSphere Virtual Volumes. Par conséquent, lorsque vous réinstallez l'hôte, vous ne pouvez pas supprimer les disques de machine virtuelle en raison de la liaison existante. Au fil du temps, de nombreux disques de machine virtuelle peuvent s'accumuler et consommer de l'espace de stockage inactif.

                • Dans de rares cas, un périphérique série sur une machine virtuelle peut ne pas avoir une propriété serial<N>.fileName et la propriété serial<N>.autodetect définie sur FALSE. Par conséquent, le service hostd peut échouer à plusieurs reprises.

                • Dans vSphere Client, si vous définissez l'une des options de paramétrage du trafic, comme Bande passante moyenne, Bande passante maximale ou Ampleur du pic, sur une valeur supérieure à 2 147 483 Kbits/s, les paramètres ne sont pas conservés.

                • En raison du nombre faible de descripteurs de fichiers par défaut, certaines fonctionnalités telles que vSphere vMotion peuvent échouer dans VAAI pour les environnements NAS après la mise à niveau vers ESXi 7.x, en raison du nombre insuffisant de fichiers de disques de machine virtuelle pouvant être utilisés simultanément. Vous voyez des erreurs telles que Too many open files dans les journaux du démon vaai-nas dans le fichier syslog.log.

                • Dans de rares cas, si une demande d'E/S s'exécute en parallèle avec une opération de suppression du mappage déclenchée par le SE invité sur une machine virtuelle à provisionnement dynamique, un blocage peut se produire dans un volume VMFS6. Par conséquent, les machines virtuelles sur ce volume cessent de répondre.

                • Pendant les opérations de vSphere Storage vMotion ou d'ajout à chaud sur une machine virtuelle disposant de plus de 300 Go de mémoire, le délai de basculement peut approcher de 2 minutes, ce qui entraîne un échec du délai d'expiration.

                • Si vous ne supprimez pas la liaison de port après avoir supprimé une carte réseau VMkernel liée à un adaptateur iSCSI, la liaison de port périmée peut entraîner des problèmes après un redémarrage de l'hôte ESXi. Lors du démarrage, la liaison de la carte réseau VMkernel non existante à l'adaptateur iSCSI échoue et les configurations iSCSI ne peuvent pas être restaurées pendant le démarrage. Par conséquent, une fois le redémarrage terminé, il se peut que vous ne voyiez pas certains LUN ou certaines banques de données.

                • Après un basculement de stockage, le client ESXi NFSv4.1 peut identifier par erreur le serveur NFS comme une entité différente et ignorer la récupération. Par conséquent, la banque de données NFSv4.1 reste à l'état Inaccessible.

                • Dans certains cas, comme la température dépassant le seuil, un périphérique NVMe peut signaler un avertissement critique et le contrôleur ESXi NVMe n'enregistre pas le périphérique et le met hors ligne.

                • Un problème rare lorsque le cache de blocs utilisé dépasse le cache réservé peut entraîner des problèmes de réservation dans le service de fichiers vSAN. Par conséquent, vous ne pouvez pas accéder à certains partages de fichiers, et le contrôle de santé affiche l'erreur VDFS daemon is not running. Dans les journaux vdfsd-server, vous voyez des erreurs telles que :
                  PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:621
                  PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:626

                • Dans de rares cas, les requêtes de recherche en arrière-plan exécutées par le système vCenter Server sur un hôte ESXi ayant accès aux fichiers de disques de machine virtuelle des machines virtuelles exportées au format OVF peuvent accidentellement modifier les fichiers. Par conséquent, vous ne pouvez pas importer les machines virtuelles.

                • En raison d'un problème de chargement de composant, l'ajout d'une règle de réclamation PSA de gestion multivoie à l'ensemble de règles de réclamation sur un système vCenter Server à l'aide de l'outil de démarrage rapide peut échouer.

                • Après un arrêt ou un démarrage contrôlé d'un serveur dans un cluster de serveurs ESXi attachés à une baie ALUA, tous les LUN auxquels ce serveur a accès peuvent s'introduire sur un processeur de stockage sur la baie. Par conséquent, les performances des autres serveurs ESXi accédant aux LUN se dégradent.

                • Dans de rares cas, lorsqu'un hôte ESXi subit une forte sollicitation de la mémoire, PSA ne gère pas correctement les échecs d'allocation de mémoire. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet avec une erreur telle que #PF Exception 14 in world 2098026:SCSI path sc IP / SCSI path scan helpers.

                • Si une machine virtuelle en cours d'exécution redémarre lors d'une opération de suppression de snapshots, les disques de machine virtuelle peuvent être rouverts et fermés de manière incorrecte lors de la consolidation des snapshots. En conséquence, la machine virtuelle peut échouer. Cependant, il s'agit d'un problème de synchronisation qui se produit accidentellement.

                • Lors de la détection de périphériques, un conflit de réservation peut entraîner le signalement erroné d'ATS comme not supported et, pour cette raison, ESXi utilise la réservation SCSI-2 au lieu d'ATS. Par conséquent, le montage de banques de données VMFS6 avec la prise en charge de disques de machine virtuelle en cluster activée peut échouer de manière aléatoire.

                • Certaines opérations peuvent modifier l'UUID de l'hôte. Par exemple, si vous réinstallez le logiciel ESXi ou que vous déplacez l'hôte entre les clusters, l'UUID de l'hôte peut changer. Si l'UUID de l'hôte change pendant la durée d'interruption de service de fichiers vSAN, les serveurs de services de fichiers vSAN ne peuvent pas démarrer.

                • Si vous désactivez le service de fichiers vSAN sans partage de fichiers existant, vSAN supprime le domaine du service de fichiers. Un échec de suppression d'un serveur peut interrompre le processus et laisser certaines métadonnées. Lorsque vous réactivez le service de fichiers, les anciennes métadonnées peuvent empêcher le service de fichiers de fonctionner comme prévu.

                • La commande Report Target Port Groups peut renvoyer une valeur incorrecte dans le champ DURÉE DE TRANSITION IMPLICITE, ce qui affecte la couche de translation SCSI vers NVMe. Dans des cas tels que la migration de plusieurs dispositifs, la durée de transition ALUA est critique pour certains logiciels de gestion multivoie, par exemple PowerPath, pour effectuer des opérations correctes.

                • Les annulations de mappages de petite taille en attente peuvent être bloquées lorsque vous redémarrez un hôte ou que vous remontez un groupe de disques. Les annulations de mappage en attente peuvent entraîner un encombrement des journaux, ce qui entraîne une latence d'E/S.

                • Après la première mise à niveau ou mise à jour de votre système vers ESXi 7.x, avec chaque mise à jour consécutive, également appelée correctif, vous pouvez voir une troncation dans le chemin d'accès au répertoire /productLocker d'une banque de données. Par exemple, si votre premier correctif sur ESXi 7.x est de la version 7.0 Update 2 à la version 7.0 Update 3, le chemin d'accès au répertoire /productLocker est semblable à l'origine à /vmfs/volumes/xxx/VMware-Tools/productLocker/. Cependant, pour chaque correctif consécutif, par exemple de la version 7.0 Update 3 à la version 7.0 Update 3c, le chemin devient semblable à /VMware-Tools/productLocker/.

                • Dans un cluster vSAN étendu ou un cluster à deux nœuds, les votes de quorum peuvent ne pas être distribués correctement pour les objets avec un PFTT de 1 et un SFTT de 1 ou plus. Si un site tombe en panne et qu'un hôte ou un disque supplémentaire échoue sur le site actif, l'objet peut perdre le quorum et devenir inaccessible.

                • Une demande de redimensionnement d'objet peut échouer si la nouvelle taille n'est pas alignée sur 512 octets. Ce problème peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet.

                • Dans certains cas, par exemple lorsqu'une machine virtuelle redémarre, une session de protocole SSH en cours d'exécution que l'utilitaire pktcap-uw utilise pour surveiller et valider les configurations de commutateur sur l'hôte ESXi peut se terminer, mais l'utilitaire pktcap-uw peut continuer à essayer de traiter les paquets. Par conséquent, l'utilitaire commence à consommer plus de CPU que d'habitude. Vous pouvez utiliser la commande esxtop -a pour suivre les performances du CPU.

                • Dans l'instance de vCenter Server exécutant la version 7.0 Update 3, un périphérique NVMe certifié peut présenter l'avertissement de contrôle de santé suivant : NVMe device is not VMware certified. L'avertissement de contrôle de santé suivant peut également s'afficher : NVMe device can not be identified.

                • La commande ESXCLI hardware ipmi bmc get ne renvoie pas l'adresse IPv6 d'un contrôleur BMC en raison d'une analyse incorrecte.

                • Si l'hôte témoin n'est pas accessible par les hôtes du cluster, l'assistant d'arrêt du cluster vSAN peut échouer pour un cluster étendu ou des clusters à deux nœuds. Ce problème se produit lorsque le trafic de données vSAN et le trafic témoin utilisent des cartes vmknic différentes. Dans vSphere Client, le message d'erreur suivant s'affiche sur la page Services vSAN : Disconnected host found from orch <adresse IP du témoin>. Si vCenter est hébergé sur le cluster, vSphere Client n'est pas disponible lors de l'arrêt et le message d'erreur est disponible dans l'instance de Host Client dans laquelle la machine virtuelle vCenter réside.

                • Dans vSphere Client, lorsque vous cliquez avec le bouton droit sur une banque de données, vous pouvez voir l'UUID de certaines machines virtuelles dans une banque de données vSphere Virtual Volumes, par exemple naa.xxxx, au lieu de leur nom. Ce problème se produit rarement dans des environnements à grande échelle comportant un grand nombre de conteneurs et de machines virtuelles sur une banque de données vSphere Virtual Volumes. Le problème n'a aucun impact fonctionnel, tel qu'une incidence sur les opérations de machine virtuelle, la sauvegarde ou toute autre valeur que l'affichage de machine virtuelle dans vSphere Client.

                • En raison d'un problème rare avec l'infrastructure ESXi, un fournisseur VASA lent peut entraîner une situation dans laquelle les banques de données vSphere Virtual Volumes sont inaccessibles et l'hôte ESXi cesse de répondre.

                • Dans certains environnements, lorsque vous arrêtez un hôte ESXi, il ne se met pas hors tension et un écran s'affiche avec le message This system has been halted. Il est recommandé d'utiliser le bouton de réinitialisation ou d'alimentation pour redémarrer.

                • Le paramètre LargeBAR qui étend le registre d'adresses de base (BAR) sur un périphérique vmxnet3 prend en charge le relais uniforme (UPT). Toutefois, UPT n'est pas pris en charge sur ESX 7.0 Update 3 et versions ultérieures, et si le pilote vmxnet3 est rétrogradé vers une version antérieure à la version 7.0 et que le paramètre LargeBAR est activé, les machines virtuelles peuvent perdre la connectivité.

                • Si vous supprimez à chaud des disques indépendants non persistants d'une machine virtuelle sur laquelle le paramètre de configuration vmx.reboot.PowerCycle est activé, ESXi stocke un fichier journal redo. Si une telle machine virtuelle est une machine virtuelle proxy de sauvegarde, vous pouvez voir un grand nombre de fichiers journaux redondants pour prendre une quantité importante de stockage.

                • Dans de rares cas, lorsqu'un hôte ESXi tente d'accéder à une entrée sans mise en cache à partir d'un cache de pool de ressources, l'hôte échoue par intermittence avec un écran de diagnostic violet PF Exception 14 et un fichier de vidage de mémoire. Dans le fichier de vidage, vous voyez des erreurs pour les modules J3_DeleteTransaction et J6ProcessReplayTxnList qui indiquent le problème.

                • Un problème rare avec VMFS peut entraîner une contention de verrouillage élevée des threads de service hostd, voire des blocages, pour les appels de système de fichiers de base tels que open, access ou rename. Par conséquent, l'hôte ESXi cesse de répondre.

                • Étant donné que le protocole d'authentification MD5 est obsolète à compter d'ESXi 7.x, si une configuration d'agent SNMP ESXi utilise le protocole d'authentification MD5, les mises à niveau vers ESXi 7.x échouent.

                • Dans ESXi 7.x, le paramètre Syslog.global.logHost, qui définit une liste délimitée par des virgules d'hôtes distants et de spécifications pour les transmissions de messages, ne tolère pas d'espaces après la virgule. Les versions d'ESXi antérieures à 7.x tolèrent un espace après la virgule dans le paramètre Syslog.global.logHost. Par conséquent, les mises à niveau vers ESXi 7.x peuvent échouer.

                • Un problème lié à l'utilisation de la structure de données probabiliste du filtre de Bloom qui vise à optimiser les E/S de lecture pour les machines virtuelles s'exécutant sur un snapshot peut entraîner une erreur d'E/S basée sur la cohérence logique lorsque la machine virtuelle est en cours d'exécution sur un snapshot. Le problème est limité et se produit uniquement si vous exécutez SQL Server sur un snapshot.

                • Un problème lié au processus d'analyse des banques de données pour aider les allocations de blocs de fichiers pour les fichiers légers peut entraîner un verrouillage de CPU dans certains cas. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet avec une erreur semblable à PSOD - @BlueScreen: NMI.

                • Les fichiers journaux du service hostd peuvent obtenir un nombre anormalement élevé de messages Task Created et Task Completed pour des tâches invisibles, ce qui peut à son tour réduire la durée de conservation des journaux. 

                • Si une commande SCSI sur un point de terminaison de protocole d'une banque de données vSphere Virtual Volumes échoue, le point de terminaison peut obtenir un état Non pris en charge, qui peut être mis en cache. Par conséquent, les commandes SCSI suivantes sur ce point de terminaison de protocole échouent avec un code d'erreur tel que 0x5 0x20, et les opérations de lecture et d'écriture sur une banque de données vSphere Virtual Volumes échouent.

                • Dans certains cas, comme une erreur de port hors service, les hôtes ESXi peuvent perdre la connectivité au contrôleur NVMe bien que certaines files d'attente d'E/S soient toujours actives.

                • Si vous répliquez une machine virtuelle à l'aide de vSphere Replication et que le nombre de disques de la machine virtuelle augmente à un nombre qui n'est pas aligné sur 512, la machine virtuelle ne peut pas être mise sous tension.

                • Si le nombre de CPU que vous définissez avec le paramètre ConfigSpec#numCPU n'est pas un multiple du nombre de cœurs par socket que vous définissez avec le paramètre ConfigSpec#numCoresPerSocket dans la configuration d'une machine virtuelle, la machine virtuelle ne se met pas sous tension.

                • Ce problème affecte les hôtes des clusters étendus avec les paramètres de stratégie locality=Aucun, HFT=0, SFT=1 ou SFT=2. Lorsque vous placez un hôte en mode de maintenance avec Assurer l'accessibilité, l'opération peut rester à 100 % pendant un long moment ou échouer après 60 minutes.

                • Après la mise à niveau d'un hôte ESXi vers la version 7.0 Update 2, vous pouvez remarquer de fréquentes alarmes de latence réseau vSAN sur le cluster lorsque le service de performances vSAN est activé. Les résultats de latence indiquent que la plupart des alarmes sont émises par le nœud vSAN principal.

                • En raison d'une modification de la taille de la file d'attente d'administration par défaut pour les contrôleurs NVMe over RDMA dans ESXi 7.0 Update 3c, les mises à jour d'ESXi 7.0, 7.0 Update 1 ou 7.0 Update 2 vers la version 7.0 Update 3c peuvent rendre le stockage NVMe over RDMA inaccessible.

                • En raison d'une condition de concurrence rare, lorsqu'un port de conteneur tente de réacquérir un verrouillage qu'il détient déjà, un hôte ESXi peut échouer avec un écran de diagnostic violet lorsque des machines virtuelles avec des ports de conteneur sont mises hors tension ou migrées à l'aide de vSphere vMotion. Ce problème se produit en raison d'une duplication des ID de port.

                • des hôtes ESXi peuvent perdre l'accès aux baies de stockage Unity après la mise à niveau du pilote lpfc vers la version 14.0.x.x. Vous voyez des erreurs telles que protocol failure detected during processing of FCP I/O et rspInfo3 x2 dans les journaux du pilote.

                • Pour les pilotes liés à LSI, lorsqu'un serveur ESXi démarre, si vous débranchez un disque et le branchez dans un autre emplacement sur le même hôte, les modifications de l'emplacement du disque peuvent prendre un certain temps à s'afficher à partir de vSphere Client ou à l'aide de la commande ESXCLI esxcli storage core device physical get -d. Le problème est spécifique aux pilotes avec de nombreux disques connectés au pilote, 150 et plus, et il est résolu dans les 5 minutes qui suivent.

                • Avec ESXi 7.0 Update 3f, le pilote Intel-icen prend en charge les fonctions de mise en réseau sur les cartes réseau E822/E823 pour les plates-formes Intel Icelake-D. Les fonctions ENS (Enhanced Network Stack) et RDMA sur ces périphériques ne sont pas prises en charge.

                • ESXi 7.0 Update 3f met à niveau le pilote Intel-ne1000 pour prendre en charge les périphériques Intel I219-LM requis pour les modèles de serveur plus récents, tels que la plate-forme Intel Lake-S. Le déchargement de segmentation TCP pour les périphériques I219 est désactivé en raison de problèmes connus dans le DMA matériel.

                • Un problème d'erreur de pointeur null très rare peut entraîner l'échec des hôtes ESXi sur les baies IBM FlashSystem V9000 avec un écran de diagnostic violet et une erreur telle que #PF Exception 14 in world 2098414:CqWorld IP 0xxxxx addr 0xxxx.

                • Lorsque vous désactivez ou interrompez vSphere FT, les machines virtuelles peuvent perdre temporairement la connectivité et ne pas répondre aux commandes ping ou à tout trafic réseau. L'envoi d'une commande ping aux machines virtuelles peut expirer successivement sur une courte période, par exemple 20 secondes.

                • Dans certaines conditions, telles que l'augmentation du partage de page ou la désactivation de l'utilisation de grandes pages au niveau de la machine virtuelle ou de l'hôte ESXi, vous pouvez constater une utilisation du CPU de machines virtuelles compatibles VBS Windows atteignant 100 %.

              ESXi-7.0U3f-20036589-no-tools
              Nom du profil ESXi-7.0U3f-20036589-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 12 juillet 2022
              Niveau d'acceptation PartnerSupported
              Matériel concerné S.O.
              Logiciels concernés S.O.
              VIB concernés
              • VMware_bootbank_esxio-combiner_7.0.3-0.50.20036589
              • VMware_bootbank_esx-ui_1.43.8-19798623
              • VMware_bootbank_esx-xserver_7.0.3-0.50.20036589
              • VMware_bootbank_cpu-microcode_7.0.3-0.50.20036589
              • VMware_bootbank_trx_7.0.3-0.50.20036589
              • VMware_bootbank_vsanhealth_7.0.3-0.50.20036589
              • VMware_bootbank_esx-base_7.0.3-0.50.20036589
              • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.50.20036589
              • VMware_bootbank_gc_7.0.3-0.50.20036589
              • VMware_bootbank_native-misc-drivers_7.0.3-0.50.20036589
              • VMware_bootbank_bmcal_7.0.3-0.50.20036589
              • VMware_bootbank_vsan_7.0.3-0.50.20036589
              • VMware_bootbank_vdfs_7.0.3-0.50.20036589
              • VMware_bootbank_crx_7.0.3-0.50.20036589
              • VMware_bootbank_esx-update_7.0.3-0.50.20036589
              • VMware_bootbank_loadesx_7.0.3-0.50.20036589
              • VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.50.20036589
              • VMW_bootbank_bnxtnet_216.0.50.0-44vmw.703.0.50.20036589
              • VMW_bootbank_lpfc_14.0.169.26-5vmw.703.0.50.20036589
              • VMware_bootbank_lsuv2-lsiv2-drivers-plugin_1.0.0-12vmw.703.0.50.20036589
              • VMW_bootbank_icen_1.4.1.20-1vmw.703.0.50.20036589
              • VMW_bootbank_irdman_1.3.1.22-1vmw.703.0.50.20036589
              • VMW_bootbank_ne1000_0.9.0-1vmw.703.0.50.20036589
              • VMW_bootbank_iser_1.1.0.1-1vmw.703.0.50.20036589
              • VMW_bootbank_vmkusb_0.1-7vmw.703.0.50.20036589
              • VMware_locker_tools-light_12.0.0.19345655-20036586
              PR résolus 2916848, 2817702, 2937074, 2957732, 2984134, 2944807, 2985369, 2907963, 2949801, 2984245, 2915911, 2990593, 2992648, 2905357, 2980176, 2974472, 2974376, 2972059, 2973031, 2967359, 2860126, 2878245, 2876044, 2968157, 2960242, 2970238, 2966270, 2966783, 2963328, 2939395, 2966362, 2946550, 2958543, 2966628, 2961584, 2911056, 2965235, 2952427, 2963401, 2965146, 2963038, 2963479, 2949375, 2961033, 2958926, 2839515, 2951139, 2878224, 2954320, 2952432, 2961346, 2857932, 2960949, 2960882, 2957966, 2929443, 2956080, 2959293, 2944919, 2948800, 2928789, 2957769, 2928268, 2957062, 2792139, 2934102, 2953709, 2950686, 2953488, 2949446, 2955016, 2953217, 2956030, 2949902, 2944894, 2944521, 2911363, 2952205, 2894093, 2910856, 2953754, 2949777, 2925733, 2951234, 2915979, 2904241, 2935355, 2941263, 2912661, 2891231, 2928202, 2928268, 2867146, 2244126, 2912330, 2898858, 2906297, 2912213, 2910340, 2745800, 2912182, 2941274, 2912230, 2699748, 2882789, 2869031, 2913017, 2864375, 2929821, 2957673, 2921564, 2925133 et 2965277
              Numéros CVE associés S/O
              • Ce correctif met à jour les problèmes suivants :

                • Les appels pyVmomi à vSphere API EnvironmentBrowser.QueryConfigTargetEx peuvent échouer avec le message UnknownWsdlTypeError.

                • Le module de santé du matériel d'ESXi peut ne pas parvenir à décoder certains capteurs de type Événement système lorsque le nom d'un serveur physique est modifié. Par conséquent, dans vSphere Client, vous voyez l'état Inconnu pour les capteurs de type Événement système sous Surveiller > Santé du matériel.

                • Si vous définissez le paramètre avancé vmx.reboot.powerCycle sur une machine virtuelle sur TRUE, lorsque le SE invité initie un redémarrage, la machine virtuelle se met hors tension, puis se met sous tension. Cependant, si un cycle d'alimentation se produit pendant une migration à l'aide de vSphere vMotion, l'opération échoue et la machine virtuelle sur l'hôte source peut ne pas se mettre sous tension.

                • Si un socket rencontre un échec de connexion alors qu'il est interrogé lors de la communication interne entre des sockets de domaine UNIX, une concurrence de données peut se produire. Par conséquent, dans certains cas, l'hôte ESXi peut accéder à une région de mémoire non valide et échouer avec un écran de diagnostic violet avec le message #PF Exception 14 et des erreurs semblables à UserDuct_PollSize() et UserSocketLocalPoll().

                • Si un adaptateur iSCSI matériel sur un hôte ESXi de votre environnement utilise des pseudo cartes réseau, il se peut que vous ne puissiez pas créer un profil d'hôte à partir d'un tel hôte, car les pseudo cartes réseau ne disposent pas de l'adresse PCI et du nom de fournisseur requis pour un profil.

                • Les conditions de concurrence dans le pilote iscsi_vmk peuvent entraîner des opérations d'E/S bloquées ou des délais d'expiration de pulsation sur une banque de données VMFS. Par conséquent, certaines machines virtuelles peuvent cesser de répondre.

                • Le débit avec les adaptateurs iSCSI logiciels est limité en raison des tailles de tampon d'envoi et de réception codées en dur, respectivement 600 Ko pour le tampon d'envoi et 256 Ko pour le tampon de réception. Par conséquent, les performances de l'adaptateur iscsi_vmk ne sont pas optimales.

                • Lorsque plusieurs machines virtuelles NVIDIA vGPU se mettent hors tension simultanément, il arrive parfois que certaines ressources GPU à plusieurs instances (MIG) ne soient pas détruites. Par conséquent, la mise sous tension ultérieure de la VM vGPU peut échouer en raison des ressources MIG résiduelles.

                • Dans de rares cas, lorsqu'un serveur NFSv4.1 renvoie une erreur temporaire lors du basculement du stockage, les machines virtuelles peuvent cesser de répondre pendant 10 secondes avant le redémarrage de l'opération.

                • En de rares occasions, l'achèvement de paquets peut ne pas se produire sur le port ou l'ensemble de ports d'origine, mais sur un ensemble de ports différent, ce qui entraîne une boucle susceptible d'endommager la liste de paquets avec un pointeur non valide. Par conséquent, un hôte ESXi peut échouer avec un écran de diagnostic violet. Dans les journaux, vous voyez une erreur telle que PF Exception 14 in world 61176327:nsx.cp.tx IP 0xxxxxx addr 0x3c.

                • La mémoire d'un nœud NUMA d'hôte ESXi peut être composée de plusieurs plages physiques. Dans les versions d'ESXi antérieures à la version 7.0 Update 3f, les champs memoryRangeBegin et memoryRangeLength dans NumaNodeInfo donnent l'adresse physique de début d'hôte et la longueur d'une plage dans le nœud NUMA, en ignorant les plages supplémentaires.

                • Si vous activez le chemin d'accès rapide sur HPP pour les périphériques logiciels 4KN 512e, il ne fonctionne pas comme prévu, car le chemin d'accès rapide ne gère pas Read-Modify-Write (R-M-W), qui doit utiliser un chemin lent. L'utilisation du chemin d'accès rapide sur les périphériques 4KN n'est pas prise en charge.

                • Si vous disposez d'une machine virtuelle en cours d'exécution avec des disques virtuels d'une capacité supérieure à 1 To et que vous supprimez un snapshot des disques sur cette machine virtuelle, celle-ci peut se bloquer pendant quelques secondes, voire quelques minutes. La machine virtuelle récupère finalement, mais ses charges de travail peuvent subir des interruptions. Ce problème se produit, car l'opération de suppression déclenche la consolidation des snapshots en arrière-plan, ce qui entraîne le retard. Ce problème est plus susceptible de se produire sur un stockage plus lent, tel que NFS.

                • Les paquets DVFilter peuvent être transférés de manière incorrecte vers un port réseau, sur lequel le code d'achèvement de paquets ne parvient pas à s'exécuter. Par conséquent, des hôtes ESXi échouent avec un écran de diagnostic violet et l'erreur PF Exception 14 Vmxnet3VMKDevTxCompleteOne E1000DevTxCompleteOneWork.

                • Dans de rares cas, DFW peut envoyer une liste de paquets à un ensemble de ports incorrect. Par conséquent, le service VMkernel peut échouer et les machines virtuelles perdent la connectivité. Dans le fichier vmkernel.log, vous voyez des messages tels que :
                  2021-09-27T04:29:53.170Z cpu84:xxxx)NetPort: 206: Failure: lockModel[0] vs psWorldState->lockModel[0] there is no portset lock holding.

                • À partir de vSphere 7.0 Update 2, HPP devient le plug-in par défaut pour les périphériques NVMe et SCSI locaux, mais vous pouvez le remplacer par le plug-in ESX NMP (Native Multipathing Plug-in). Cependant, dans certains environnements, le passage de NMP à HPP rend inaccessibles certaines propriétés de périphériques réclamés par HPP, telles que le nom complet.

                • Dans une cible ALUA, si les ID de groupe de ports (TPGID) cibles sont modifiés pour un LUN, la réponse d'identification du périphérique mis en cache que SATP utilise peut ne pas se mettre à jour en conséquence. Par conséquent, ESXi peut ne pas refléter les états de chemin corrects pour le périphérique correspondant.

                • Si vous utilisez la pile de traduction NVMe-SCSI pour enregistrer des périphériques NVMe dans votre système, les propriétés targetPortGroup et relativeTargetPortId obtiennent un ID de contrôleur de 0 pour tous les chemins. Par conséquent, une commande RTPG renvoie le même état d'accès ALUA pour tous les chemins d'accès de l'espace de noms, car chaque chemin d'accès tpgID correspond au premier descripteur, qui est 0.

                • Si le mot de passe de l'administrateur du service de fichiers est modifié sur le serveur Active Directory, le mot de passe dans la configuration du domaine du service de fichiers vSAN peut ne pas correspondre. Si les mots de passe ne correspondent pas ou si le compte est verrouillé, certains partages de fichiers peuvent être inaccessibles. Le service de santé vSAN affiche l'avertissement suivant : Service de fichiers : Serveur de fichiers introuvable.

                • Lorsque vous réinstallez un hôte ESXi après une panne, étant donné que l'instance ayant échoué ne redémarre jamais, les liaisons périmées des disques de machine virtuelle restent intactes sur le fournisseur VASA et les banques de données vSphere Virtual Volumes. Par conséquent, lorsque vous réinstallez l'hôte, vous ne pouvez pas supprimer les disques de machine virtuelle en raison de la liaison existante. Au fil du temps, de nombreux disques de machine virtuelle peuvent s'accumuler et consommer de l'espace de stockage inactif.

                • Dans de rares cas, un périphérique série sur une machine virtuelle peut ne pas avoir une propriété serial<N>.fileName et la propriété serial<N>.autodetect définie sur FALSE. Par conséquent, le service hostd peut échouer à plusieurs reprises.

                • Dans vSphere Client, si vous définissez l'une des options de paramétrage du trafic, comme Bande passante moyenne, Bande passante maximale ou Ampleur du pic, sur une valeur supérieure à 2 147 483 Kbits/s, les paramètres ne sont pas conservés.

                • En raison du nombre faible de descripteurs de fichiers par défaut, certaines fonctionnalités telles que vSphere vMotion peuvent échouer dans VAAI pour les environnements NAS après la mise à niveau vers ESXi 7.x, en raison du nombre insuffisant de fichiers de disques de machine virtuelle pouvant être utilisés simultanément. Vous voyez des erreurs telles que Too many open files dans les journaux du démon vaai-nas dans le fichier syslog.log.

                • Dans de rares cas, si une demande d'E/S s'exécute en parallèle avec une opération de suppression du mappage déclenchée par le SE invité sur une machine virtuelle à provisionnement dynamique, un blocage peut se produire dans un volume VMFS6. Par conséquent, les machines virtuelles sur ce volume cessent de répondre.

                • Pendant les opérations de vSphere Storage vMotion ou d'ajout à chaud sur une machine virtuelle disposant de plus de 300 Go de mémoire, le délai de basculement peut approcher de 2 minutes, ce qui entraîne un échec du délai d'expiration.

                • Si vous ne supprimez pas la liaison de port après avoir supprimé une carte réseau VMkernel liée à un adaptateur iSCSI, la liaison de port périmée peut entraîner des problèmes après un redémarrage de l'hôte ESXi. Lors du démarrage, la liaison de la carte réseau VMkernel non existante à l'adaptateur iSCSI échoue et les configurations iSCSI ne peuvent pas être restaurées pendant le démarrage. Par conséquent, une fois le redémarrage terminé, il se peut que vous ne voyiez pas certains LUN ou certaines banques de données.

                • Après un basculement de stockage, le client ESXi NFSv4.1 peut identifier par erreur le serveur NFS comme une entité différente et ignorer la récupération. Par conséquent, la banque de données NFSv4.1 reste à l'état Inaccessible.

                • Dans certains cas, comme la température dépassant le seuil, un périphérique NVMe peut signaler un avertissement critique et le contrôleur ESXi NVMe n'enregistre pas le périphérique et le met hors ligne.

                • Un problème rare lorsque le cache de blocs utilisé dépasse le cache réservé peut entraîner des problèmes de réservation dans le service de fichiers vSAN. Par conséquent, vous ne pouvez pas accéder à certains partages de fichiers, et le contrôle de santé affiche l'erreur VDFS daemon is not running. Dans les journaux vdfsd-server, vous voyez des erreurs telles que :
                  PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:621
                  PANIC: NOT_IMPLEMENTED bora/vdfs/core/VDFSPhysicalLog.cpp:626

                • Dans de rares cas, les requêtes de recherche en arrière-plan exécutées par le système vCenter Server sur un hôte ESXi ayant accès aux fichiers de disques de machine virtuelle des machines virtuelles exportées au format OVF peuvent accidentellement modifier les fichiers. Par conséquent, vous ne pouvez pas importer les machines virtuelles.

                • En raison d'un problème de chargement de composant, l'ajout d'une règle de réclamation PSA de gestion multivoie à l'ensemble de règles de réclamation sur un système vCenter Server à l'aide de l'outil de démarrage rapide peut échouer.

                • Après un arrêt ou un démarrage contrôlé d'un serveur dans un cluster de serveurs ESXi attachés à une baie ALUA, tous les LUN auxquels ce serveur a accès peuvent s'introduire sur un processeur de stockage sur la baie. Par conséquent, les performances des autres serveurs ESXi accédant aux LUN se dégradent.

                • Dans de rares cas, lorsqu'un hôte ESXi subit une forte sollicitation de la mémoire, PSA ne gère pas correctement les échecs d'allocation de mémoire. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet avec une erreur telle que #PF Exception 14 in world 2098026:SCSI path sc IP / SCSI path scan helpers.

                • Si une machine virtuelle en cours d'exécution redémarre lors d'une opération de suppression de snapshots, les disques de machine virtuelle peuvent être rouverts et fermés de manière incorrecte lors de la consolidation des snapshots. En conséquence, la machine virtuelle peut échouer. Cependant, il s'agit d'un problème de synchronisation qui se produit accidentellement.

                • Lors de la détection de périphériques, un conflit de réservation peut entraîner le signalement erroné d'ATS comme not supported et, pour cette raison, ESXi utilise la réservation SCSI-2 au lieu d'ATS. Par conséquent, le montage de banques de données VMFS6 avec la prise en charge de disques de machine virtuelle en cluster activée peut échouer de manière aléatoire.

                • Certaines opérations peuvent modifier l'UUID de l'hôte. Par exemple, si vous réinstallez le logiciel ESXi ou que vous déplacez l'hôte entre les clusters, l'UUID de l'hôte peut changer. Si l'UUID de l'hôte change pendant la durée d'interruption de service de fichiers vSAN, les serveurs de services de fichiers vSAN ne peuvent pas démarrer.

                • Si vous désactivez le service de fichiers vSAN sans partage de fichiers existant, vSAN supprime le domaine du service de fichiers. Un échec de suppression d'un serveur peut interrompre le processus et laisser certaines métadonnées. Lorsque vous réactivez le service de fichiers, les anciennes métadonnées peuvent empêcher le service de fichiers de fonctionner comme prévu.

                • La commande Report Target Port Groups peut renvoyer une valeur incorrecte dans le champ DURÉE DE TRANSITION IMPLICITE, ce qui affecte la couche de translation SCSI vers NVMe. Dans des cas tels que la migration de plusieurs dispositifs, la durée de transition ALUA est critique pour certains logiciels de gestion multivoie, par exemple PowerPath, pour effectuer des opérations correctes.

                • Les annulations de mappages de petite taille en attente peuvent être bloquées lorsque vous redémarrez un hôte ou que vous remontez un groupe de disques. Les annulations de mappage en attente peuvent entraîner un encombrement des journaux, ce qui entraîne une latence d'E/S.

                • Après la première mise à niveau ou mise à jour de votre système vers ESXi 7.x, avec chaque mise à jour consécutive, également appelée correctif, vous pouvez voir une troncation dans le chemin d'accès au répertoire /productLocker d'une banque de données. Par exemple, si votre premier correctif sur ESXi 7.x est de la version 7.0 Update 2 à la version 7.0 Update 3, le chemin d'accès au répertoire /productLocker est semblable à l'origine à /vmfs/volumes/xxx/VMware-Tools/productLocker/. Cependant, pour chaque correctif consécutif, par exemple de la version 7.0 Update 3 à la version 7.0 Update 3c, le chemin devient semblable à /VMware-Tools/productLocker/.

                • Dans un cluster vSAN étendu ou un cluster à deux nœuds, les votes de quorum peuvent ne pas être distribués correctement pour les objets avec un PFTT de 1 et un SFTT de 1 ou plus. Si un site tombe en panne et qu'un hôte ou un disque supplémentaire échoue sur le site actif, l'objet peut perdre le quorum et devenir inaccessible.

                • Une demande de redimensionnement d'objet peut échouer si la nouvelle taille n'est pas alignée sur 512 octets. Ce problème peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet.

                • Dans certains cas, par exemple lorsqu'une machine virtuelle redémarre, une session de protocole SSH en cours d'exécution que l'utilitaire pktcap-uw utilise pour surveiller et valider les configurations de commutateur sur l'hôte ESXi peut se terminer, mais l'utilitaire pktcap-uw peut continuer à essayer de traiter les paquets. Par conséquent, l'utilitaire commence à consommer plus de CPU que d'habitude. Vous pouvez utiliser la commande esxtop -a pour suivre les performances du CPU.

                • Dans l'instance de vCenter Server exécutant la version 7.0 Update 3, un périphérique NVMe certifié peut présenter l'avertissement de contrôle de santé suivant : NVMe device is not VMware certified. L'avertissement de contrôle de santé suivant peut également s'afficher : NVMe device can not be identified.

                • La commande ESXCLI hardware ipmi bmc get ne renvoie pas l'adresse IPv6 d'un contrôleur BMC en raison d'une analyse incorrecte.

                • Si l'hôte témoin n'est pas accessible par les hôtes du cluster, l'assistant d'arrêt du cluster vSAN peut échouer pour un cluster étendu ou des clusters à deux nœuds. Ce problème se produit lorsque le trafic de données vSAN et le trafic témoin utilisent des cartes vmknic différentes. Dans vSphere Client, le message d'erreur suivant s'affiche sur la page Services vSAN : Disconnected host found from orch <adresse IP du témoin>. Si vCenter est hébergé sur le cluster, vSphere Client n'est pas disponible lors de l'arrêt et le message d'erreur est disponible dans l'instance de Host Client dans laquelle la machine virtuelle vCenter réside.

                • Dans vSphere Client, lorsque vous cliquez avec le bouton droit sur une banque de données, vous pouvez voir l'UUID de certaines machines virtuelles dans une banque de données vSphere Virtual Volumes, par exemple naa.xxxx, au lieu de leur nom. Ce problème se produit rarement dans des environnements à grande échelle comportant un grand nombre de conteneurs et de machines virtuelles sur une banque de données vSphere Virtual Volumes. Le problème n'a aucun impact fonctionnel, tel qu'une incidence sur les opérations de machine virtuelle, la sauvegarde ou toute autre valeur que l'affichage de machine virtuelle dans vSphere Client.

                • En raison d'un problème rare avec l'infrastructure ESXi, un fournisseur VASA lent peut entraîner une situation dans laquelle les banques de données vSphere Virtual Volumes sont inaccessibles et l'hôte ESXi cesse de répondre.

                • Dans certains environnements, lorsque vous arrêtez un hôte ESXi, il ne se met pas hors tension et un écran s'affiche avec le message This system has been halted. Il est recommandé d'utiliser le bouton de réinitialisation ou d'alimentation pour redémarrer.

                • Le paramètre LargeBAR qui étend le registre d'adresses de base (BAR) sur un périphérique vmxnet3 prend en charge le relais uniforme (UPT). Toutefois, UPT n'est pas pris en charge sur ESX 7.0 Update 3 et versions ultérieures, et si le pilote vmxnet3 est rétrogradé vers une version antérieure à la version 7.0 et que le paramètre LargeBAR est activé, les machines virtuelles peuvent perdre la connectivité.

                • Si vous supprimez à chaud des disques indépendants non persistants d'une machine virtuelle sur laquelle le paramètre de configuration vmx.reboot.PowerCycle est activé, ESXi stocke un fichier journal redo. Si une telle machine virtuelle est une machine virtuelle proxy de sauvegarde, vous pouvez voir un grand nombre de fichiers journaux redondants pour prendre une quantité importante de stockage.

                • Dans de rares cas, lorsqu'un hôte ESXi tente d'accéder à une entrée sans mise en cache à partir d'un cache de pool de ressources, l'hôte échoue par intermittence avec un écran de diagnostic violet PF Exception 14 et un fichier de vidage de mémoire. Dans le fichier de vidage, vous voyez des erreurs pour les modules J3_DeleteTransaction et J6ProcessReplayTxnList qui indiquent le problème.

                • Un problème rare avec VMFS peut entraîner une contention de verrouillage élevée des threads de service hostd, voire des blocages, pour les appels de système de fichiers de base tels que open, access ou rename. Par conséquent, l'hôte ESXi cesse de répondre.

                • Étant donné que le protocole d'authentification MD5 est obsolète à compter d'ESXi 7.x, si une configuration d'agent SNMP ESXi utilise le protocole d'authentification MD5, les mises à niveau vers ESXi 7.x échouent.

                • Dans ESXi 7.x, le paramètre Syslog.global.logHost, qui définit une liste délimitée par des virgules d'hôtes distants et de spécifications pour les transmissions de messages, ne tolère pas d'espaces après la virgule. Les versions d'ESXi antérieures à 7.x tolèrent un espace après la virgule dans le paramètre Syslog.global.logHost. Par conséquent, les mises à niveau vers ESXi 7.x peuvent échouer.

                • Un problème lié à l'utilisation de la structure de données probabiliste du filtre de Bloom qui vise à optimiser les E/S de lecture pour les machines virtuelles s'exécutant sur un snapshot peut entraîner une erreur d'E/S basée sur la cohérence logique lorsque la machine virtuelle est en cours d'exécution sur un snapshot. Le problème est limité et se produit uniquement si vous exécutez SQL Server sur un snapshot.

                • Un problème lié au processus d'analyse des banques de données pour aider les allocations de blocs de fichiers pour les fichiers légers peut entraîner un verrouillage de CPU dans certains cas. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet avec une erreur semblable à PSOD - @BlueScreen: NMI.

                • Les fichiers journaux du service hostd peuvent obtenir un nombre anormalement élevé de messages Task Created et Task Completed pour des tâches invisibles, ce qui peut à son tour réduire la durée de conservation des journaux. 

                • Si une commande SCSI sur un point de terminaison de protocole d'une banque de données vSphere Virtual Volumes échoue, le point de terminaison peut obtenir un état Non pris en charge, qui peut être mis en cache. Par conséquent, les commandes SCSI suivantes sur ce point de terminaison de protocole échouent avec un code d'erreur tel que 0x5 0x20, et les opérations de lecture et d'écriture sur une banque de données vSphere Virtual Volumes échouent.

                • Dans certains cas, comme une erreur de port hors service, les hôtes ESXi peuvent perdre la connectivité au contrôleur NVMe bien que certaines files d'attente d'E/S soient toujours actives.

                • Si vous répliquez une machine virtuelle à l'aide de vSphere Replication et que le nombre de disques de la machine virtuelle augmente à un nombre qui n'est pas aligné sur 512, la machine virtuelle ne peut pas être mise sous tension.

                • Si le nombre de CPU que vous définissez avec le paramètre ConfigSpec#numCPU n'est pas un multiple du nombre de cœurs par socket que vous définissez avec le paramètre ConfigSpec#numCoresPerSocket dans la configuration d'une machine virtuelle, la machine virtuelle ne se met pas sous tension.

                • Ce problème affecte les hôtes des clusters étendus avec les paramètres de stratégie locality=Aucun, HFT=0, SFT=1 ou SFT=2. Lorsque vous placez un hôte en mode de maintenance avec Assurer l'accessibilité, l'opération peut rester à 100 % pendant un long moment ou échouer après 60 minutes.

                • Après la mise à niveau d'un hôte ESXi vers la version 7.0 Update 2, vous pouvez remarquer de fréquentes alarmes de latence réseau vSAN sur le cluster lorsque le service de performances vSAN est activé. Les résultats de latence indiquent que la plupart des alarmes sont émises par le nœud vSAN principal.

                • En raison d'une modification de la taille de la file d'attente d'administration par défaut pour les contrôleurs NVMe over RDMA dans ESXi 7.0 Update 3c, les mises à jour d'ESXi 7.0, 7.0 Update 1 ou 7.0 Update 2 vers la version 7.0 Update 3c peuvent rendre le stockage NVMe over RDMA inaccessible.

                • En raison d'une condition de concurrence rare, lorsqu'un port de conteneur tente de réacquérir un verrouillage qu'il détient déjà, un hôte ESXi peut échouer avec un écran de diagnostic violet lorsque des machines virtuelles avec des ports de conteneur sont mises hors tension ou migrées à l'aide de vSphere vMotion. Ce problème se produit en raison d'une duplication des ID de port.

                • des hôtes ESXi peuvent perdre l'accès aux baies de stockage Unity après la mise à niveau du pilote lpfc vers la version 14.0.x.x. Vous voyez des erreurs telles que protocol failure detected during processing of FCP I/O et rspInfo3 x2 dans les journaux du pilote.

                • Pour les pilotes liés à LSI, lorsqu'un serveur ESXi démarre, si vous débranchez un disque et le branchez dans un autre emplacement sur le même hôte, les modifications de l'emplacement du disque peuvent prendre un certain temps à s'afficher à partir de vSphere Client ou à l'aide de la commande ESXCLI esxcli storage core device physical get -d. Le problème est spécifique aux pilotes avec de nombreux disques connectés au pilote, 150 et plus, et il est résolu dans les 5 minutes qui suivent.

                • Avec ESXi 7.0 Update 3f, le pilote Intel-icen prend en charge les fonctions de mise en réseau sur les cartes réseau E822/E823 pour les plates-formes Intel Icelake-D. Les fonctions ENS (Enhanced Network Stack) et RDMA sur ces périphériques ne sont pas prises en charge.

                • ESXi 7.0 Update 3f met à niveau le pilote Intel-ne1000 pour prendre en charge les périphériques Intel I219-LM requis pour les modèles de serveur plus récents, tels que la plate-forme Intel Lake-S. Le déchargement de segmentation TCP pour les périphériques I219 est désactivé en raison de problèmes connus dans le DMA matériel.

                • Un problème d'erreur de pointeur null très rare peut entraîner l'échec des hôtes ESXi sur les baies IBM FlashSystem V9000 avec un écran de diagnostic violet et une erreur telle que #PF Exception 14 in world 2098414:CqWorld IP 0xxxxx addr 0xxxx.

                • Lorsque vous désactivez ou interrompez vSphere FT, les machines virtuelles peuvent perdre temporairement la connectivité et ne pas répondre aux commandes ping ou à tout trafic réseau. L'envoi d'une commande ping aux machines virtuelles peut expirer successivement sur une courte période, par exemple 20 secondes.

                • Dans certaines conditions, telles que l'augmentation du partage de page ou la désactivation de l'utilisation de grandes pages au niveau de la machine virtuelle ou de l'hôte ESXi, vous pouvez constater une utilisation du CPU de machines virtuelles compatibles VBS Windows atteignant 100 %.

              ESXi-7.0U3sf-20036586-standard
              Nom du profil ESXi-7.0U3sf-20036586-standard
              Build Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.
              Fournisseur VMware, Inc.
              Date de publication 12 juillet 2022
              Niveau d'acceptation PartnerSupported
              Matériel concerné S.O.
              Logiciels concernés S.O.
              VIB concernés
              • VMware_bootbank_native-misc-drivers_7.0.3-0.45.20036586
              • VMware_bootbank_bmcal_7.0.3-0.45.20036586
              • VMware_bootbank_esx-ui_1.43.8-19798623
              • VMware_bootbank_vsanhealth_7.0.3-0.45.20036586
              • VMware_bootbank_esxio-combiner_7.0.3-0.45.20036586
              • VMware_bootbank_esx-xserver_7.0.3-0.45.20036586
              • VMware_bootbank_trx_7.0.3-0.45.20036586
              • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.45.20036586
              • VMware_bootbank_vdfs_7.0.3-0.45.20036586
              • VMware_bootbank_vsan_7.0.3-0.45.20036586
              • VMware_bootbank_cpu-microcode_7.0.3-0.45.20036586
              • VMware_bootbank_esx-base_7.0.3-0.45.20036586
              • VMware_bootbank_gc_7.0.3-0.45.20036586
              • VMware_bootbank_crx_7.0.3-0.45.20036586
              • VMware_bootbank_esx-update_7.0.3-0.45.20036586
              • VMware_bootbank_loadesx_7.0.3-0.45.20036586
              • VMware_locker_tools-light_12.0.0.19345655-20036586
              PR résolus

              2920287, 2946147, 2946217, 2946222, 2946671, 2946863, 2947156, 2951864, 2951866, 2972147, 2972151, 2816546
              Numéros CVE associés

              CVE-2004-0230, CVE-2020-7451, CVE-2015-2923, CVE-2015-5358, CVE-2013-3077, CVE-2015-1414, CVE-2018-6918, CVE-2020-7469, CVE-2019-5611, CVE-2020-7457, CVE-2018-6916, CVE-2019-5608, CVE-2022-23816, CVE-2022-23825, CVE-2022-28693, CVE-2022-29901
              • Ce correctif met à jour les problèmes suivants :
                  • L'analyseur XML Expat a été mis à jour vers la version 2.4.7.
                  • La base de données SQLite a été mise à jour vers la version 3.37.2.
                  • La bibliothèque cURL a été mise à jour vers la version 7.81.0.
                  • Le module OpenSSL a été mis à jour vers la version openssl-1.0.2ze.
                  • La bibliothèque ESXi userworld libxml2 a été mise à jour vers la version 2.9.14.
                  • Le module Python a été mis à jour vers la version 3.8.13.
                  • La bibliothèque zlib a été mise à jour vers la version 1.2.12.
                  • Cette version résout la vulnérabilité critique CVE-2004-0230. VMware a évalué que ce problème se situe dans la plage de gravité faible avec un score de base CVSSv3 maximal de 3,7.
                  • Cette version résout la vulnérabilité critique CVE-2020-7451. VMware a évalué que ce problème se situe dans la plage de gravité moyenne avec un score de base CVSSv3 maximal de 5,3.
                  • Cette version résout la vulnérabilité critique CVE-2015-2923. VMware a évalué que ce problème se situe dans la plage de gravité moyenne avec un score de base CVSSv3 maximal de 6,5.
                  • Cette version résout la vulnérabilité critique CVE-2015-5358. VMware a évalué que ce problème se situe dans la plage de gravité moyenne avec un score de base CVSSv3 maximal de 6,5.
                  • Cette version résout la vulnérabilité critique CVE-2013-3077. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,0.
                  • Cette version résout la vulnérabilité critique CVE-2015-1414. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5.  
                  • Cette version résout la vulnérabilité critique CVE-2018-6918. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5.
                  • Cette version résout la vulnérabilité critique CVE-2020-7469. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5.
                  • Cette version résout la vulnérabilité critique CVE-2019-5611. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5. 
                  • Cette version résout la vulnérabilité critique CVE-2020-7457. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,8. 
                  • Cette version résout la vulnérabilité critique CVE-2018-6916. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 8,1.
                  • Cette version résout la vulnérabilité critique CVE-2019-5608. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 8,1.

                • Cette version résout les vulnérabilités critiques CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 et CVE-2022-29901. Pour plus d'informations sur ces vulnérabilités et leur impact sur les produits VMware, reportez-vous à la page VMSA-2022-0020.

              ESXi-7.0U3sf-20036586-no-tools
              Nom du profil ESXi-7.0U3sf-20036586-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 12 juillet 2022
              Niveau d'acceptation PartnerSupported
              Matériel concerné S.O.
              Logiciels concernés S.O.
              VIB concernés
              • VMware_bootbank_native-misc-drivers_7.0.3-0.45.20036586
              • VMware_bootbank_bmcal_7.0.3-0.45.20036586
              • VMware_bootbank_esx-ui_1.43.8-19798623
              • VMware_bootbank_vsanhealth_7.0.3-0.45.20036586
              • VMware_bootbank_esxio-combiner_7.0.3-0.45.20036586
              • VMware_bootbank_esx-xserver_7.0.3-0.45.20036586
              • VMware_bootbank_trx_7.0.3-0.45.20036586
              • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.45.20036586
              • VMware_bootbank_vdfs_7.0.3-0.45.20036586
              • VMware_bootbank_vsan_7.0.3-0.45.20036586
              • VMware_bootbank_cpu-microcode_7.0.3-0.45.20036586
              • VMware_bootbank_esx-base_7.0.3-0.45.20036586
              • VMware_bootbank_gc_7.0.3-0.45.20036586
              • VMware_bootbank_crx_7.0.3-0.45.20036586
              • VMware_bootbank_esx-update_7.0.3-0.45.20036586
              • VMware_bootbank_loadesx_7.0.3-0.45.20036586
              PR résolus 2920287, 2946147, 2946217, 2946222, 2946671, 2946863, 2947156, 2951864, 2951866, 2972147, 2972151, 2816546
              Numéros CVE associés CVE-2004-0230, CVE-2020-7451, CVE-2015-2923, CVE-2015-5358, CVE-2013-3077, CVE-2015-1414, CVE-2018-6918, CVE-2020-7469, CVE-2019-5611, CVE-2020-7457, CVE-2018-6916, CVE-2019-5608, CVE-2022-23816, CVE-2022-23825, CVE-2022-28693, CVE-2022-29901
              • Ce correctif met à jour les problèmes suivants :
                  • L'analyseur XML Expat a été mis à jour vers la version 2.4.7.
                  • La base de données SQLite a été mise à jour vers la version 3.37.2.
                  • La bibliothèque cURL a été mise à jour vers la version 7.81.0.
                  • Le module OpenSSL a été mis à jour vers la version openssl-1.0.2ze.
                  • La bibliothèque ESXi userworld libxml2 a été mise à jour vers la version 2.9.14.
                  • Le module Python a été mis à jour vers la version 3.8.13.
                  • La bibliothèque zlib a été mise à jour vers la version 1.2.12.
                  • Cette version résout la vulnérabilité critique CVE-2004-0230. VMware a évalué que ce problème se situe dans la plage de gravité faible avec un score de base CVSSv3 maximal de 3,7.
                  • Cette version résout la vulnérabilité critique CVE-2020-7451. VMware a évalué que ce problème se situe dans la plage de gravité moyenne avec un score de base CVSSv3 maximal de 5,3.
                  • Cette version résout la vulnérabilité critique CVE-2015-2923. VMware a évalué que ce problème se situe dans la plage de gravité moyenne avec un score de base CVSSv3 maximal de 6,5.
                  • Cette version résout la vulnérabilité critique CVE-2015-5358. VMware a évalué que ce problème se situe dans la plage de gravité moyenne avec un score de base CVSSv3 maximal de 6,5.
                  • Cette version résout la vulnérabilité critique CVE-2013-3077. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,0.
                  • Cette version résout la vulnérabilité critique CVE-2015-1414. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5.  
                  • Cette version résout la vulnérabilité critique CVE-2018-6918. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5.
                  • Cette version résout la vulnérabilité critique CVE-2020-7469. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5.
                  • Cette version résout la vulnérabilité critique CVE-2019-5611. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,5. 
                  • Cette version résout la vulnérabilité critique CVE-2020-7457. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 7,8. 
                  • Cette version résout la vulnérabilité critique CVE-2018-6916. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 8,1.
                  • Cette version résout la vulnérabilité critique CVE-2019-5608. VMware a évalué que ce problème se situe dans la plage de gravité élevée avec un score de base CVSSv3 maximal de 8,1.

                • Cette version résout les vulnérabilités critiques CVE-2022-23816, CVE-2022-23825, CVE-2022-28693 et CVE-2022-29901. Pour plus d'informations sur ces vulnérabilités et leur impact sur les produits VMware, reportez-vous à la page VMSA-2022-0020.

              ESXi Image - ESXi70U3f-20036589
              Nom ESXi
              Version ESXi70U3f-20036589
              Date de publication 12 juillet 2022
              Catégorie Correctif de bogues
              Composants concernés
              • Composant ESXi - VIB ESXi principaux
              • Composant d'installation/mise à niveau d'ESXi
              • Pilotes Broadcom NetXtreme-E Network et ROCE/RDMA pour VMware ESXi
              • Pilote réseau pour adaptateurs Intel(R) E810
              • Pilote réseau pour adaptateurs RDMA basés sur Intel(R) X722 et E810
              • Pilote VMware iSER natif
              • Pilote lpfc Broadcom Emulex Connectivity Division pour adaptateurs FC
              • Plug-in de gestion de PILOTES LSU NATIFS LSI
              • Pilote de mise en réseau pour adaptateurs de la famille Intel PRO/1000
              • Pilote USB
              PR résolus 

              2916848, 2817702, 2937074, 2957732, 2984134, 2944807, 2985369, 2907963, 2949801, 2984245, 2911320, 2915911, 2990593, 2992648, 2905357, 2980176, 2974472, 2974376, 2972059, 2973031, 2967359, 2860126, 2878245, 2876044, 2968157, 2960242, 2970238, 2966270, 2966783, 2963328, 2939395, 2966362, 2946550, 2958543, 2966628, 2961584, 2911056, 2965235, 2952427, 2963401, 2965146, 2963038, 2963479, 2949375, 2961033, 2958926, 2839515, 2951139, 2878224, 2954320, 2952432, 2961346, 2857932, 2960949, 2960882, 2957966, 2929443, 2956080, 2959293, 2944919, 2948800, 2928789, 2957769, 2928268, 2957062, 2792139, 2934102, 2953709, 2950686, 2953488, 2949446, 2955016, 2953217, 2956030, 2949902, 2944894, 2944521, 2911363, 2952205, 2894093, 2910856, 2953754, 2949777, 2925733, 2951234, 2915979, 2904241, 2935355, 2941263, 2912661, 2891231, 2928202, 2928268, 2867146, 2244126, 2912330, 2898858, 2906297, 2912213, 2910340, 2745800, 2912182, 2941274, 2912230, 2699748, 2882789, 2869031, 2913017, 2864375, 2929821, 2957673, 2921564, 2925133, 2965277 et 2980176
              Numéros CVE associés S/O
                ESXi Image - ESXi70U3sf-20036586
                Nom ESXi
                Version ESXi70U3sf-20036586
                Date de publication 12 juillet 2022
                Catégorie Sécurité
                Composants concernés
                • Composant ESXi - VIB ESXi principaux
                • Composant d'installation/mise à niveau d'ESXi
                • VMware-VM-Tools
                PR résolus  2920287, 2946147, 2946217, 2946222, 2946671, 2946863, 2947156, 2951864, 2951866, 2972147, 2972151
                Numéros CVE associés CVE-2004-0230, CVE-2020-7451, CVE-2015-2923, CVE-2015-5358, CVE-2013-3077, CVE-2015-1414, CVE-2018-6918, CVE-2020-7469, CVE-2019-5611, CVE-2020-7457, CVE-2018-6916, CVE-2019-5608, CVE-2022-23816, CVE-2022-23825, CVE-2022-28693, CVE-2022-29901

                  Problèmes connus

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

                  Problèmes de vSphere Client
                  • Le fabricant du BIOS s'affiche comme « -- » dans vSphere Client

                    Dans vSphere Client, lorsque vous sélectionnez un hôte ESXi et accédez à Configurer > Matériel > Microprogramme, vous voyez -- au lieu du nom du fabricant du BIOS.

                    Solution : Pour plus d'informations, reportez-vous à l'article 88937 de la base de connaissances VMware.

                  Problèmes divers
                  • Le relais de périphérique USB depuis des hôtes ESXi vers des machines virtuelles peut échouer

                    Un périphérique de modem USB peut réclamer simultanément plusieurs interfaces par VMkernel et bloquer le relais de périphérique vers des machines virtuelles.
                    Solution : vous devez appliquer la configuration avancée USB.quirks sur l'hôte ESXi pour ignorer l'interface NET de VMkernel et autoriser le modem USB à passer le relais vers les machines virtuelles. Vous pouvez appliquer la configuration de 3 manières différentes :

                    1. Accédez à ESXi Shell et exécutez la commande suivante : esxcli system settings advanced set -o /USB/quirks -s 0xvvvv:0xpppp:0:0xffff:UQ_NET_IGNORE | |- Device Product ID |------- Device Vendor ID
                      Par exemple, pour Gemalto M2M GmbH Zoom 4625 Modem(vid:pid/1e2d:005b), vous pouvez avoir la commande :
                      esxcli system settings advanced set -o /USB/quirks -s 0x1e2d:0x005b:0:0xffff:UQ_NET_IGNORE
                      Redémarrez l'hôte ESXi.
                    2. Définissez la configuration avancée à partir de vSphere Client ou de vSphere Web Client et redémarrez l'hôte ESXi.
                    3. Utilisez un profil d'hôte pour appliquer la configuration avancée.

                    Pour plus d'informations, reportez-vous à l'article 80416 de la base de connaissances VMware.

                  Problèmes connus depuis les versions précédentes

                  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
                  check-circle-line exclamation-circle-line close-line
                  Scroll to top icon