ESXi 7.0 Update 2c | 24 août 2021 | Build 18426014

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

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

  • ESXi 7.0 Update 2c fournit des correctifs de bogues et de sécurité documentés dans la section Problèmes résolus.

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.

Pour plus d'informations sur les versions d'ESXi qui prennent en charge la mise à niveau vers ESXi 7.0 Update 2c, consultez l'article 67077 de la base de connaissances VMware.

Correctifs contenus dans cette version

La version 7.0 Update 2c d'ESXi fournit les correctifs suivants :

Détails de la build

Nom de fichier de téléchargement : VMware-ESXi-7.0U2c-18426014-depot
Build : 18426014
Taille du téléchargement : 580,8 Mo
md5sum : a6b2d1e3a1a071b8d93a55d7a7fc0b63
sha1checksum : 829da0330f765b4ae46c2fb5b90a8b60f90e4e5b
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.2-0.20.18426014 Correctif de bogues Critique
Pilote Emulex FC Broadcom-ELX-lpfc_12.8.298.3-2vmw.702.0.20.18426014 Correctif de bogues Critique
Pilotes Broadcom NetXtreme-E Network et ROCE/RDMA pour VMware ESXi Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.702.0.20.18426014 Correctif de bogues Important
Pilotes QLogic FastLinQ 10/25/40/50/100 GbE Ethernet et RoCE/RDMA pour VMware ESXi MRVL-E4-CNA-Driver-Bundle_1.0.0.0-1vmw.702.0.20.18426014 Correctif de bogues Important
Composant d'installation/mise à niveau d'ESXi esx-update_7.0.2-0.20.18426014 Correctif de bogues Critique
Pilote réseau pour les adaptateurs Intel(R) X710/XL710/XXV710/X722 Intel-i40en_1.8.1.137-1vmw.702.0.20.18426014 Correctif de bogues Critique
Pilote USB VMware-vmkusb_0.1-4vmw.702.0.20.18426014 Correctif de bogues Critique
Composant ESXi - VIB ESXi principaux ESXi_7.0.2-0.15.18295176 Sécurité Critique
Pilote USB VMware-vmkusb_0.1-1vmw.702.0.15.18295176 Sécurité Modéré
Composant ESXi Tools VMware-VM-Tools_11.2.6.17901274-18295176 Sécurité Critique
Composant d'installation/mise à niveau d'ESXi esx-update_7.0.2-0.15.18295176 Sécurité Critique

IMPORTANT :

  • Pour télécharger le fichier ZIP de dépôt hors ligne du correctif ESXi 7.0 Update 2c à partir de VMware Customer Connect, accédez à Produits et comptes > Correctifs de produit. 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.
  • À 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
ESXi-7.0U2c-18426014 Correctif de bogues Critique Correctif de bogues et sécurité
ESXi-7.0U2sc-18295176 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.0U2c-18426014-standard
ESXi-7.0U2c-18426014-no-tools
ESXi-7.0U2sc-18295176-standard
ESXi-7.0U2sc-18295176-no-tools

Image ESXi

Nom et version Date de publication Catégorie Détail
ESXi70U2c-18426014 24/08/2021 Correctif de bogues Image de correctif de bogues et de sécurité
ESXi70U2sc-18295176 24/08/2021 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.0.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.0.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 sur la page Correctifs de produits, puis utilisez la commande esxcli software profile update.
Pour plus d'informations, consultez Mise à niveau des hôtes à l'aide des commandes ESXCLI et le guide Mise à niveau de VMware ESXi.

Remarques relatives à la prise en charge du produit

  • Arrêt de la prise en charge du module TPM (Trusted Platform Module, module de plate-forme sécurisée) 1.2 dans une future version majeure de vSphere : VMware prévoit dans une future version majeure de vSphere d'interrompre la prise en charge du module TPM 1.2 et des fonctionnalités associées telles que TPM 1.2 avec TXT. Pour utiliser pleinement les fonctionnalités de vSphere, vous pouvez utiliser TPM 2.0 au lieu de TPM 1.2. La prise en charge de TPM 1.2 se poursuit dans toutes les versions, mises à jour et correctifs vSphere 7.0.x. Cependant, vous ne verrez pas d'avertissement indiquant la désapprobation de TPM 1.2 lors de l'installation ou des mises à jour des versions 7.0.x.

  • Le service SLP (Service Location Protocol) est désactivé par défaut : à partir d'ESX 7.0 Update 2c, le service SLP est désactivé par défaut pour éviter d'éventuelles vulnérabilités de sécurité. Le service SLP est également automatiquement désactivé après les mises à niveau vers ESX 7.0 Update 2c. Vous pouvez activer manuellement le service SLP à l'aide de la commande esxcli system slp set --enable true. Pour plus d'informations, reportez-vous à l'article 76372 de la base de connaissances VMware.

Problèmes résolus

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

ESXi_7.0.2-0.20.18426014
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_vsanhealth_7.0.2-0.20.18426014
  • VMware_bootbank_vsan_7.0.2-0.20.18426014
  • VMware_bootbank_gc_7.0.2-0.20.18426014
  • VMware_bootbank_esx-xserver_7.0.2-0.20.18426014
  • VMware_bootbank_clusterstore_7.0.2-0.20.18426014
  • VMware_bootbank_vdfs_7.0.2-0.20.18426014
  • VMware_bootbank_native-misc-drivers_7.0.2-0.20.18426014
  • VMware_bootbank_cpu-microcode_7.0.2-0.20.18426014
  • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.20.18426014
  • VMware_bootbank_esx-base_7.0.2-0.20.18426014
PR résolus 2717698, 2731446, 2515171, 2731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408
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 crx, vsanhealth, vsan, gc, esx-xserver, clusterstore, vdfs, native-misc-drivers, cpu-microcode, esx-dvfilter-generic-fastpath et esx-base pour résoudre les problèmes suivants :

  • PR 2717698 : Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une condition de concurrence rare dans le pilote qedentv

    Une condition de concurrence rare dans le pilote qedentv peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet. Ce problème survient lorsqu'une interruption complète de Rx se produit juste après la destruction d'une paire de files d'attente (QP) de l'interface des services généraux (GSI), par exemple lors du déchargement d'un pilote qedentv ou de l'arrêt d'un système. Dans ce cas, le pilote qedentv peut accéder à une adresse de QP déjà libérée, ce qui entraîne une exception PF. Ce problème peut se produire sur les hôtes ESXi connectés à un commutateur physique occupé avec un trafic GSI non sollicité intense. Dans la trace de débogage, vous voyez des messages tels que :

    cpu4:2107287)0x45389609bcb0:[0x42001d3e6f72]qedrntv_ll2_rx_cb@(qedrntv)#<None>+0x1be stack: 0x45b8f00a7740, 0x1e146d040, 0x432d65738d40, 0x0, 0x
    2021-02-11T03:31:53.882Z cpu4:2107287)0x45389609bd50:[0x42001d421d2a]ecore_ll2_rxq_completion@(qedrntv)#<None>+0x2ab stack: 0x432bc20020ed, 0x4c1e74ef0, 0x432bc2002000,
    2021-02-11T03:31:53.967Z cpu4:2107287)0x45389609bdf0:[0x42001d1296d0]ecore_int_sp_dpc@(qedentv)#<None>+0x331 stack: 0x0, 0x42001c3bfb6b, 0x76f1e5c0, 0x2000097, 0x14c2002
    2021-02-11T03:31:54.039Z cpu4:2107287)0x45389609be60:[0x42001c0db867]IntrCookieBH@vmkernel#nover+0x17c stack: 0x45389609be80, 0x40992f09ba, 0x43007a436690, 0x43007a43669
    2021-02-11T03:31:54.116Z cpu4:2107287)0x45389609bef0:[0x42001c0be6b0]BH_Check@vmkernel#nover+0x121 stack: 0x98ba, 0x33e72f6f6e20, 0x0, 0x8000000000000000, 0x430000000001
    2021-02-11T03:31:54.187Z cpu4:2107287)0x45389609bf70:[0x42001c28370c]NetPollWorldCallback@vmkernel#nover+0x129 stack: 0x61, 0x42001d0e0000, 0x42001c283770, 0x0, 0x0
    2021-02-11T03:31:54.256Z cpu4:2107287)0x45389609bfe0:[0x42001c380bad]CpuSched_StartWorld@vmkernel#nover+0x86 stack: 0x0, 0x42001c0c2b44, 0x0, 0x0, 0x0
    2021-02-11T03:31:54.319Z cpu4:2107287)0x45389609c000:[0x42001c0c2b43]Debug_IsInitialized@vmkernel#nover+0xc stack: 0x0, 0x0, 0x0, 0x0, 0x0
    2021-02-11T03:31:54.424Z cpu4:2107287)^[[45m^[[33;1mVMware ESXi 7.0.2 [Releasebuild-17435195 x86_64]^[[0m
    #PF Exception 14 in world 2107287:vmnic7-pollW IP 0x42001d3e6f72 addr 0x1c

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

  • PR 2731446 : lorsque le dispositif vSphere Replication se met sous tension, le service hostd peut échouer et provoquer l'absence temporaire de réponse des hôtes ESXi auprès du système vCenter Server.

    Dans de rares cas, lorsque le dispositif vSphere Replication se met sous tension, le service hostd peut échouer et provoquer l'absence temporaire de réponse des hôtes ESXi auprès du système vCenter Server. Le service hostd redémarre automatiquement et la connectivité est rétablie.

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

  • PR 2515171 : La modification d'un paramètre d'options avancées dans un profil d'hôte et la définition d'une valeur sur false entraînent la définition de la valeur sur true

    Lorsque vous tentez de définir une valeur sur false pour un paramètre d'option avancée dans un profil d'hôte, l'interface utilisateur crée une valeur de chaîne non vide. Les valeurs qui ne sont pas vides sont interprétées comme true et le paramètre d'option avancée reçoit une valeur true dans le profil d'hôte.

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

  • PR 2731306 : les hôtes ESXi ne répondent plus à l'instance de vCenter Server avec des messages répétés pour les échecs d'admission

    Les hôtes ESXi peuvent cesser de répondre à l'instance de vCenter Server même lorsque les hôtes sont accessibles et en cours d'exécution. Ce problème se produit dans les images fournisseur avec des pilotes personnalisés où ImageConfigManager consomme plus de RAM que celle allouée. Par conséquent, les échecs répétés de ImageConfigManager entraînent la déconnexion des hôtes ESXi de l'instance de vCenter Server.
    Dans les journaux vmkernel, vous voyez des erreurs répétées telles que :
    Admission failure in path: host/vim/vmvisor/hostd-tmp/sh.<pid1>:python.<pid2>:uw.<pid2>.
    Dans les journaux hostd vous voyez des messages tels que : Task Created : haTask-ha-host-vim.host.ImageConfigManager.fetchSoftwarePackages-<sequence> suivi de : ForkExec(/usr/bin/sh) <pid1>, où <pid1> identifie un processus ImageConfigManager.

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

  • PR 2751564 : si vous diminuez la valeur de l'option de configuration avancée DiskMaxIOSize, les opérations d'E/S des hôtes ESXi peuvent échouer

    Si vous modifiez l'option de configuration avancée DiskMaxIOSize par une valeur inférieure, les E/S avec des blocs de grande taille peuvent être fractionnées et mises en file d'attente de manière incorrecte sur le chemin PSA. Par conséquent, les opérations d'E/S des hôtes ESXi peuvent expirer et échouer.

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

  • PR 2718934 : les opérations de mise sous tension ou hors tension des machines virtuelles prennent trop de temps

    Dans certaines conditions, les opérations de mise sous tension ou hors tension des machines virtuelles peuvent prendre jusqu'à 20 minutes. Ce problème se produit lorsque le stockage sous-jacent des machines virtuelles exécute une opération en arrière-plan, telle que des événements de réanalyse HBA ou APD, et que certains verrous sont maintenus en permanence.

    Le problème est résolu dans cette version. Le correctif supprime les verrous inutiles sur les ressources de stockage et introduit un mutex rapide pour améliorer les performances de fonctionnement d'alimentation de la machine virtuelle.

  • PR 2755056 : les hôtes ESXi échouent avec un écran de diagnostic violet en raison d'une différence de taille de réponse de la page Vital Product Data (VPD)

    Dans de rares cas, lorsque la taille de réponse de la page VPD de l'hôte ESXi cible est différente sur des chemins différents de l'hôte, ESXi peut écrire plus d'octets que la longueur allouée pour un chemin donné. Par conséquent, l'hôte ESXi échoue avec un écran de diagnostic violet avec un message tel que :
    Panic Message: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4878 - Corruption in dlmalloc

    Ce problème est résolu dans cette version. Le correctif permet de suivre la taille des pages VPD à l'aide d'un champ distinct au lieu de dépendre de l'en-tête de réponse VPD.

  • PR 2725886 : une contention de verrouillage rare peut entraîner l'échec de certaines opérations de machine virtuelle

    Une contention de verrouillage rare peut entraîner l'échec d'opérations de machine virtuelle telles que le basculement ou la migration.
    Les messages d'échec de verrouillage sont semblables à :
    vol 'VM_SYS_11', lock at 480321536: [Req mode 1] Checking liveness:
    type 10c00003 offset 480321536 v 1940464, hb offset 3801088
    ou
    Res3: 2496: Rank violation threshold reached: cid 0xc1d00002, resType 2, cnum 5 vol VM_SYS_11

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

  • PR 2766036 : Dans vSphere Client, vous voyez des nombres incorrects pour l'espace provisionné des machines virtuelles

    Dans les workflows compliqués qui entraînent la création de plusieurs machines virtuelles, lorsque vous accédez à VM > Machines virtuelles, vous pouvez voir des nombres importants dans la colonne Espace provisionné pour certaines machines virtuelles. Par exemple, 2,95 To au lieu de l'espace provisionné réel de 25 Go.

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

  • PR 2753231 : un hôte ESXi peut échouer avec un écran de diagnostic violet en raison de l'endommagement d'une pile d'appel dans la pile de stockage ESXi

    Lors du traitement de la commande SCSI READ CAPACITY (10), ESXi peut copier des données excessives de la réponse et endommager la pile d'appels. Par conséquent, l'hôte ESXi échoue avec un écran de diagnostic violet.

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

  • PR 2728910 : les hôtes ESX peuvent échouer avec un écran de diagnostic violet lors de la mise sous tension des machines virtuelles

    Dans de très rares cas, les clusters de ressources VMFS inclus dans une transaction de journal peuvent ne pas être verrouillés. Par conséquent, lors de la mise sous tension des machines virtuelles, plusieurs hôtes ESXi peuvent échouer avec un écran de diagnostic violet en raison de l'exception 14 dans la couche VMFS. Un message et une trace de pile typiques visibles dans le journal vmkernel sont les suivants :
    @BlueScreen: #PF Exception 14 in world 2097684:VSCSI Emulat IP 0x418014d06fca addr 0x0
    PTEs:0x16a47a027;0x600faa8007;0x0;
    2020-06-24T17:35:57.073Z cpu29:2097684)Code start: 0x418013c00000 VMK uptime: 0:01:01:20.555
    2020-06-24T17:35:57.073Z cpu29:2097684)0x451a50a1baa0:[0x418014d06fca]Res6MemUnlockTxnRCList@esx#nover+0x176 stack: 0x1 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb10:[0x418014c7cdb6]J3_DeleteTransaction@esx#nover+0x33f stack: 0xbad0003
    2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb40:[0x418014c7db10]J3_AbortTransaction@esx#nover+0x105 stack: 0x0 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb80:[0x418014cbb752]Fil3_FinalizePunchFileHoleTxnVMFS6@esx#nover+0x16f stack: 0x430fe950e1f0
    2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bbd0:[0x418014c7252b]Fil3UpdateBlocks@esx#nover+0x348 stack: 0x451a50a1bc78 2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bce0:[0x418014c731dc]Fil3_PunchFileHoleWithRetry@esx#nover+0x89 stack: 0x451a50a1bec8
    2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bd90:[0x418014c739a5]Fil3_FileBlockUnmap@esx#nover+0x50e stack: 0x230eb5 2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be40:[0x418013c4c551]FSSVec_FileBlockUnmap@vmkernel#nover+0x6e stack: 0x230eb5
    2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be90:[0x418013fb87b1]VSCSI_ExecFSSUnmap@vmkernel#nover+0x8e stack: 0x0 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf00:[0x418013fb71cb]VSCSIDoEmulHelperIO@vmkernel#nover+0x2c stack: 0x430145fbe070
    2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf30:[0x418013ceadfa]HelperQueueFunc@vmkernel#nover+0x157 stack: 0x430aa05c9618 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bfe0:[0x418013f0eaa2]CpuSched_StartWorld@vmkernel#nover+0x77 stack: 0x0
    2020-06-24T17:35:57.083Z cpu29:2097684)base fs=0x0 gs=0x418047400000 Kgs=0x0

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

  • PR 2741111 : l'échec de certains CPU Intel à transférer des interruptions d'exception de débogage (#DB) peut entraîner une triple panne de machine virtuelle

    Dans de rares cas, certains CPU Intel peuvent ne pas parvenir à transférer des interruptions #DB et si une interruption de temporisateur se produit lors de l'appel système Windows, cela peut entraîner une triple panne de la machine virtuelle.

    Ce problème est résolu dans cette version. Le correctif transfère toutes les interruptions #DB des CPU vers le système d'exploitation invité, sauf lorsque l'interruption de base de données provient d'un débogueur attaché à la machine virtuelle.

  • PR 2759343 : le service sfcbd ne démarre pas lorsque vous redémarrez les agents de gestion ESXi à partir de l'interface DCUI (Direct Console User Interface)

    Si vous redémarrez les agents de gestion ESXi depuis DCUI, le service sfcbd ne démarre pas. Vous devez démarrer manuellement le service SFCB.

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

  • PR 2721379 : le service hostd enregistre un avertissement pour les capteurs d'alimentation toutes les 2 minutes.

    Le service hostd enregistre le message BuildPowerSuplySensorList a trouvé 0 capteur d'alimentation toutes les 2 minutes. Ce problème se produit lorsque vous effectuez une mise à niveau vers ESXi 7.0 Update 1 ou une nouvelle installation de cette version sur un hôte ESXi.

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

  • PR 2751277 : les hôtes ESXi peuvent échouer avec un écran de diagnostic violet en raison d'une erreur de référence de pointeur nul

    Dans de rares cas, l'allocateur de mémoire du noyau peut renvoyer un pointeur NULL qui peut ne pas être correctement déréférencé. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet avec une erreur telle que #GP Exception 13 in world 2422594:vmm:overCom @ 0x42003091ede4. Dans la trace de débogage, vous voyez des messages semblables à :
    #1 Util_ZeroPageTable
    #2 Util_ZeroPageTableMPN
    #3 VmMemPfUnmapped
    #4 VmMemPfInt
    #5 VmMemPfGetMapping
    #6 VmMemPf
    #7 VmMemPfLockPageInt
    #8 VMMVMKCall_Call
    #9 VMKVMM_ArchEnterVMKernel

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

  • PR 2708326 : Si un périphérique NVMe est ajouté et supprimé à chaud dans un court intervalle de temps, l'hôte ESXi peut échouer avec un écran de diagnostic violet

    Si un périphérique NVMe est ajouté à chaud et supprimé à chaud dans un court intervalle de temps, le pilote NVMe peut ne pas initialiser le contrôleur NVMe en raison d'une expiration du délai de la commande. Par conséquent, le pilote peut accéder à la mémoire déjà libérée lors d'un processus de nettoyage. Dans la trace de débogage, l'écran affiche un message de type AVERTISSEMENT : NVMEDEV: NVMEInitializeController:4045: Échec de l'obtention des données d'identité du contrôleur, état : Expiration du délai.
    Finalement, l'hôte ESXi peut échouer avec un écran de diagnostic violet et une erreur de type #PF Exception ... in world ...:vmkdevmgr.

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

  • PR 2755977 : les hôtes ESXi peuvent ne pas parvenir à effectuer un provisionnement statique d'un VMDK ou à créer un fichier d'échange lors de la mise sous tension d'une machine virtuelle

    Lorsqu'un hôte ESXi n'a pas de blocs de fichiers volumineux (LFB) disponibles à allouer, l'hôte effectue le provisionnement statique du VMDK ou la création d'un fichier d'échange avec de petits blocs de fichiers (SFB). Cependant, dans de rares cas, l'hôte peut également ne pas parvenir à allouer des SFB. Par conséquent, le provisionnement statique de VMDK ou la création d'un fichier d'échange échoue. Lorsque des machines virtuelles tentent de se mettre sous tension, une erreur dans les journaux vmkernel s'affiche, telle que :
     vmkernel.1:2021-01-08T19:13:28.341Z cpu20:2965260)Fil3: 10269 : Le nombre maximal de tentatives de suppression d'espace (10) a été dépassé pour l'appelant Fil3_SetFileLength de l'appelant (état « Aucun espace restant sur le périphérique »)

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

  • PR 2737934 : si vous utilisez des banques de données VMFS6 très volumineuses, vous pouvez voir des erreurs de verrouillage de CPU répétées ou les hôtes ESXi peuvent échouer par intermittence

    Lorsque vous utilisez des banques de données VMFS6 très volumineuses, le processus d'allocation de blocs de fichiers pour des VMDK dynamiques dans un cluster de ressources peut entraîner un verrouillage de CPU. Par conséquent, vous voyez des messages de verrouillage de CPU et, dans de rares cas, les hôtes ESXi peuvent échouer. Dans la trace de débogage, vous voyez des messages tels que :
    2021-04-07T02:18:08.730Z cpu31:2345212)WARNING: Heartbeat: 849 : PCPU 10 didn't have a heartbeat for 7 seconds; *may* be locked up.
    La trace de débogage associée impliquant les fonctions Res6AffMgr ressemble à ce qui :
    2021-01-06T02:16:16.073Z cpu0:2265741)ALERT: NMI: 694: NMI IPI: RIPOFF(base):RBP:CS [0x121d74d(0x42001a000000):0x50d0:0xf48] (Src 0x1, CPU0)
    2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b320:[0x42001b21d74c]Res6AffMgrComputeSortIndices@esx#nover+0x369 stack: 0x43119125a000
    2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b3b0:[0x42001b224e46]Res6AffMgrGetCluster@esx#nover+0xb1f stack: 0xd 2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b4b0:[0x42001b226491]Res6AffMgr_AllocResourcesInt@esx#nover+0x40a stack: 0x4311910f4890
    2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b680:[0x42001b2270e2]Res6AffMgr_AllocResources@esx#nover+0x1b stack: 0x0

    Ce problème est résolu dans cette version. Pour plus d'informations, reportez-vous à l'article 83473 de la base de connaissances VMware.

  • PR 2777001 : les hôtes ESXi dont le nombre de CPU physiques est élevé peuvent échouer avec un écran de diagnostic violet pendant ou après une mise à niveau vers ESXi 7.0 Update 2

    Pendant ou après une mise à niveau vers ESXi 7.0 Update 2, la couche de stockage ESX peut ne pas allouer suffisamment de ressources mémoire pour les hôtes ESXi disposant d'un nombre important de CPU physiques et de nombreux périphériques ou chemins de stockage connectés aux hôtes. Par conséquent, ces hôtes ESXi peuvent échouer avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version. Le correctif corrige l'allocation de mémoire de la couche de stockage ESX.

  • PR 2760932 : les machines virtuelles avec la version de matériel 18 peuvent échouer par intermittence lors des opérations de vSphere vMotion

    Les machines virtuelles disposant de la version de matériel 18 et de VMware Tools 11.2.0 ou version ultérieure peuvent échouer en raison d'un problème de périphérique graphique virtuel côté destination lors d'une opération vSphere vMotion ou Storage vMotion.
    Dans le vmkernel.log vous voyez une ligne telle que :
    PF failed to handle a fault on mmInfo at va 0x114f5ae0: Out of memory. Terminating...

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

  • PR 2731263 : après la mise à jour vers la version de matériel 18, une alerte de noyau du SE invité s'affiche sur les machines virtuelles

    Après la mise à jour vers la version de matériel 18, certains SE invités, tels que CentOS 7, sur des CPU AMD peuvent échouer avec une alerte de noyau lorsque vous démarrez la machine virtuelle. Le message d'alerte de noyau s'affiche lorsque vous ouvrez une console Web pour la machine virtuelle.

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

  • PR 2731142 : les paquets avec l'option Limite d'encapsulation de tunnel IPv6 sont perdus dans le trafic entre les machines virtuelles

    Certains noyaux Linux ajoutent l'option Limite d'encapsulation de tunnel IPv6 aux paquets de tunnel IPv6 comme décrit dans RFC 2473, par. 5.1. Par conséquent, les paquets de tunnel IPv6 sont abandonnés dans le trafic entre les machines virtuelles, en raison de l'en-tête d'extension IPv6.

    Ce problème est résolu dans cette version. Le correctif analyse correctement les paquets avec l'option Limite d'encapsulation de tunnel IPv6.

  • PR 2760267 : dans les journaux vmkernel, vous voyez plusieurs avertissements indiquant une commutation vers le chemin préféré XXX dans l'état de VEILLE pour le périphérique XXX

    Lorsque des supports virtuels, tels qu'un lecteur CD, sont connectés à votre environnement vSphere à l'aide d'un contrôleur iDRAC (Integrated Dell Remote Access Controller) et qu'aucun fichier de support n'est mappé au lecteur, le journal vmkernel peut afficher plusieurs messages d'avertissement tels que :
    vmw_psp_fixed: psp_fixedSelectPathToActivateInt:439: Switching to preferred path vmhba32:C0:T0:L1 in STANDBY state for device mpx.vmhba32:C0:T0:L1.WARNING: vmw_psp_fixed: psp_fixedSelectPathToActivateInt:464: Selected current STANDBY path vmhba32:C0:T0:L1 for device mpx.vmhba32:C0:T0:L1 to activate. This may lead to path thrashing.

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

  • PR 2749688 : l'instance de vCenter Server peut, par intermittence, supprimer des ports virtuels distribués internes contrôlés par NSX sur des hôtes ESXi

    Pendant les workflows de synchronisation de 24 heures du vSphere Distributed Switch, l'instance de vCenter Server peut supprimer par intermittence les ports virtuels distribués contrôlés par NSX, tels que le port SPF (Service Plane Forwarding), des hôtes ESXi. Par conséquent, les opérations vSphere vMotion de machines virtuelles peuvent échouer. Vous voyez une erreur telle que Could not connect SPF port : Not Found dans les journaux.

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

  • PR 2763986 : si vous configurez la partition de travail dans le répertoire racine d'un volume VMFS, la mise à niveau vers ESXi 7.0.x échoue et vous risquez de perdre des données sur le volume VMFS

    ESXi 7.0 a introduit la partition ESX-OSData basée sur VMFS-L, qui joue le rôle de partition de travail, de partition de casier pour VMware Tools et de destination de vidage de mémoire. Si vous configurez la partition de travail sur le répertoire racine d'un volume VMFS lors d'une mise à niveau vers ESXi 7.0.x, le système tente de convertir les fichiers VMFS au format VMFS-L pour répondre aux exigences de partition OS-Data. Par conséquent, la partition OS-Data peut écraser le volume VMFS et provoquer une perte de données.

    Ce problème est résolu dans cette version. Le correctif ajoute une vérification si le système de fichiers est VFAT avant de le convertir en OS-DATA. Pour plus d'informations, reportez-vous à l'article 83647 de la base de connaissances VMware.

  • PR 2765534 : l'état de santé du canal de communication des hôtes ESXi dans les clusters NSX Data Center for vSphere est inactif après la mise à niveau vers ESXi 7.0 Update 2a

    En raison d'un problème de gestion des journaux, après une mise à niveau vers ESXi 7.0 Update 2a, lorsque vous vérifiez l'état de santé du canal de communication, vous voyez tous les hôtes ESXi dont l'état est inactif, car NSX Manager ne parvient pas à se connecter à l'agent de pare-feu.

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, arrêtez le service vsfwd et recommencez l'opération de mise à niveau.

  • PR 2766127 : si vous mettez à niveau les hôtes ESXi à l'aide de vSphere Quick Boot dans un environnement FCoE, le serveur physique peut échouer avec un écran de diagnostic violet

    Si un hôte ESXi version 7.0 Update 2 est installé sur un LUN FCoE et utilise le mode de démarrage UEFI, lorsque vous tentez de mettre à niveau l'hôte à l'aide de vSphere QuickBoot, le serveur physique peut échouer avec un écran de diagnostic violet en raison d'une erreur de mémoire.

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

  • PR 2777003 : si vous utilisez un périphérique USB comme périphérique de démarrage pour ESXi 7.0 Update 2a, les hôtes ESXi peuvent cesser de répondre, et vous verrez apparaître les alertes « l'hôte ne répond pas » et « boot bank est introuvable ».

    Les périphériques USB ont une petite profondeur de file d'attente et, en raison d'une condition de concurrence dans la pile de stockage ESXi, certaines opérations d'E/S peuvent ne pas atteindre le périphérique. Ces E/S sont mises en file d'attente dans la pile de stockage ESXi et finissent par expirer. Par conséquent, les hôtes ESXi cessent de répondre.
    Dans vSphere Client, vous voyez des alertes telles que Alerte : /bootbank introuvable dans le chemin « /bootbank » et L'hôte ne répond pas.
    Dans les journaux vmkernel.*, vous voyez des erreurs telles que :
    2021-04-12T04:47:44.940Z cpu0:2097441)ScsiPath: 8058: Cancelled Cmd(0x45b92ea3fd40) 0xa0, cmdId.initiator=0x4538c859b8f8 CmdSN 0x0 from world 0 to path "vmhba32:C0:T0:L0". Cmd count Active:0 Queued:1.
    2021-04-12T04:48:50.527Z cpu2:2097440)ScsiDeviceIO: 4315: Cmd(0x45b92ea76d40) 0x28, cmdId.initiator=0x4305f74cc780 CmdSN 0x1279 from world 2099370 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x5 D:0x0 P:0x0 Cancelled from path layer. Cmd count Active:1
    2021-04-12T04:48:50.527Z cpu2:2097440)Queued:4

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

  • PR 2778793 : la durée de démarrage des hôtes ESXi ralentit après la mise à niveau vers ESXi Update 2a

    Vous pouvez observer un ralentissement allant jusqu'à 60 minutes dans le délai de démarrage des hôtes ESXi après une mise à niveau vers ESXi Update 2a.
    Ce problème n'affecte pas les mises à jour ESXi Update 2a à partir de versions antérieures à ESXi 7.0.x.
    Ce problème se produit uniquement lorsque vous utilisez une image vSphere Lifecycle Manager ou une ligne de base, ou la commande esxcli software profile update pour effectuer l'opération de mise à niveau. Si vous utilisez une image ISO ou une installation basée sur un script, vous ne rencontrez pas ce problème.
    Ce problème est plus susceptible d'affecter les configurations iSCSI, mais il est lié à l'algorithme d'ESXi pour la détection de la banque de démarrage, et non au ralentissement des cibles de stockage externes.

    Ce problème est résolu dans cette version. Le correctif augmente les limites de tolérance lorsqu'un fichier ou un stockage boot.cfg n'est pas fourni rapidement.

  • PR 2755807 : les opérations vSphere vMotion sur un hôte ESXi échouent avec une erreur de mémoire insuffisante

    En raison d'une fuite de mémoire dans le segment de mémoire de l'ensemble de ports, les opérations vSphere vMotion sur un hôte ESXi peuvent échouer et afficher une erreur de mémoire insuffisante. Dans vSphere Client, vous voyez une erreur telle que :
    Échec de réservation du port : DVSwitch 50 18 34 d1 76 81 ec 9e-03 62 e2 d4 6f 23 30 ba port 1 39.
    Échec avec l'état d'erreur : Mémoire insuffisante.

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

  • PR 2760081 : avertissement de santé du moteur de recommandation de build vSAN après la mise à niveau vers vSAN 7.0 Update 2

    Si l'instance de vCenter Server ne peut pas résoudre vcsa.vmware.com en une adresse IP, le catalogue de versions vSAN ne peut pas être téléchargé. Le contrôle de santé vSAN suivant affiche un avertissement : santé du moteur de recommandations de build vSAN.
    Un message d'erreur similaire au message suivant peut s'afficher :
    2021-04-12T11:40:59.435Z ERROR vsan-mgmt[32221] [VsanHttpRequestWrapper::urlopen opID=noOpId] Exception while sending request : Cannot resolve localhost or Internet websites.
    2021-04-12T11:40:59.435Z WARNING vsan-mgmt[32221] [VsanVumCoreUtil::CheckVumServiceStatus opID=noOpId] Failed to connect VUM service: Cannot resolve localhost or Internet websites.
    2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumIntegration::VumStatusCallback opID=noOpId] VUM is not installed or not responsive ​
    2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumSystemUtil::HasConfigIssue opID=noOpId] Config issue health.test.vum.vumDisabled exists on entity None

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

  • PR 2731644 : une activité de nettoyage plus élevée que d'habitude s'affiche sur vSAN

    Un bogue de dépassement de capacité d'entier peut amener vSAN DOM à émettre des nettoyages plus fréquemment que le paramètre configuré.

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

  • PR 2749815 : les hôtes ESXi échouent avec un écran de diagnostic violet lorsqu'une resynchronisation est abandonnée avec des écritures d'invité actives

    Lorsqu'une resynchronisation s'exécute en parallèle avec des écritures d'invité sur des objets appartenant à un hôte ESXi, l'hôte peut échouer avec un écran de diagnostic violet.

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

  • PR 2749962 : vous voyez une erreur Syslog Failed to write header on rotate

    Lorsque le fichier cmmdstimemachineDump.log atteint une limite maximale de 10 Mo, la rotation se produit et un nouveau fichier cmmdstimemachineDump est créé. Cependant, pendant la rotation, dans les journaux vmsyslogd.err, vous pouvez voir une erreur telle que :
    2021-04-08T03:15:53.719Z vmsyslog.loggers.file : ERROR ] Failed to write header on rotate. Exception: [Errno 2] No such file or directory: '/var/run/cmmdstimemachineDumpHeader.txt'

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

  • PR 2738238 : la tâche de modification du format de l'objet prend beaucoup de temps à répondre

    Dans certains cas, la surveillance du cluster, l'appartenance et le service d'annuaire (CMMDS) ne fournissent pas une entrée correcte à la tâche Modification du format d'objet et la tâche prend beaucoup de temps à répondre.

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

  • PR 2799408 : la mise à niveau d'un cluster étendu vers la version ESXi 7.0 Update 2 ou version ultérieure peut entraîner l'échec de plusieurs hôtes ESX avec un écran de diagnostic violet

    Dans de rares cas, si l'hôte témoin est remplacé pendant le processus de mise à niveau et qu'une tâche de conversion du format de disque s'exécute peu après le remplacement, plusieurs hôtes ESX sur un cluster étendu peuvent échouer avec un écran de diagnostic violet.

    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.

esx-update_7.0.2-0.20.18426014
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_loadesx_7.0.2-0.20.18426014
  • VMware_bootbank_esx-update_7.0.2-0.20.18426014
PR résolus 2722263, 2812906
Numéros CVE S.O.

Met à jour les VIB loadesx et esx-update pour résoudre le problème suivant :

  • PR 2722263 : vous ne pouvez pas supprimer des composants dans une image ESXi personnalisée après la mise à niveau vers ESXi 7.0 Update 2a

    Si vous créez une image personnalisée de version 7.0 Update 2a à l'aide du kit de modularisation ESXi, remplacez certains composants dans l'image de base, par exemple Intel-ixgben:1.8.9.0-1OEM.700.1.0.15525992, puis mettez à niveau vos hôtes ESXi 7.0.x, vous ne pouvez pas supprimer le composant personnalisé après la mise à niveau. En outre, certains VIB des composants personnalisés peuvent être manquants.

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

  • PR 2812906 : les métadonnées des banques de données VMFS peuvent être endommagées dans certains scénarios de déploiement ESXi en raison de la duplication des UUID (Universally Unique Identifiers) du système

    Certains scénarios de déploiement, tels que le clonage de banques de démarrage ESXi, peuvent aboutir à des UUID entièrement identiques de plusieurs hôtes ESXi. Comme les UUID sont utilisés pour les opérations de signal de pulsation et de journal VMFS, lorsque des UUID sont dupliqués après les opérations d'installation ou de mise à niveau, plusieurs hôtes ESXi tentent d'accéder aux régions de métadonnées sur la même banque de données VMFS. Par conséquent, vous pouvez voir des métadonnées endommagées dans certaines banques de données VMFS.
    Dans les journaux vmkernel vous voyez des messages tels que :
    vmkernel 608: VMFS volume DCS_HCFA_TEDS_Regulated_10032/5ba2905b-ac11166d-b145-0025b5920a02 on naa.60060e8012a34f005040a34f00000d64:1 has been detected corrupted.
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 319: FS3RCMeta 2245 200 21 105 0
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 326: 0 0 0 0 0 0 0 0 0 0 0 7 0 254 1 4 0 248 3 96 0 0 0 0 0
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 332: 0 0 0
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 338: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

    Les autres scénarios de déploiement affectés sont la réutilisation de profils matériels, par exemple des systèmes lame qui utilisent la même adresse MAC pour déployer une nouvelle instance, et le déplacement des disques de démarrage entre les serveurs.

    Solution : aucune. Pour plus d'informations, reportez-vous aux articles 84280 et 84349 de la base de connaissances VMware.

Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.702.0.20.18426014
Catégorie des correctifs Correctif de bogues
Gravité des correctifs Important
Redémarrage de l'hôte requis Oui
Migration ou arrêt de la machine virtuelle requis Oui
Matériel concerné S.O.
Logiciels concernés S.O.
VIB inclus
  • VMW_bootbank_bnxtroce_216.0.58.0-20vmw.702.0.20.18426014
  • VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.20.18426014
PR résolus S.O.
Numéros CVE S.O.

Met à jour le VIB bnxtroce.

    MRVL-E4-CNA-Driver-Bundle_1.0.0.0-1vmw.702.0.20.18426014
    Catégorie des correctifs Correctif de bogues
    Gravité des correctifs Important
    Redémarrage de l'hôte requis Oui
    Migration ou arrêt de la machine virtuelle requis Oui
    Matériel concerné S.O.
    Logiciels concernés S.O.
    VIB inclus
    • VMW_bootbank_qedrntv_3.40.5.53-17vmw.702.0.20.18426014
    • VMW_bootbank_qedentv_3.40.5.53-20vmw.702.0.20.18426014
    PR résolus S.O.
    Numéros CVE S.O.

    Met à jour le VIB qedrntv.

      Intel-i40en_1.8.1.137-1vmw.702.0.20.18426014
      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_i40enu_1.8.1.137-1vmw.702.0.20.18426014
      PR résolus

      2750390
      Numéros CVE S.O.

      Met à jour le VIB i40enu pour résoudre le problème suivant :

      • PR 2750390 : après une mise à niveau vers ESXi 7.0 Update 2a, les VIB des pilotes réseau i40en asynchrones pour ESXi sont ignorés ou restaurés vers le pilote de la boîte de réception VMware i40enu

        À partir de vSphere 7.0 Update 2, le nom du pilote i40en de la boîte de réception a été remplacé par i40enu. Par conséquent, si vous tentez d'installer un pilote asynchrone de partenaire i40en, le VIB i40en est ignoré ou restauré vers le pilote de la boîte de réception VMware i40enu.

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

      Broadcom-ELX-lpfc_12.8.298.3-2vmw.702.0.20.18426014
      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_12.8.298.3-2vmw.702.0.20.18426014
      PR résolus 2715138
      Numéros CVE S.O.

      Met à jour le VIB lpfc pour résoudre le problème suivant :

      • PR 2715138 : les hôtes ESXi peuvent échouer avec un écran de diagnostic violet lors de l'installation du plug-in Dell EMC PowerPath

        Une erreur rare de Défaut de page peut entraîner l'échec des hôtes ESXi avec un écran de diagnostic violet lors de l'installation du plug-in Dell EMC PowerPath.

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

      VMware-vmkusb_0.1-4vmw.702.0.20.18426014
      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-4vmw.702.0.20.18426014
      PR résolus 2753546
      Numéros CVE S.O.

      Met à jour le VIB vmkusb pour résoudre le problème suivant :

      • PR 2753546 : si vous utilisez un terminal de démarrage USB, la connexion à la partition /bootbank peut s'interrompre ou la partition VMFS-L LOCKER est endommagée

        Si le contrôleur hôte USB se déconnecte de votre système vSphere et qu'une ressource sur le périphérique, telle que les fichiers de vidage mémoire, est toujours utilisée par ESXi, le chemin du périphérique ne peut pas être libéré avant la reconnexion du périphérique. Par conséquent, ESXi fournit un nouveau chemin d'accès au périphérique USB, ce qui rompt la connexion à la partition /bootbank ou endommage la partition VMFS-L LOCKER.

        Ce problème est résolu dans cette version. Le correctif améliore le pilote du contrôleur hôte USB pour tolérer les échecs de délai d'expiration de la commande afin de laisser à ESXi suffisamment de temps pour libérer des ressources du périphérique USB.
        Il est recommandé de ne pas définir la partition de vidage sur le périphérique de stockage USB. Pour plus d'informations, reportez-vous aux articles 2077516 et 2149257 de la base de connaissances VMware.

      ESXi_7.0.2-0.15.18295176
      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_vdfs_7.0.2-0.15.18295176
      • VMware_bootbank_esx-xserver_7.0.2-0.15.18295176
      • VMware_bootbank_esx-base_7.0.2-0.15.18295176
      • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.15.18295176
      • VMware_bootbank_crx_7.0.2-0.15.18295176
      • VMware_bootbank_native-misc-drivers_7.0.2-0.15.18295176
      • VMware_bootbank_cpu-microcode_7.0.2-0.15.18295176
      • VMware_bootbank_gc_7.0.2-0.15.18295176
      • VMware_bootbank_vsanhealth_7.0.2-0.15.18295176
      • VMware_bootbank_clusterstore_7.0.2-0.15.18295176
      • VMware_bootbank_vsan_7.0.2-0.15.18295176
      PR résolus 2738816, 2738857, 2735594
      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 vdfs, esx-xserver, esx-base, esx-dvfilter-generic-fastpath, crx, native-misc-drivers, cpu-microcode, gc, vsanhealth, clusterstore, vsan et esx-base pour résoudre les problèmes suivants :

      • Mise à jour d'OpenSSH

        OpenSSH a été mis à jour vers la version 8.5p1.

      • Mise à jour de la bibliothèque OpenSSL

        La bibliothèque OpenSSL a été mise à jour vers la version openssl-1.0.2y.

      • Mise à jour de la bibliothèque Libarchive

        La bibliothèque Libarchive a été mise à jour vers la version 3.5.1.

      esx-update_7.0.2-0.15.18295176
      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_loadesx_7.0.2-0.15.18295176
      • VMware_bootbank_esx-update_7.0.2-0.15.18295176
      PR résolus S.O.
      Numéros CVE S.O.

      Met à jour les VIB loadesx et esx-update.

        VMware-VM-Tools_11.2.6.17901274-18295176
        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_11.2.6.17901274-18295176
        PR résolus 2761942
        Numéros CVE S.O.

        Met à jour le VIB tools-light pour résoudre le problème suivant :

        VMware-vmkusb_0.1-1vmw.702.0.15.18295176
        Catégorie des correctifs Sécurité
        Gravité des correctifs Modéré
        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-1vmw.702.0.15.18295176
        PR résolus S.O.
        Numéros CVE S.O.

        Met à jour le VIB vmkusb.

          ESXi-7.0U2c-18426014-standard
          Nom du profil ESXi-7.0U2c-18426014-standard
          Build Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.
          Fournisseur VMware, Inc.
          Date de publication 24 août 2021
          Niveau d'acceptation PartnerSupported
          Matériel concerné S.O.
          Logiciels concernés S.O.
          VIB concernés
          • VMware_bootbank_vsanhealth_7.0.2-0.20.18426014
          • VMware_bootbank_vsan_7.0.2-0.20.18426014
          • VMware_bootbank_gc_7.0.2-0.20.18426014
          • VMware_bootbank_esx-xserver_7.0.2-0.20.18426014
          • VMware_bootbank_clusterstore_7.0.2-0.20.18426014
          • VMware_bootbank_vdfs_7.0.2-0.20.18426014
          • VMware_bootbank_native-misc-drivers_7.0.2-0.20.18426014
          • VMware_bootbank_cpu-microcode_7.0.2-0.20.18426014
          • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.20.18426014
          • VMware_bootbank_esx-base_7.0.2-0.20.18426014
          • VMware_bootbank_loadesx_7.0.2-0.20.18426014
          • VMware_bootbank_esx-update_7.0.2-0.20.18426014
          • VMW_bootbank_bnxtroce_216.0.58.0-20vmw.702.0.20.18426014
          • VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.20.18426014
          • VMW_bootbank_qedrntv_3.40.5.53-17vmw.702.0.20.18426014
          • VMW_bootbank_qedentv_3.40.5.53-20vmw.702.0.20.18426014
          • VMW_bootbank_i40enu_1.8.1.137-1vmw.702.0.20.18426014
          • VMW_bootbank_lpfc_12.8.298.3-2vmw.702.0.20.18426014
          • VMW_bootbank_vmkusb_0.1-4vmw.702.0.20.18426014
          PR résolus 2717698, 2731446, 2515171, 731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408, 2722263, 2812906, 2750390, 2715138, 2753546
          Numéros CVE associés S/O

          Ce correctif met à jour les problèmes suivants :

            • Une condition de concurrence rare dans le pilote qedentv peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet. Ce problème survient lorsqu'une interruption complète de Rx se produit juste après la destruction d'une paire de files d'attente (QP) de l'interface des services généraux (GSI), par exemple lors du déchargement d'un pilote qedentv ou de l'arrêt d'un système. Dans ce cas, le pilote qedentv peut accéder à une adresse de QP déjà libérée, ce qui entraîne une exception PF. Ce problème peut se produire sur les hôtes ESXi connectés à un commutateur physique occupé avec un trafic GSI non sollicité intense. Dans la trace de débogage, vous voyez des messages tels que :

              cpu4:2107287)0x45389609bcb0:[0x42001d3e6f72]qedrntv_ll2_rx_cb@(qedrntv)#<None>+0x1be stack: 0x45b8f00a7740, 0x1e146d040, 0x432d65738d40, 0x0, 0x
              2021-02-11T03:31:53.882Z cpu4:2107287)0x45389609bd50:[0x42001d421d2a]ecore_ll2_rxq_completion@(qedrntv)#<None>+0x2ab stack: 0x432bc20020ed, 0x4c1e74ef0, 0x432bc2002000,
              2021-02-11T03:31:53.967Z cpu4:2107287)0x45389609bdf0:[0x42001d1296d0]ecore_int_sp_dpc@(qedentv)#<None>+0x331 stack: 0x0, 0x42001c3bfb6b, 0x76f1e5c0, 0x2000097, 0x14c2002
              2021-02-11T03:31:54.039Z cpu4:2107287)0x45389609be60:[0x42001c0db867]IntrCookieBH@vmkernel#nover+0x17c stack: 0x45389609be80, 0x40992f09ba, 0x43007a436690, 0x43007a43669
              2021-02-11T03:31:54.116Z cpu4:2107287)0x45389609bef0:[0x42001c0be6b0]BH_Check@vmkernel#nover+0x121 stack: 0x98ba, 0x33e72f6f6e20, 0x0, 0x8000000000000000, 0x430000000001
              2021-02-11T03:31:54.187Z cpu4:2107287)0x45389609bf70:[0x42001c28370c]NetPollWorldCallback@vmkernel#nover+0x129 stack: 0x61, 0x42001d0e0000, 0x42001c283770, 0x0, 0x0
              2021-02-11T03:31:54.256Z cpu4:2107287)0x45389609bfe0:[0x42001c380bad]CpuSched_StartWorld@vmkernel#nover+0x86 stack: 0x0, 0x42001c0c2b44, 0x0, 0x0, 0x0
              2021-02-11T03:31:54.319Z cpu4:2107287)0x45389609c000:[0x42001c0c2b43]Debug_IsInitialized@vmkernel#nover+0xc stack: 0x0, 0x0, 0x0, 0x0, 0x0
              2021-02-11T03:31:54.424Z cpu4:2107287)^[[45m^[[33;1mVMware ESXi 7.0.2 [Releasebuild-17435195 x86_64]^[[0m
              #PF Exception 14 in world 2107287:vmnic7-pollW IP 0x42001d3e6f72 addr 0x1c

            • Dans de rares cas, lorsque le dispositif vSphere Replication se met sous tension, le service hostd peut échouer et provoquer l'absence temporaire de réponse des hôtes ESXi auprès du système vCenter Server. Le service hostd redémarre automatiquement et la connectivité est rétablie.

            • Lorsque vous tentez de définir une valeur sur false pour un paramètre d'option avancée dans un profil d'hôte, l'interface utilisateur crée une valeur de chaîne non vide. Les valeurs qui ne sont pas vides sont interprétées comme true et le paramètre d'option avancée reçoit une valeur true dans le profil d'hôte.

            • Les hôtes ESXi peuvent cesser de répondre à l'instance de vCenter Server même lorsque les hôtes sont accessibles et en cours d'exécution. Ce problème se produit dans les images fournisseur avec des pilotes personnalisés où ImageConfigManager consomme plus de RAM que celle allouée. Par conséquent, les échecs répétés de ImageConfigManager entraînent la déconnexion des hôtes ESXi de l'instance de vCenter Server.
              Dans les journaux vmkernel, vous voyez des erreurs répétées telles que :
              Admission failure in path: host/vim/vmvisor/hostd-tmp/sh.<pid1>:python.<pid2>:uw.<pid2>.
              Dans les journaux hostd vous voyez des messages tels que : Task Created : haTask-ha-host-vim.host.ImageConfigManager.fetchSoftwarePackages-<sequence> suivi de : ForkExec(/usr/bin/sh) <pid1>, où <pid1> identifie une procédure ImageConfigManager.

            • Si vous modifiez l'option de configuration avancée DiskMaxIOSize par une valeur inférieure, les E/S avec des blocs de grande taille peuvent être fractionnées et mises en file d'attente de manière incorrecte sur le chemin PSA. Par conséquent, les opérations d'E/S des hôtes ESXi peuvent expirer et échouer.

            • Dans certaines conditions, les opérations de mise sous tension ou hors tension des machines virtuelles peuvent prendre jusqu'à 20 minutes. Ce problème se produit lorsque le stockage sous-jacent des machines virtuelles exécute une opération en arrière-plan, telle que des événements de réanalyse HBA ou APD, et que certains verrous sont maintenus en permanence.

            • Dans de rares cas, lorsque la taille de réponse de la page VPD de l'hôte ESXi cible est différente sur des chemins différents de l'hôte, ESXi peut écrire plus d'octets que la longueur allouée pour un chemin donné. Par conséquent, l'hôte ESXi échoue avec un écran de diagnostic violet avec un message tel que :
              Panic Message: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4878 - Corruption in dlmalloc

            • Une contention de verrouillage rare peut entraîner l'échec d'opérations de machine virtuelle telles que le basculement ou la migration.
              Les messages d'échec de verrouillage sont semblables à :
              vol 'VM_SYS_11', lock at 480321536: [Req mode 1] Checking liveness:
              type 10c00003 offset 480321536 v 1940464, hb offset 3801088
              ou
              Res3: 2496: Rank violation threshold reached: cid 0xc1d00002, resType 2, cnum 5 vol VM_SYS_11

            • Dans les workflows compliqués qui entraînent la création de plusieurs machines virtuelles, lorsque vous accédez à VM > Machines virtuelles, vous pouvez voir des nombres importants dans la colonne Espace provisionné pour certaines machines virtuelles. Par exemple, 2,95 To au lieu de l'espace provisionné réel de 25 Go.

            • Lors du traitement de la commande SCSI READ CAPACITY (10), ESXi peut copier des données excessives de la réponse et endommager la pile d'appels. Par conséquent, l'hôte ESXi échoue avec un écran de diagnostic violet.

            • Dans de très rares cas, les clusters de ressources VMFS inclus dans une transaction de journal peuvent ne pas être verrouillés. Par conséquent, lors de la mise sous tension des machines virtuelles, plusieurs hôtes ESXi peuvent échouer avec un écran de diagnostic violet en raison de l'exception 14 dans la couche VMFS. Un message et une trace de pile typiques visibles dans le journal vmkernel sont les suivants :
              @BlueScreen: #PF Exception 14 in world 2097684:VSCSI Emulat IP 0x418014d06fca addr 0x0
              PTEs:0x16a47a027;0x600faa8007;0x0;
              2020-06-24T17:35:57.073Z cpu29:2097684)Code start: 0x418013c00000 VMK uptime: 0:01:01:20.555
              2020-06-24T17:35:57.073Z cpu29:2097684)0x451a50a1baa0:[0x418014d06fca]Res6MemUnlockTxnRCList@esx#nover+0x176 stack: 0x1 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb10:[0x418014c7cdb6]J3_DeleteTransaction@esx#nover+0x33f stack: 0xbad0003
              2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb40:[0x418014c7db10]J3_AbortTransaction@esx#nover+0x105 stack: 0x0 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb80:[0x418014cbb752]Fil3_FinalizePunchFileHoleTxnVMFS6@esx#nover+0x16f stack: 0x430fe950e1f0
              2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bbd0:[0x418014c7252b]Fil3UpdateBlocks@esx#nover+0x348 stack: 0x451a50a1bc78 2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bce0:[0x418014c731dc]Fil3_PunchFileHoleWithRetry@esx#nover+0x89 stack: 0x451a50a1bec8
              2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bd90:[0x418014c739a5]Fil3_FileBlockUnmap@esx#nover+0x50e stack: 0x230eb5 2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be40:[0x418013c4c551]FSSVec_FileBlockUnmap@vmkernel#nover+0x6e stack: 0x230eb5
              2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be90:[0x418013fb87b1]VSCSI_ExecFSSUnmap@vmkernel#nover+0x8e stack: 0x0 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf00:[0x418013fb71cb]VSCSIDoEmulHelperIO@vmkernel#nover+0x2c stack: 0x430145fbe070
              2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf30:[0x418013ceadfa]HelperQueueFunc@vmkernel#nover+0x157 stack: 0x430aa05c9618 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bfe0:[0x418013f0eaa2]CpuSched_StartWorld@vmkernel#nover+0x77 stack: 0x0
              2020-06-24T17:35:57.083Z cpu29:2097684)base fs=0x0 gs=0x418047400000 Kgs=0x0

            • Dans de rares cas, certains CPU Intel peuvent ne pas parvenir à transférer des interruptions #DB et si une interruption de temporisateur se produit lors de l'appel système Windows, cela peut entraîner une triple panne de la machine virtuelle.

            • Si vous redémarrez les agents de gestion ESXi depuis DCUI, le service sfcbd ne démarre pas. Vous devez démarrer manuellement le service SFCB.

            • Le service hostd enregistre le message BuildPowerSuplySensorList a trouvé 0 capteur d'alimentation toutes les 2 minutes. Ce problème se produit lorsque vous effectuez une mise à niveau vers ESXi 7.0 Update 1 ou une nouvelle installation de cette version sur un hôte ESXi.

            • Dans de rares cas, l'allocateur de mémoire du noyau peut renvoyer un pointeur NULL qui peut ne pas être correctement déréférencé. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet avec une erreur telle que #GP Exception 13 in world 2422594:vmm:overCom @ 0x42003091ede4. Dans la trace de débogage, vous voyez des messages semblables à :
              #1 Util_ZeroPageTable
              #2 Util_ZeroPageTableMPN
              #3 VmMemPfUnmapped
              #4 VmMemPfInt
              #5 VmMemPfGetMapping
              #6 VmMemPf
              #7 VmMemPfLockPageInt
              #8 VMMVMKCall_Call
              #9 VMKVMM_ArchEnterVMKernel

            • Si un périphérique NVMe est ajouté à chaud et supprimé à chaud dans un court intervalle de temps, le pilote NVMe peut ne pas initialiser le contrôleur NVMe en raison d'une expiration du délai de la commande. Par conséquent, le pilote peut accéder à la mémoire déjà libérée lors d'un processus de nettoyage. Dans la trace de débogage, l'écran affiche un message de type AVERTISSEMENT : NVMEDEV: NVMEInitializeController:4045: Échec de l'obtention des données d'identité du contrôleur, état : Expiration du délai.
              Finalement, l'hôte ESXi peut échouer avec un écran de diagnostic violet et une erreur de type #PF Exception ... in world ...:vmkdevmgr.

            • Lorsqu'un hôte ESXi n'a pas de blocs de fichiers volumineux (LFB) disponibles à allouer, l'hôte effectue le provisionnement statique du VMDK ou la création d'un fichier d'échange avec de petits blocs de fichiers (SFB). Cependant, dans de rares cas, l'hôte peut également ne pas parvenir à allouer des SFB. Par conséquent, le provisionnement statique de VMDK ou la création d'un fichier d'échange échoue. Lorsque des machines virtuelles tentent de se mettre sous tension, une erreur dans les journaux vmkernel s'affiche, telle que :
               vmkernel.1:2021-01-08T19:13:28.341Z cpu20:2965260)Fil3: 10269 : Le nombre maximal de tentatives de suppression d'espace (10) a été dépassé pour l'appelant Fil3_SetFileLength de l'appelant (état « Aucun espace restant sur le périphérique »)

            • Lorsque vous utilisez des banques de données VMFS6 très volumineuses, le processus d'allocation de blocs de fichiers pour des VMDK dynamiques dans un cluster de ressources peut entraîner un verrouillage de CPU. Par conséquent, vous voyez des messages de verrouillage de CPU et, dans de rares cas, les hôtes ESXi peuvent échouer. Dans la trace de débogage, vous voyez des messages tels que :
              2021-04-07T02:18:08.730Z cpu31:2345212)WARNING: Heartbeat: 849 : PCPU 10 didn't have a heartbeat for 7 seconds; *may* be locked up.
              La trace de débogage associée impliquant les fonctions Res6AffMgr ressemble à ce qui :
              2021-01-06T02:16:16.073Z cpu0:2265741)ALERT: NMI: 694: NMI IPI: RIPOFF(base):RBP:CS [0x121d74d(0x42001a000000):0x50d0:0xf48] (Src 0x1, CPU0)
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b320:[0x42001b21d74c]Res6AffMgrComputeSortIndices@esx#nover+0x369 stack: 0x43119125a000
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b3b0:[0x42001b224e46]Res6AffMgrGetCluster@esx#nover+0xb1f stack: 0xd 2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b4b0:[0x42001b226491]Res6AffMgr_AllocResourcesInt@esx#nover+0x40a stack: 0x4311910f4890
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b680:[0x42001b2270e2]Res6AffMgr_AllocResources@esx#nover+0x1b stack: 0x0

            • Pendant ou après une mise à niveau vers ESXi 7.0 Update 2, la couche de stockage ESX peut ne pas allouer suffisamment de ressources mémoire pour les hôtes ESXi disposant d'un nombre important de CPU physiques et de nombreux périphériques ou chemins de stockage connectés aux hôtes. Par conséquent, ces hôtes ESXi peuvent échouer avec un écran de diagnostic violet.

            • Les machines virtuelles disposant de la version de matériel 18 et de VMware Tools 11.2.0 ou version ultérieure peuvent échouer en raison d'un problème de périphérique graphique virtuel côté destination lors d'une opération vSphere vMotion ou Storage vMotion.
              Dans le fichier vmkernel.log vous voyez une ligne telle que :
              PF failed to handle a fault on mmInfo at va 0x114f5ae0: Out of memory. Terminating...

            • Après la mise à jour vers la version de matériel 18, certains SE invités, tels que CentOS 7, sur des CPU AMD peuvent échouer avec une alerte de noyau lorsque vous démarrez la machine virtuelle. Le message d'alerte de noyau s'affiche lorsque vous ouvrez une console Web pour la machine virtuelle.

            • Certains noyaux Linux ajoutent l'option Limite d'encapsulation de tunnel IPv6 aux paquets de tunnel IPv6 comme décrit dans RFC 2473, par. 5.1. Par conséquent, les paquets de tunnel IPv6 sont abandonnés dans le trafic entre les machines virtuelles, en raison de l'en-tête d'extension IPv6.

            • Lorsque des supports virtuels, tels qu'un lecteur CD, sont connectés à votre environnement vSphere à l'aide d'un contrôleur iDRAC (Integrated Dell Remote Access Controller) et qu'aucun fichier de support n'est mappé au lecteur, le journal vmkernel peut afficher plusieurs messages d'avertissement tels que :
              vmw_psp_fixed: psp_fixedSelectPathToActivateInt:439: Switching to preferred path vmhba32:C0:T0:L1 in STANDBY state for device mpx.vmhba32:C0:T0:L1.WARNING: vmw_psp_fixed: psp_fixedSelectPathToActivateInt:464: Selected current STANDBY path vmhba32:C0:T0:L1 for device mpx.vmhba32:C0:T0:L1 to activate. This may lead to path thrashing.

            • Pendant les workflows de synchronisation de 24 heures du vSphere Distributed Switch, l'instance de vCenter Server peut supprimer par intermittence les ports virtuels distribués contrôlés par NSX, tels que le port SPF (Service Plane Forwarding), des hôtes ESXi. Par conséquent, les opérations vSphere vMotion de machines virtuelles peuvent échouer. Vous voyez une erreur telle que Could not connect SPF port : Not Found dans les journaux.

            • ESXi 7.0 a introduit la partition ESX-OSData basée sur VMFS-L, qui joue le rôle de partition de travail, de partition de casier pour VMware Tools et de destination de vidage de mémoire. Si vous configurez la partition de travail sur le répertoire racine d'un volume VMFS lors d'une mise à niveau vers ESXi 7.0.x, le système tente de convertir les fichiers VMFS au format VMFS-L pour répondre aux exigences de partition OS-Data. Par conséquent, la partition OS-Data peut écraser le volume VMFS et provoquer une perte de données.

            • En raison d'un problème de gestion des journaux, après une mise à niveau vers ESXi 7.0 Update 2a, lorsque vous vérifiez l'état de santé du canal de communication, vous voyez tous les hôtes ESXi dont l'état est inactif, car NSX Manager ne parvient pas à se connecter à l'agent de pare-feu.

            • Si un hôte ESXi version 7.0 Update 2 est installé sur un LUN FCoE et utilise le mode de démarrage UEFI, lorsque vous tentez de mettre à niveau l'hôte à l'aide de vSphere QuickBoot, le serveur physique peut échouer avec un écran de diagnostic violet en raison d'une erreur de mémoire.

            • Les périphériques USB ont une petite profondeur de file d'attente et, en raison d'une condition de concurrence dans la pile de stockage ESXi, certaines opérations d'E/S peuvent ne pas atteindre le périphérique. Ces E/S sont mises en file d'attente dans la pile de stockage ESXi et finissent par expirer. Par conséquent, les hôtes ESXi cessent de répondre.
              Dans vSphere Client, vous voyez des alertes telles que Alerte : /bootbank introuvable dans le chemin « /bootbank » et L'hôte ne répond pas.
              Dans les journaux vmkernel.*, vous voyez des erreurs telles que :
              2021-04-12T04:47:44.940Z cpu0:2097441)ScsiPath: 8058: Cancelled Cmd(0x45b92ea3fd40) 0xa0, cmdId.initiator=0x4538c859b8f8 CmdSN 0x0 from world 0 to path "vmhba32:C0:T0:L0". Cmd count Active:0 Queued:1.
              2021-04-12T04:48:50.527Z cpu2:2097440)ScsiDeviceIO: 4315: Cmd(0x45b92ea76d40) 0x28, cmdId.initiator=0x4305f74cc780 CmdSN 0x1279 from world 2099370 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x5 D:0x0 P:0x0 Cancelled from path layer. Cmd count Active:1
              2021-04-12T04:48:50.527Z cpu2:2097440)Queued:4

            • Vous pouvez observer un ralentissement allant jusqu'à 60 minutes dans le délai de démarrage des hôtes ESXi après une mise à niveau vers ESXi Update 2a.
              Ce problème n'affecte pas les mises à jour ESXi Update 2a à partir de versions antérieures à ESXi 7.0.x.
              Ce problème se produit uniquement lorsque vous utilisez une image vSphere Lifecycle Manager, une ligne de base ou la commande esxcli software profile update pour effectuer l'opération de mise à niveau. Si vous utilisez une image ISO ou une installation basée sur un script, vous ne rencontrez pas ce problème.
              Ce problème est plus susceptible d'affecter les configurations iSCSI, mais il est lié à l'algorithme d'ESXi pour la détection de la banque de démarrage, et non au ralentissement des cibles de stockage externes.

            • En raison d'une fuite de mémoire dans le segment de mémoire de l'ensemble de ports, les opérations vSphere vMotion sur un hôte ESXi peuvent échouer et afficher une erreur de mémoire insuffisante. Dans vSphere Client, vous voyez une erreur telle que :
              Échec de réservation du port : DVSwitch 50 18 34 d1 76 81 ec 9e-03 62 e2 d4 6f 23 30 ba port 1 39.
              Échec avec l'état d'erreur : Mémoire insuffisante.

            • Si l'instance de vCenter Server ne peut pas résoudre vcsa.vmware.com en une adresse IP, le catalogue de versions vSAN ne peut pas être téléchargé. Le contrôle de santé vSAN suivant affiche un avertissement : santé du moteur de recommandations de build vSAN.
              Un message d'erreur similaire au message suivant peut s'afficher :
              2021-04-12T11:40:59.435Z ERROR vsan-mgmt[32221] [VsanHttpRequestWrapper::urlopen opID=noOpId] Exception while sending request : Cannot resolve localhost or Internet websites.
              2021-04-12T11:40:59.435Z WARNING vsan-mgmt[32221] [VsanVumCoreUtil::CheckVumServiceStatus opID=noOpId] Failed to connect VUM service: Cannot resolve localhost or Internet websites.
              2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumIntegration::VumStatusCallback opID=noOpId] VUM is not installed or not responsive ​
              2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumSystemUtil::HasConfigIssue opID=noOpId] Config issue health.test.vum.vumDisabled exists on entity None

            • Un bogue de dépassement de capacité d'entier peut amener vSAN DOM à émettre des nettoyages plus fréquemment que le paramètre configuré.

            • Lorsqu'une resynchronisation s'exécute en parallèle avec des écritures d'invité sur des objets appartenant à un hôte ESXi, l'hôte peut échouer avec un écran de diagnostic violet.

            • Lorsque le fichier cmmdstimemachineDump.log atteint une limite maximale de 10 Mo, la rotation se produit et un nouveau fichier cmmdstimemachineDump est créé. Cependant, pendant la rotation, dans les journaux vmsyslogd.err, vous pouvez voir une erreur telle que :
              2021-04-08T03:15:53.719Z vmsyslog.loggers.file : ERROR ] Failed to write header on rotate. Exception: [Errno 2] No such file or directory: '/var/run/cmmdstimemachineDumpHeader.txt'

            • Dans certains cas, la surveillance du cluster, l'appartenance et le service d'annuaire (CMMDS) ne fournissent pas une entrée correcte à la tâche Modification du format d'objet et la tâche prend beaucoup de temps à répondre.

            • Dans de rares cas, si l'hôte témoin est remplacé pendant le processus de mise à niveau et qu'une tâche de conversion du format de disque s'exécute peu après le remplacement, plusieurs hôtes ESX sur un cluster étendu peuvent échouer avec un écran de diagnostic violet.

            • Si vous créez une image personnalisée de version 7.0 Update 2a à l'aide du kit de modularisation ESXi, remplacez certains composants dans l'image de base, par exemple Intel-ixgben:1.8.9.0-1OEM.700.1.0.15525992, puis mettez à niveau vos hôtes ESXi 7.0.x, vous ne pouvez pas supprimer le composant personnalisé après la mise à niveau. En outre, certains VIB des composants personnalisés peuvent être manquants.

            • Lorsque vous clonez un périphérique de démarrage ESXi, vous créez des instances avec des UUID identiques. Comme les UUID sont utilisés pour les opérations de signal de pulsation et de journal VMFS, lorsque vous avez dupliqué l'UUIDS, après les opérations d'installation ou de mise à niveau, plusieurs hôtes ESXi tentent d'accéder aux régions de métadonnées sur la même banque de données VMFS. Par conséquent, vous pouvez voir une corruption massive des métadonnées dans les banques de données VMFS sur plusieurs hôtes ESXi.
              Dans les journaux vmkernel vous voyez des messages tels que :
              vmkernel 608: VMFS volume DCS_HCFA_TEDS_Regulated_10032/5ba2905b-ac11166d-b145-0025b5920a02 on naa.60060e8012a34f005040a34f00000d64:1 has been detected corrupted.
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 319: FS3RCMeta 2245 200 21 105 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 326: 0 0 0 0 0 0 0 0 0 0 0 7 0 254 1 4 0 248 3 96 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 332: 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 338: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

            • À partir de vSphere 7.0 Update 2, le nom du pilote i40en de la boîte de réception a été remplacé par i40enu. Par conséquent, si vous tentez d'installer un pilote asynchrone de partenaire i40en, le VIB i40en est ignoré ou restauré vers le pilote de la boîte de réception VMware i40enu.

            • Une erreur rare de Défaut de page peut entraîner l'échec des hôtes ESXi avec un écran de diagnostic violet lors de l'installation du plug-in Dell EMC PowerPath.

            • Si le contrôleur hôte USB se déconnecte de votre système vSphere et qu'une ressource sur le périphérique, telle que les fichiers de vidage mémoire, est toujours utilisée par ESXi, le chemin du périphérique ne peut pas être libéré avant la reconnexion du périphérique. Par conséquent, ESXi fournit un nouveau chemin d'accès au périphérique USB, ce qui interrompt la connexion à la partition /bootbank ou endommage la partition VMFS-L LOCKER.

          ESXi-7.0U2c-18426014-no-tools
          Nom du profil ESXi-7.0U2c-18426014-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 24 août 2021
          Niveau d'acceptation PartnerSupported
          Matériel concerné S.O.
          Logiciels concernés S.O.
          VIB concernés
          • VMware_bootbank_vsanhealth_7.0.2-0.20.18426014
          • VMware_bootbank_vsan_7.0.2-0.20.18426014
          • VMware_bootbank_gc_7.0.2-0.20.18426014
          • VMware_bootbank_esx-xserver_7.0.2-0.20.18426014
          • VMware_bootbank_clusterstore_7.0.2-0.20.18426014
          • VMware_bootbank_vdfs_7.0.2-0.20.18426014
          • VMware_bootbank_native-misc-drivers_7.0.2-0.20.18426014
          • VMware_bootbank_cpu-microcode_7.0.2-0.20.18426014
          • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.20.18426014
          • VMware_bootbank_esx-base_7.0.2-0.20.18426014
          • VMware_bootbank_loadesx_7.0.2-0.20.18426014
          • VMware_bootbank_esx-update_7.0.2-0.20.18426014
          • VMW_bootbank_bnxtroce_216.0.58.0-20vmw.702.0.20.18426014
          • VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.20.18426014
          • VMW_bootbank_qedrntv_3.40.5.53-17vmw.702.0.20.18426014
          • VMW_bootbank_qedentv_3.40.5.53-20vmw.702.0.20.18426014
          • VMW_bootbank_i40enu_1.8.1.137-1vmw.702.0.20.18426014
          • VMW_bootbank_lpfc_12.8.298.3-2vmw.702.0.20.18426014
          • VMW_bootbank_vmkusb_0.1-4vmw.702.0.20.18426014
          PR résolus 2717698, 2731446, 2515171, 731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408, 2722263, 2812906, 2750390, 2715138, 2753546
          Numéros CVE associés S/O

          Ce correctif met à jour les problèmes suivants :

            • Une condition de concurrence rare dans le pilote qedentv peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet. Ce problème survient lorsqu'une interruption complète de Rx se produit juste après la destruction d'une paire de files d'attente (QP) de l'interface des services généraux (GSI), par exemple lors du déchargement d'un pilote qedentv ou de l'arrêt d'un système. Dans ce cas, le pilote qedentv peut accéder à une adresse de QP déjà libérée, ce qui entraîne une exception PF. Ce problème peut se produire sur les hôtes ESXi connectés à un commutateur physique occupé avec un trafic GSI non sollicité intense. Dans la trace de débogage, vous voyez des messages tels que :

              cpu4:2107287)0x45389609bcb0:[0x42001d3e6f72]qedrntv_ll2_rx_cb@(qedrntv)#<None>+0x1be stack: 0x45b8f00a7740, 0x1e146d040, 0x432d65738d40, 0x0, 0x
              2021-02-11T03:31:53.882Z cpu4:2107287)0x45389609bd50:[0x42001d421d2a]ecore_ll2_rxq_completion@(qedrntv)#<None>+0x2ab stack: 0x432bc20020ed, 0x4c1e74ef0, 0x432bc2002000,
              2021-02-11T03:31:53.967Z cpu4:2107287)0x45389609bdf0:[0x42001d1296d0]ecore_int_sp_dpc@(qedentv)#<None>+0x331 stack: 0x0, 0x42001c3bfb6b, 0x76f1e5c0, 0x2000097, 0x14c2002
              2021-02-11T03:31:54.039Z cpu4:2107287)0x45389609be60:[0x42001c0db867]IntrCookieBH@vmkernel#nover+0x17c stack: 0x45389609be80, 0x40992f09ba, 0x43007a436690, 0x43007a43669
              2021-02-11T03:31:54.116Z cpu4:2107287)0x45389609bef0:[0x42001c0be6b0]BH_Check@vmkernel#nover+0x121 stack: 0x98ba, 0x33e72f6f6e20, 0x0, 0x8000000000000000, 0x430000000001
              2021-02-11T03:31:54.187Z cpu4:2107287)0x45389609bf70:[0x42001c28370c]NetPollWorldCallback@vmkernel#nover+0x129 stack: 0x61, 0x42001d0e0000, 0x42001c283770, 0x0, 0x0
              2021-02-11T03:31:54.256Z cpu4:2107287)0x45389609bfe0:[0x42001c380bad]CpuSched_StartWorld@vmkernel#nover+0x86 stack: 0x0, 0x42001c0c2b44, 0x0, 0x0, 0x0
              2021-02-11T03:31:54.319Z cpu4:2107287)0x45389609c000:[0x42001c0c2b43]Debug_IsInitialized@vmkernel#nover+0xc stack: 0x0, 0x0, 0x0, 0x0, 0x0
              2021-02-11T03:31:54.424Z cpu4:2107287)^[[45m^[[33;1mVMware ESXi 7.0.2 [Releasebuild-17435195 x86_64]^[[0m
              #PF Exception 14 in world 2107287:vmnic7-pollW IP 0x42001d3e6f72 addr 0x1c

            • Dans de rares cas, lorsque le dispositif vSphere Replication se met sous tension, le service hostd peut échouer et provoquer l'absence temporaire de réponse des hôtes ESXi auprès du système vCenter Server. Le service hostd redémarre automatiquement et la connectivité est rétablie.

            • Lorsque vous tentez de définir une valeur sur false pour un paramètre d'option avancée dans un profil d'hôte, l'interface utilisateur crée une valeur de chaîne non vide. Les valeurs qui ne sont pas vides sont interprétées comme true et le paramètre d'option avancée reçoit une valeur true dans le profil d'hôte.

            • Les hôtes ESXi peuvent cesser de répondre à l'instance de vCenter Server même lorsque les hôtes sont accessibles et en cours d'exécution. Ce problème se produit dans les images fournisseur avec des pilotes personnalisés où ImageConfigManager consomme plus de RAM que celle allouée. Par conséquent, les échecs répétés de ImageConfigManager entraînent la déconnexion des hôtes ESXi de l'instance de vCenter Server.
              Dans les journaux vmkernel, vous voyez des erreurs répétées telles que :
              Admission failure in path: host/vim/vmvisor/hostd-tmp/sh.<pid1>:python.<pid2>:uw.<pid2>.
              Dans les journaux hostd vous voyez des messages tels que : Task Created : haTask-ha-host-vim.host.ImageConfigManager.fetchSoftwarePackages-<sequence> suivi de : ForkExec(/usr/bin/sh) <pid1>, où <pid1> identifie une procédure ImageConfigManager.

            • Si vous modifiez l'option de configuration avancée DiskMaxIOSize par une valeur inférieure, les E/S avec des blocs de grande taille peuvent être fractionnées et mises en file d'attente de manière incorrecte sur le chemin PSA. Par conséquent, les opérations d'E/S des hôtes ESXi peuvent expirer et échouer.

            • Dans certaines conditions, les opérations de mise sous tension ou hors tension des machines virtuelles peuvent prendre jusqu'à 20 minutes. Ce problème se produit lorsque le stockage sous-jacent des machines virtuelles exécute une opération en arrière-plan, telle que des événements de réanalyse HBA ou APD, et que certains verrous sont maintenus en permanence.

            • Dans de rares cas, lorsque la taille de réponse de la page VPD de l'hôte ESXi cible est différente sur des chemins différents de l'hôte, ESXi peut écrire plus d'octets que la longueur allouée pour un chemin donné. Par conséquent, l'hôte ESXi échoue avec un écran de diagnostic violet avec un message tel que :
              Panic Message: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4878 - Corruption in dlmalloc

            • Une contention de verrouillage rare peut entraîner l'échec d'opérations de machine virtuelle telles que le basculement ou la migration.
              Les messages d'échec de verrouillage sont semblables à :
              vol 'VM_SYS_11', lock at 480321536: [Req mode 1] Checking liveness:
              type 10c00003 offset 480321536 v 1940464, hb offset 3801088
              ou
              Res3: 2496: Rank violation threshold reached: cid 0xc1d00002, resType 2, cnum 5 vol VM_SYS_11

            • Dans les workflows compliqués qui entraînent la création de plusieurs machines virtuelles, lorsque vous accédez à VM > Machines virtuelles, vous pouvez voir des nombres importants dans la colonne Espace provisionné pour certaines machines virtuelles. Par exemple, 2,95 To au lieu de l'espace provisionné réel de 25 Go.

            • Lors du traitement de la commande SCSI READ CAPACITY (10), ESXi peut copier des données excessives de la réponse et endommager la pile d'appels. Par conséquent, l'hôte ESXi échoue avec un écran de diagnostic violet.

            • Dans de très rares cas, les clusters de ressources VMFS inclus dans une transaction de journal peuvent ne pas être verrouillés. Par conséquent, lors de la mise sous tension des machines virtuelles, plusieurs hôtes ESXi peuvent échouer avec un écran de diagnostic violet en raison de l'exception 14 dans la couche VMFS. Un message et une trace de pile typiques visibles dans le journal vmkernel sont les suivants :
              @BlueScreen: #PF Exception 14 in world 2097684:VSCSI Emulat IP 0x418014d06fca addr 0x0
              PTEs:0x16a47a027;0x600faa8007;0x0;
              2020-06-24T17:35:57.073Z cpu29:2097684)Code start: 0x418013c00000 VMK uptime: 0:01:01:20.555
              2020-06-24T17:35:57.073Z cpu29:2097684)0x451a50a1baa0:[0x418014d06fca]Res6MemUnlockTxnRCList@esx#nover+0x176 stack: 0x1 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb10:[0x418014c7cdb6]J3_DeleteTransaction@esx#nover+0x33f stack: 0xbad0003
              2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb40:[0x418014c7db10]J3_AbortTransaction@esx#nover+0x105 stack: 0x0 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb80:[0x418014cbb752]Fil3_FinalizePunchFileHoleTxnVMFS6@esx#nover+0x16f stack: 0x430fe950e1f0
              2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bbd0:[0x418014c7252b]Fil3UpdateBlocks@esx#nover+0x348 stack: 0x451a50a1bc78 2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bce0:[0x418014c731dc]Fil3_PunchFileHoleWithRetry@esx#nover+0x89 stack: 0x451a50a1bec8
              2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bd90:[0x418014c739a5]Fil3_FileBlockUnmap@esx#nover+0x50e stack: 0x230eb5 2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be40:[0x418013c4c551]FSSVec_FileBlockUnmap@vmkernel#nover+0x6e stack: 0x230eb5
              2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be90:[0x418013fb87b1]VSCSI_ExecFSSUnmap@vmkernel#nover+0x8e stack: 0x0 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf00:[0x418013fb71cb]VSCSIDoEmulHelperIO@vmkernel#nover+0x2c stack: 0x430145fbe070
              2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf30:[0x418013ceadfa]HelperQueueFunc@vmkernel#nover+0x157 stack: 0x430aa05c9618 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bfe0:[0x418013f0eaa2]CpuSched_StartWorld@vmkernel#nover+0x77 stack: 0x0
              2020-06-24T17:35:57.083Z cpu29:2097684)base fs=0x0 gs=0x418047400000 Kgs=0x0

            • Dans de rares cas, certains CPU Intel peuvent ne pas parvenir à transférer des interruptions #DB et si une interruption de temporisateur se produit lors de l'appel système Windows, cela peut entraîner une triple panne de la machine virtuelle.

            • Si vous redémarrez les agents de gestion ESXi depuis DCUI, le service sfcbd ne démarre pas. Vous devez démarrer manuellement le service SFCB.

            • Le service hostd enregistre le message BuildPowerSuplySensorList a trouvé 0 capteur d'alimentation toutes les 2 minutes. Ce problème se produit lorsque vous effectuez une mise à niveau vers ESXi 7.0 Update 1 ou une nouvelle installation de cette version sur un hôte ESXi.

            • Dans de rares cas, l'allocateur de mémoire du noyau peut renvoyer un pointeur NULL qui peut ne pas être correctement déréférencé. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet avec une erreur telle que #GP Exception 13 in world 2422594:vmm:overCom @ 0x42003091ede4. Dans la trace de débogage, vous voyez des messages semblables à :
              #1 Util_ZeroPageTable
              #2 Util_ZeroPageTableMPN
              #3 VmMemPfUnmapped
              #4 VmMemPfInt
              #5 VmMemPfGetMapping
              #6 VmMemPf
              #7 VmMemPfLockPageInt
              #8 VMMVMKCall_Call
              #9 VMKVMM_ArchEnterVMKernel

            • Si un périphérique NVMe est ajouté à chaud et supprimé à chaud dans un court intervalle de temps, le pilote NVMe peut ne pas initialiser le contrôleur NVMe en raison d'une expiration du délai de la commande. Par conséquent, le pilote peut accéder à la mémoire déjà libérée lors d'un processus de nettoyage. Dans la trace de débogage, l'écran affiche un message de type AVERTISSEMENT : NVMEDEV: NVMEInitializeController:4045: Échec de l'obtention des données d'identité du contrôleur, état : Expiration du délai.
              Finalement, l'hôte ESXi peut échouer avec un écran de diagnostic violet et une erreur de type #PF Exception ... in world ...:vmkdevmgr.

            • Lorsqu'un hôte ESXi n'a pas de blocs de fichiers volumineux (LFB) disponibles à allouer, l'hôte effectue le provisionnement statique du VMDK ou la création d'un fichier d'échange avec de petits blocs de fichiers (SFB). Cependant, dans de rares cas, l'hôte peut également ne pas parvenir à allouer des SFB. Par conséquent, le provisionnement statique de VMDK ou la création d'un fichier d'échange échoue. Lorsque des machines virtuelles tentent de se mettre sous tension, une erreur dans les journaux vmkernel s'affiche, telle que :
               vmkernel.1:2021-01-08T19:13:28.341Z cpu20:2965260)Fil3: 10269 : Le nombre maximal de tentatives de suppression d'espace (10) a été dépassé pour l'appelant Fil3_SetFileLength de l'appelant (état « Aucun espace restant sur le périphérique »)

            • Lorsque vous utilisez des banques de données VMFS6 très volumineuses, le processus d'allocation de blocs de fichiers pour des VMDK dynamiques dans un cluster de ressources peut entraîner un verrouillage de CPU. Par conséquent, vous voyez des messages de verrouillage de CPU et, dans de rares cas, les hôtes ESXi peuvent échouer. Dans la trace de débogage, vous voyez des messages tels que :
              2021-04-07T02:18:08.730Z cpu31:2345212)WARNING: Heartbeat: 849 : PCPU 10 didn't have a heartbeat for 7 seconds; *may* be locked up.
              La trace de débogage associée impliquant les fonctions Res6AffMgr ressemble à ce qui :
              2021-01-06T02:16:16.073Z cpu0:2265741)ALERT: NMI: 694: NMI IPI: RIPOFF(base):RBP:CS [0x121d74d(0x42001a000000):0x50d0:0xf48] (Src 0x1, CPU0)
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b320:[0x42001b21d74c]Res6AffMgrComputeSortIndices@esx#nover+0x369 stack: 0x43119125a000
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b3b0:[0x42001b224e46]Res6AffMgrGetCluster@esx#nover+0xb1f stack: 0xd 2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b4b0:[0x42001b226491]Res6AffMgr_AllocResourcesInt@esx#nover+0x40a stack: 0x4311910f4890
              2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b680:[0x42001b2270e2]Res6AffMgr_AllocResources@esx#nover+0x1b stack: 0x0

            • Pendant ou après une mise à niveau vers ESXi 7.0 Update 2, la couche de stockage ESX peut ne pas allouer suffisamment de ressources mémoire pour les hôtes ESXi disposant d'un nombre important de CPU physiques et de nombreux périphériques ou chemins de stockage connectés aux hôtes. Par conséquent, ces hôtes ESXi peuvent échouer avec un écran de diagnostic violet.

            • Les machines virtuelles disposant de la version de matériel 18 et de VMware Tools 11.2.0 ou version ultérieure peuvent échouer en raison d'un problème de périphérique graphique virtuel côté destination lors d'une opération vSphere vMotion ou Storage vMotion.
              Dans le fichier vmkernel.log vous voyez une ligne telle que :
              PF failed to handle a fault on mmInfo at va 0x114f5ae0: Out of memory. Terminating...

            • Après la mise à jour vers la version de matériel 18, certains SE invités, tels que CentOS 7, sur des CPU AMD peuvent échouer avec une alerte de noyau lorsque vous démarrez la machine virtuelle. Le message d'alerte de noyau s'affiche lorsque vous ouvrez une console Web pour la machine virtuelle.

            • Certains noyaux Linux ajoutent l'option Limite d'encapsulation de tunnel IPv6 aux paquets de tunnel IPv6 comme décrit dans RFC 2473, par. 5.1. Par conséquent, les paquets de tunnel IPv6 sont abandonnés dans le trafic entre les machines virtuelles, en raison de l'en-tête d'extension IPv6.

            • Lorsque des supports virtuels, tels qu'un lecteur CD, sont connectés à votre environnement vSphere à l'aide d'un contrôleur iDRAC (Integrated Dell Remote Access Controller) et qu'aucun fichier de support n'est mappé au lecteur, le journal vmkernel peut afficher plusieurs messages d'avertissement tels que :
              vmw_psp_fixed: psp_fixedSelectPathToActivateInt:439: Switching to preferred path vmhba32:C0:T0:L1 in STANDBY state for device mpx.vmhba32:C0:T0:L1.WARNING: vmw_psp_fixed: psp_fixedSelectPathToActivateInt:464: Selected current STANDBY path vmhba32:C0:T0:L1 for device mpx.vmhba32:C0:T0:L1 to activate. This may lead to path thrashing.

            • Pendant les workflows de synchronisation de 24 heures du vSphere Distributed Switch, l'instance de vCenter Server peut supprimer par intermittence les ports virtuels distribués contrôlés par NSX, tels que le port SPF (Service Plane Forwarding), des hôtes ESXi. Par conséquent, les opérations vSphere vMotion de machines virtuelles peuvent échouer. Vous voyez une erreur telle que Could not connect SPF port : Not Found dans les journaux.

            • ESXi 7.0 a introduit la partition ESX-OSData basée sur VMFS-L, qui joue le rôle de partition de travail, de partition de casier pour VMware Tools et de destination de vidage de mémoire. Si vous configurez la partition de travail sur le répertoire racine d'un volume VMFS lors d'une mise à niveau vers ESXi 7.0.x, le système tente de convertir les fichiers VMFS au format VMFS-L pour répondre aux exigences de partition OS-Data. Par conséquent, la partition OS-Data peut écraser le volume VMFS et provoquer une perte de données.

            • En raison d'un problème de gestion des journaux, après une mise à niveau vers ESXi 7.0 Update 2a, lorsque vous vérifiez l'état de santé du canal de communication, vous voyez tous les hôtes ESXi dont l'état est inactif, car NSX Manager ne parvient pas à se connecter à l'agent de pare-feu.

            • Si un hôte ESXi version 7.0 Update 2 est installé sur un LUN FCoE et utilise le mode de démarrage UEFI, lorsque vous tentez de mettre à niveau l'hôte à l'aide de vSphere QuickBoot, le serveur physique peut échouer avec un écran de diagnostic violet en raison d'une erreur de mémoire.

            • Les périphériques USB ont une petite profondeur de file d'attente et, en raison d'une condition de concurrence dans la pile de stockage ESXi, certaines opérations d'E/S peuvent ne pas atteindre le périphérique. Ces E/S sont mises en file d'attente dans la pile de stockage ESXi et finissent par expirer. Par conséquent, les hôtes ESXi cessent de répondre.
              Dans vSphere Client, vous voyez des alertes telles que Alerte : /bootbank introuvable dans le chemin « /bootbank » et L'hôte ne répond pas.
              Dans les journaux vmkernel.*, vous voyez des erreurs telles que :
              2021-04-12T04:47:44.940Z cpu0:2097441)ScsiPath: 8058: Cancelled Cmd(0x45b92ea3fd40) 0xa0, cmdId.initiator=0x4538c859b8f8 CmdSN 0x0 from world 0 to path "vmhba32:C0:T0:L0". Cmd count Active:0 Queued:1.
              2021-04-12T04:48:50.527Z cpu2:2097440)ScsiDeviceIO: 4315: Cmd(0x45b92ea76d40) 0x28, cmdId.initiator=0x4305f74cc780 CmdSN 0x1279 from world 2099370 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x5 D:0x0 P:0x0 Cancelled from path layer. Cmd count Active:1
              2021-04-12T04:48:50.527Z cpu2:2097440)Queued:4

            • Vous pouvez observer un ralentissement allant jusqu'à 60 minutes dans le délai de démarrage des hôtes ESXi après une mise à niveau vers ESXi Update 2a.
              Ce problème n'affecte pas les mises à jour ESXi Update 2a à partir de versions antérieures à ESXi 7.0.x.
              Ce problème se produit uniquement lorsque vous utilisez une image vSphere Lifecycle Manager, une ligne de base ou la commande esxcli software profile update pour effectuer l'opération de mise à niveau. Si vous utilisez une image ISO ou une installation basée sur un script, vous ne rencontrez pas ce problème.
              Ce problème est plus susceptible d'affecter les configurations iSCSI, mais il est lié à l'algorithme d'ESXi pour la détection de la banque de démarrage, et non au ralentissement des cibles de stockage externes.

            • En raison d'une fuite de mémoire dans le segment de mémoire de l'ensemble de ports, les opérations vSphere vMotion sur un hôte ESXi peuvent échouer et afficher une erreur de mémoire insuffisante. Dans vSphere Client, vous voyez une erreur telle que :
              Échec de réservation du port : DVSwitch 50 18 34 d1 76 81 ec 9e-03 62 e2 d4 6f 23 30 ba port 1 39.
              Échec avec l'état d'erreur : Mémoire insuffisante.

            • Si l'instance de vCenter Server ne peut pas résoudre vcsa.vmware.com en une adresse IP, le catalogue de versions vSAN ne peut pas être téléchargé. Le contrôle de santé vSAN suivant affiche un avertissement : santé du moteur de recommandations de build vSAN.
              Un message d'erreur similaire au message suivant peut s'afficher :
              2021-04-12T11:40:59.435Z ERROR vsan-mgmt[32221] [VsanHttpRequestWrapper::urlopen opID=noOpId] Exception while sending request : Cannot resolve localhost or Internet websites.
              2021-04-12T11:40:59.435Z WARNING vsan-mgmt[32221] [VsanVumCoreUtil::CheckVumServiceStatus opID=noOpId] Failed to connect VUM service: Cannot resolve localhost or Internet websites.
              2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumIntegration::VumStatusCallback opID=noOpId] VUM is not installed or not responsive ​
              2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumSystemUtil::HasConfigIssue opID=noOpId] Config issue health.test.vum.vumDisabled exists on entity None

            • Un bogue de dépassement de capacité d'entier peut amener vSAN DOM à émettre des nettoyages plus fréquemment que le paramètre configuré.

            • Lorsqu'une resynchronisation s'exécute en parallèle avec des écritures d'invité sur des objets appartenant à un hôte ESXi, l'hôte peut échouer avec un écran de diagnostic violet.

            • Lorsque le fichier cmmdstimemachineDump.log atteint une limite maximale de 10 Mo, la rotation se produit et un nouveau fichier cmmdstimemachineDump est créé. Cependant, pendant la rotation, dans les journaux vmsyslogd.err, vous pouvez voir une erreur telle que :
              2021-04-08T03:15:53.719Z vmsyslog.loggers.file : ERROR ] Failed to write header on rotate. Exception: [Errno 2] No such file or directory: '/var/run/cmmdstimemachineDumpHeader.txt'

            • Dans certains cas, la surveillance du cluster, l'appartenance et le service d'annuaire (CMMDS) ne fournissent pas une entrée correcte à la tâche Modification du format d'objet et la tâche prend beaucoup de temps à répondre.

            • Dans de rares cas, si l'hôte témoin est remplacé pendant le processus de mise à niveau et qu'une tâche de conversion du format de disque s'exécute peu après le remplacement, plusieurs hôtes ESX sur un cluster étendu peuvent échouer avec un écran de diagnostic violet.

            • Si vous créez une image personnalisée de version 7.0 Update 2a à l'aide du kit de modularisation ESXi, remplacez certains composants dans l'image de base, par exemple Intel-ixgben:1.8.9.0-1OEM.700.1.0.15525992, puis mettez à niveau vos hôtes ESXi 7.0.x, vous ne pouvez pas supprimer le composant personnalisé après la mise à niveau. En outre, certains VIB des composants personnalisés peuvent être manquants.

            • Lorsque vous clonez un périphérique de démarrage ESXi, vous créez des instances avec des UUID identiques. Comme les UUID sont utilisés pour les opérations de signal de pulsation et de journal VMFS, lorsque vous avez dupliqué l'UUIDS, après les opérations d'installation ou de mise à niveau, plusieurs hôtes ESXi tentent d'accéder aux régions de métadonnées sur la même banque de données VMFS. Par conséquent, vous pouvez voir une corruption massive des métadonnées dans les banques de données VMFS sur plusieurs hôtes ESXi.
              Dans les journaux vmkernel vous voyez des messages tels que :
              vmkernel 608: VMFS volume DCS_HCFA_TEDS_Regulated_10032/5ba2905b-ac11166d-b145-0025b5920a02 on naa.60060e8012a34f005040a34f00000d64:1 has been detected corrupted.
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 319: FS3RCMeta 2245 200 21 105 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 326: 0 0 0 0 0 0 0 0 0 0 0 7 0 254 1 4 0 248 3 96 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 332: 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 338: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
              2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

            • À partir de vSphere 7.0 Update 2, le nom du pilote i40en de la boîte de réception a été remplacé par i40enu. Par conséquent, si vous tentez d'installer un pilote asynchrone de partenaire i40en, le VIB i40en est ignoré ou restauré vers le pilote de la boîte de réception VMware i40enu.

            • Une erreur rare de Défaut de page peut entraîner l'échec des hôtes ESXi avec un écran de diagnostic violet lors de l'installation du plug-in Dell EMC PowerPath.

            • Si le contrôleur hôte USB se déconnecte de votre système vSphere et qu'une ressource sur le périphérique, telle que les fichiers de vidage mémoire, est toujours utilisée par ESXi, le chemin du périphérique ne peut pas être libéré avant la reconnexion du périphérique. Par conséquent, ESXi fournit un nouveau chemin d'accès au périphérique USB, ce qui interrompt la connexion à la partition /bootbank ou endommage la partition VMFS-L LOCKER.

          ESXi-7.0U2sc-18295176-standard
          Nom du profil ESXi-7.0U2sc-18295176-standard
          Build Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.
          Fournisseur VMware, Inc.
          Date de publication 24 août 2021
          Niveau d'acceptation PartnerSupported
          Matériel concerné S.O.
          Logiciels concernés S.O.
          VIB concernés
          • VMware_bootbank_vdfs_7.0.2-0.15.18295176
          • VMware_bootbank_esx-xserver_7.0.2-0.15.18295176
          • VMware_bootbank_esx-base_7.0.2-0.15.18295176
          • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.15.18295176
          • VMware_bootbank_crx_7.0.2-0.15.18295176
          • VMware_bootbank_native-misc-drivers_7.0.2-0.15.18295176
          • VMware_bootbank_cpu-microcode_7.0.2-0.15.18295176
          • VMware_bootbank_gc_7.0.2-0.15.18295176
          • VMware_bootbank_vsanhealth_7.0.2-0.15.18295176
          • VMware_bootbank_clusterstore_7.0.2-0.15.18295176
          • VMware_bootbank_vsan_7.0.2-0.15.18295176
          • VMware_bootbank_loadesx_7.0.2-0.15.18295176
          • VMware_bootbank_esx-update_7.0.2-0.15.18295176
          • VMware_locker_tools-light_11.2.6.17901274-18295176
          • VMW_bootbank_vmkusb_0.1-1vmw.702.0.15.18295176
          PR résolus 2738816, 2738857, 2735594, 2761942
          Numéros CVE associés S/O

          Ce correctif met à jour les problèmes suivants :

            • OpenSSH a été mis à jour vers la version 8.5p1.

            • La bibliothèque OpenSSL a été mise à jour vers la version openssl-1.0.2y.

            • La bibliothèque Libarchive a été mise à jour vers la version 3.5.1.

            • Les images ISO de VMware Tools 11.2.6 suivantes sont fournies avec ESXi :

              • windows.iso: Image de VMware Tools pour Windows 7 SP1 ou Windows Server 2008 R2 SP1 ou version ultérieure
              • linux.iso: Image de VMware Tools 10.3.23 pour les versions plus anciennes de Linux OS avec glibc 2.5 ou version ultérieure

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

              • solaris.iso: Image de VMware Tools pour Solaris
              • darwin.iso: Image de VMware Tools pour les versions Mac OS X 10.11 et ultérieures.

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

          ESXi-7.0U2sc-18295176-no-tools
          Nom du profil ESXi-7.0U2sc-18295176-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 24 août 2021
          Niveau d'acceptation PartnerSupported
          Matériel concerné S.O.
          Logiciels concernés S.O.
          VIB concernés
          • VMware_bootbank_vdfs_7.0.2-0.15.18295176
          • VMware_bootbank_esx-xserver_7.0.2-0.15.18295176
          • VMware_bootbank_esx-base_7.0.2-0.15.18295176
          • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.15.18295176
          • VMware_bootbank_crx_7.0.2-0.15.18295176
          • VMware_bootbank_native-misc-drivers_7.0.2-0.15.18295176
          • VMware_bootbank_cpu-microcode_7.0.2-0.15.18295176
          • VMware_bootbank_gc_7.0.2-0.15.18295176
          • VMware_bootbank_vsanhealth_7.0.2-0.15.18295176
          • VMware_bootbank_clusterstore_7.0.2-0.15.18295176
          • VMware_bootbank_vsan_7.0.2-0.15.18295176
          • VMware_bootbank_loadesx_7.0.2-0.15.18295176
          • VMware_bootbank_esx-update_7.0.2-0.15.18295176
          • VMware_locker_tools-light_11.2.6.17901274-18295176
          • VMW_bootbank_vmkusb_0.1-1vmw.702.0.15.18295176
          PR résolus 2738816, 2738857, 2735594, 2761942
          Numéros CVE associés S/O

          Ce correctif met à jour les problèmes suivants :

            • OpenSSH a été mis à jour vers la version 8.5p1.

            • La bibliothèque OpenSSL a été mise à jour vers la version openssl-1.0.2y.

            • La bibliothèque Libarchive a été mise à jour vers la version 3.5.1.

            • Les images ISO de VMware Tools 11.2.6 suivantes sont fournies avec ESXi :

              • windows.iso: Image de VMware Tools pour Windows 7 SP1 ou Windows Server 2008 R2 SP1 ou version ultérieure
              • linux.iso: Image de VMware Tools 10.3.23 pour les versions plus anciennes de Linux OS avec glibc 2.5 ou version ultérieure

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

              • solaris.iso: Image de VMware Tools pour Solaris
              • darwin.iso: Image de VMware Tools pour les versions Mac OS X 10.11 et ultérieures.

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

          Image ESXi - ESXi70U2c-18426014
          Nom ESXi
          Version ESXi70U2c-18426014
          Date de publication 24 août 2020
          Catégorie Correctif de bogues
          Composants concernés
          • Composant ESXi - VIB ESXi principaux
          • Pilote Emulex FC
          • Pilotes Broadcom NetXtreme-E Network et ROCE/RDMA pour VMware ESXi
          • Pilotes QLogic FastLinQ 10/25/40/50/100 GbE Ethernet et RoCE/RDMA pour VMware ESXi
          • Composant d'installation/mise à niveau d'ESXi
          • Pilote réseau pour les adaptateurs Intel(R) X710/XL710/XXV710/X722
          • Pilote USB
          PR résolus  2717698, 2731446, 2515171, 731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408, 2722263, 2812906, 2750390, 2715138, 2753546
          Numéros CVE associés S/O
            Image ESXi - ESXi70U2sc-18295176
            Nom ESXi
            Version ESXi70U2sc-18295176
            Date de publication 24 août 2020
            Catégorie Sécurité
            Composants concernés
            • Composant ESXi - VIB ESXi principaux
            • Pilote USB
            • Composant ESXi Tools
            • Composant d'installation/mise à niveau d'ESXi
            PR résolus  2738816, 2738857, 2735594, 2761942
            Numéros CVE associés S/O

              Problèmes connus

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

              Problèmes divers
              • Le démon sensord ne parvient pas à signaler l'état du matériel de l'hôte ESXi

                Une erreur logique dans la validation du SDR IPMI peut empêcher sensord d'identifier une source pour les informations d'alimentation. Par conséquent, lorsque vous exécutez la commande vsish -e get /power/hostStats, il se peut que vous ne voyiez aucune sortie.

                Solution : aucune.

              Problèmes d'installation, de mise à niveau et de migration
              • Les hôtes ESXi peuvent perdre la connectivité après la mise à niveau du pilote brcmfcoe sur les baies de stockage Hitachi

                Après une mise à niveau du pilote brcmfcoe sur des baies de stockage Hitachi, les hôtes ESXi peuvent ne pas démarrer et perdre la connectivité.

                Solution : aucune.

              Problèmes connus des versions antérieures

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

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