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
• Versions antérieures d'ESXi 7.0
• Correctifs contenus dans cette version
• Remarques relatives à la prise en charge du produit
• Problèmes résolus
• Problèmes connus

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 :

• VMware ESXi 7.0, version de correctif ESXi 7.0 Update 2a
• VMware ESXi 7.0, version de correctif ESXi 7.0 Update 2
• VMware ESXi 7.0, version de correctif ESXi 7.0 Update 1d
• VMware ESXi 7.0, version de correctif ESXi 7.0 Update 1c
• VMware ESXi 7.0, version de correctif ESXi 7.0 Update 1b
• VMware ESXi 7.0, version de correctif ESXi 7.0 Update 1a
• VMware ESXi 7.0, version de correctif ESXi 7.0 Update 1
• VMware ESXi 7.0, Patch Release ESXi 7.0b

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
• esx-update_7.0.2-0.20.18426014
• Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.702.0.20.18426014
• MRVL-E4-CNA-Driver-Bundle_1.0.0.0-1vmw.702.0.20.18426014
• Intel-i40en_1.8.1.137-1vmw.702.0.20.18426014
• Broadcom-ELX-lpfc_12.8.298.3-2vmw.702.0.20.18426014
• VMware-vmkusb_0.1-4vmw.702.0.20.18426014
• ESXi_7.0.2-0.15.18295176
• esx-update_7.0.2-0.15.18295176
• VMware-VM-Tools_11.2.6.17901274-18295176
• VMware-vmkusb_0.1-1vmw.702.0.15.18295176
• ESXi-7.0U2c-18426014-standard
• ESXi-7.0U2c-18426014-no-tools
• ESXi-7.0U2sc-18295176-standard
• ESXi-7.0U2sc-18295176-no-tools
• Image ESXi - ESXi70U2c-18426014
• Image ESXi - ESXi70U2sc-18295176

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 :

• 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 :

  • Notes de mise à jour de VMware Tools 11.2.6
  • Ce que chaque administrateur vSphere doit savoir sur VMware Tools
  • VMware Tools pour les hôtes provisionnés avec Auto Deploy
  • Mise à jour de VMware Tools

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 :

    • Notes de mise à jour de VMware Tools 11.2.6
    • Ce que chaque administrateur vSphere doit savoir sur VMware Tools
    • VMware Tools pour les hôtes provisionnés avec Auto Deploy
    • Mise à jour de VMware Tools

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 :

    • Notes de mise à jour de VMware Tools 11.2.6
    • Ce que chaque administrateur vSphere doit savoir sur VMware Tools
    • VMware Tools pour les hôtes provisionnés avec Auto Deploy
    • Mise à jour de VMware Tools

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
• Problèmes d'installation, de mise à niveau et de migration
• Problèmes connus affectant les versions antérieures

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.

Les problèmes connus des versions antérieures sont classés comme suit :

• Problèmes de vSAN
• Problèmes d'installation, de mise à niveau et de migration
• Problèmes liés aux fonctionnalités de sécurité
• Problèmes de mise en réseau
• Problèmes de stockage
• Problèmes vCenter Server et vSphere Client
• Problèmes de gestion des machines virtuelles
• Problèmes de vSphere HA et Fault Tolerance
• Problèmes liés à vSphere Lifecycle Manager
• Problèmes divers

Problèmes de vSAN

• Si vous modifiez le site préféré dans un cluster étendu VMware vSAN, certains objets peuvent apparaître par erreur comme conformes

  Si vous modifiez le site préféré dans un cluster étendu, certains objets peuvent apparaître par erreur comme conformes, car leurs paramètres de stratégie peuvent ne pas changer automatiquement. Par exemple, si vous configurez une machine virtuelle pour qu'elle conserve les données sur le site préféré, lorsque vous modifiez le site préféré, les données peuvent demeurer sur le site qui n'est pas préféré.

  Solution : avant de modifier un site préféré, dans les paramètres avancés, diminuez la valeur ClomMaxCrawlCycleMinutes pour la ramener à 15 minutes afin de vous assurer que les stratégies d'objets sont mises à jour. Après la modification, restaurez la valeur antérieure de l'option ClomMaxCrawlCycleMinutes.

Problèmes d'installation, de mise à niveau et de migration

• Les vérifications préalables de la mise à niveau ou de la migration vCenter échouent avec « erreur inattendue 87 ».

  Les vérifications préalables de la mise à niveau ou de la migration de vCenter Server échouent lorsque le certificat du service de jetons de sécurité (STS) ne contient pas de champ Nom alternatif du sujet (SAN). Cette situation se produit lorsque vous avez remplacé le certificat vCenter 5.5 Single Sign-On par un certificat personnalisé sans champ SAN et que vous tentez d'effectuer la mise à niveau vers vCenter Server 7.0. La mise à niveau considère que le certificat STS n'est pas valide et les vérifications préalables empêchent le processus de mise à niveau de se poursuivre.

  Solution : remplacez le certificat STS par un certificat valide qui contient un champ SAN, puis procédez à la mise à niveau ou à la migration de vCenter Server 7.0.

• Problèmes de mise à niveau vers vSphere 7.0 avec des fournisseurs CIM préexistants.

  Après la mise à niveau, les fournisseurs CIM 32 bits précédemment installés cessent de fonctionner, car ESXi requiert des fournisseurs CIM 64 bits. Les clients peuvent perdre des fonctions d'API de gestion liées à CIMPDK, NDDK (DDK natif), HEXDK, VAIODK (filtres d'E/S) et des erreurs liées à la dépendance uwglibc peuvent s'afficher.
  Le Syslog indique qu'un module est manquant, « bibliothèques 32 bits partagées non chargées ».

  Solution : il n'existe pas de solution. Le correctif consiste à télécharger les nouveaux fournisseurs CIM 64 bits à partir de votre fournisseur.

• L'installation des pilotes 7.0 Update 1 sur les hôtes ESXi 7.0 peut échouer

  Vous ne pouvez pas installer les pilotes applicables à ESXi 7.0 Update 1 sur les hôtes qui exécutent ESXi 7.0 ou 7.0b.
  L'opération échoue avec une erreur, telle que :
  VMW_bootbank_qedrntv_3.40.4.0-12vmw.701.0.0.xxxxxxx requires vmkapi_2_7_0_0, but the requirement cannot be satisfied within the ImageProfile. ​
Consultez le fichier journal pour plus de détails.

  Solution : mettez à jour l'hôte ESXi vers la version 7.0 Update 1. Relancez l'installation du pilote.

• Le démarrage UEFI des hôtes ESXi peut s'arrêter avec une erreur lors d'une mise à jour vers ESXi 7.0 Update 2 à partir d'une version antérieure d'ESXi 7.0

  Si vous tentez de mettre à jour votre environnement vers la version 7.0 Update 2 à partir d'une version antérieure d'ESXi 7.0 à l'aide de lignes de base de correctifs vSphere Lifecycle Manager, le démarrage UEFI des hôtes ESXi peut s'arrêter avec une erreur telle que :
  Loading /boot.cfg
Failed to load crypto64.efi
Fatal error : 15 (Not found)

  Solution : pour plus d'informations, reportez-vous aux articles 83063 et 83107 de la base de connaissances VMware.

• Si des VIB hérités sont utilisés sur un hôte ESXi, vSphere Lifecycle Manager ne peut pas extraire une spécification logicielle souhaitée pour les amorçages vers un nouveau cluster

  vCenter Server 7.0 Update 2 vous permet de créer un cluster en important la spécification logicielle souhaitée à partir d'un hôte de référence unique.  Cependant, si des VIB hérités sont utilisés sur un hôte ESXi, vSphere Lifecycle Manager ne peut pas extraire une spécification logicielle de référence à partir de cet hôte dans l'instance de vCenter Server dans laquelle vous créez le cluster. Dans le fichier /var/log/lifecycle.log, vous voyez des messages tels que :
  020-11-11T06:54:03Z lifecycle: 1000082644: HostSeeding:499 ERROR Extract depot failed: Checksum doesn't match. Calculated 5b404e28e83b1387841bb417da93c8c796ef2497c8af0f79583fd54e789d8826, expected: 0947542e30b794c721e21fb595f1851b247711d0619c55489a6a8cae6675e796 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:366 ERROR Extract depot failed. 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:145 ERROR [VibChecksumError]

  Solution : suivez les instructions de l'article 83042 de la base de connaissances VMware.

• Vous voyez une brève rafale de messages de journal dans le fichier syslog.log après chaque démarrage d'ESXi

  Après une mise à jour vers ESXi 7.0 Update 2, vous pouvez voir une brève rafale de messages de journaux après chaque démarrage d'ESXi.
  Ces journaux n'indiquent aucun problème avec ESXi et vous pouvez les ignorer. Par exemple :
  ​2021-01-19T22:44:22Z watchdog-vaai-nasd: '/usr/lib/vmware/nfs/bin/vaai-nasd -f' exited after 0 seconds (quick failure 127) 1
2021-01-19T22:44:22Z watchdog-vaai-nasd: Executing '/usr/lib/vmware/nfs/bin/vaai-nasd -f'
2021-01-19T22:44:22.990Z aainasd[1000051135]: Log for VAAI-NAS Daemon for NFS version=1.0 build=build-00000 option=DEBUG
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoadFile: No entries loaded by dictionary.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "/usr/lib/vmware/config": No such file or directory.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/config": No such file or directory.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/preferences": No such file or directory.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: Switching to VMware syslog extensions
2021-01-19T22:44:22.992Z vaainasd[1000051135]: Loading VAAI-NAS plugin(s).
2021-01-19T22:44:22.992Z vaainasd[1000051135]: DISKLIB-PLUGIN : Not loading plugin /usr/lib/vmware/nas_plugins/lib64: Not a shared library.

  Solution : aucune.

• Affichage de messages d'avertissement sur des VIB manquants dans les rapports de vérification de compatibilité de vSphere Quick Boot

  Après la mise à niveau vers ESXi 7.0 Update 2, si vous vérifiez la compatibilité de l'instance de vSphere Quick Boot de votre environnement à l'aide de la commande /usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py, des messages d'avertissement sur les VIB manquants dans le shell s'affichent. Par exemple :
  Un ou plusieurs VIB sont introuvables… dans la collection de VIB spécifiée.
Le ou les VIB réservés manquants seront ignorés… ils sont supprimés des ID de VIB réservés.
  Ces avertissements n'indiquent pas un problème de compatibilité.

  Solution : les messages sur les VIB manquants peuvent être ignorés en toute sécurité et n'affectent pas la compatibilité vSphere Quick Boot. La ligne de sortie finale de la commande loadESXCheckCompat indique sans ambiguïté si l'hôte est compatible.

• Le démarrage automatique d'un cluster que vous gérez avec une image vSphere Lifecycle Manager échoue avec une erreur

  Si vous tentez de démarrer automatiquement un cluster que vous gérez avec une image vSphere Lifecycle Manager pour effectuer une installation avec état et que vous remplacez les partitions VMFS, l'opération échoue avec une erreur. Dans le bundle de support, vous voyez des messages tels que :
  2021-02-11T19:37:43Z Host Profiles[265671 opID=MainThread]: ERROR: EngineModule::ApplyHostConfig. Exception: [Errno 30] Read-only file system

  Solution : suivez les instructions du fournisseur pour nettoyer la partition VMFS dans l'hôte cible et réessayez l'opération. Vous pouvez également utiliser un disque vide. Pour en savoir plus sur l'utilitaire de partitionnement de disques dans ESXi, consultez l'article de la base de connaissance VMware 1036609.

• Les mises à niveau vers ESXi 7.x à partir des versions 6.5.x et 6.7.0 à l'aide d'ESXCLI peuvent échouer en raison d'une limitation d'espace.

  Les mises à niveau vers ESXi 7.x à partir des versions 6.5.x et 6.7.0 à l'aide des commandes ESXCLI esxcli software profil update ou esxcli software profile install peuvent échouer, car la banque de démarrage ESXi peut être inférieure à la taille du profil d'image. Dans ESXi Shell ou l'interpréteur de commandes PowerCLI, une erreur semblable à la suivante s'affiche :

  [InstallationError]
   La transaction en attente nécessite 244 Mo d'espace libre, mais la taille maximale prise en charge est de 239 Mo.
   Consultez le fichier journal pour plus de détails.

  Ce problème se produit également lorsque vous tentez d'effectuer une mise à niveau de l'hôte ESXi à l'aide des commandes ESXCLI esxcli software vib update ou esxcli software vib install.

  Solution : vous pouvez effectuer la mise à niveau en deux étapes, à l'aide de la commande esxcli software profile update pour mettre à jour les hôtes ESXi vers ESXi 6.7 Update 1 ou une version ultérieure, puis vers la version 7.0 Update 1c. Vous pouvez également exécuter une mise à niveau à l'aide d'une image ISO et de vSphere Lifecycle Manager.

• L'authentification par carte à puce et RSA SecurID peut cesser de fonctionner après la mise à niveau vers vCenter Server 7.0.

  Si vous avez configuré vCenter Server pour l'authentification par carte à puce ou RSA SecurID, consultez l'article de la base de connaissances VMware sur https://kb.vmware.com/s/article/78057 avant de démarrer le processus de mise à niveau de vSphere 7.0. Si vous n'appliquez pas la solution comme décrit dans la base de connaissances, vous pouvez voir les messages d'erreur suivants et l'authentification par carte à puce ou RSA SecurID ne fonctionne pas.

  « L'authentification par carte à puce peut cesser de fonctionner. Les paramètres de carte à puce ne sont peut-être pas conservés et l'authentification par carte à puce peut cesser de fonctionner. »

  ou

  « L'authentification RSA SecurID peut cesser de fonctionner. Les paramètres RSA SecurID ne sont peut-être pas conservés et l'authentification RSA SecurID peut cesser de fonctionner. »

  Solution : avant de procéder à la mise à niveau vers vSphere 7.0, reportez-vous à l'article de la base de connaissances VMware sur https://kb.vmware.com/s/article/78057.

• La mise à niveau de vCenter Server avec une instance externe de Platform Services Controller de la version 6.7u3 vers la version 7.0 échoue avec une erreur VMAFD.

  Lorsque vous mettez à niveau un déploiement de vCenter Server à l'aide d'une instance externe de Platform Services Controller, vous convergez Platform Services Controller vers vCenter Server Appliance. Si la mise à niveau échoue avec l'erreur install.vmafd.vmdir_vdcpromo_error_21, le processus de premier amorçage de VMAFD a échoué. Le processus de premier amorçage de VMAFD copie la base de données du service d'annuaire VMware (data.mdb) à partir de l'instance source de Platform Services Controller et du partenaire de réplication vCenter Server Appliance.

  Solution : désactivez TSO (déchargement de segmentation TCP) et GSO (déchargement de segmentation générique) sur l'adaptateur Ethernet de l'instance source de Platform Services Controller ou de l'instance de vCenter Server Appliance du partenaire de réplication avant de mettre à niveau vCenter Server avec une instance externe de Platform Services Controller. Reportez-vous à l'article de la base de connaissances : https://kb.vmware.com/s/article/74678

• Les paramètres de carte à puce et de RSA SecurID peuvent ne pas être conservés lors de la mise à niveau de vCenter Server.

  L'authentification à l'aide de RSA SecurID ne fonctionnera pas après la mise à niveau vers vCenter Server 7.0. Un message d'erreur vous avertit de ce problème lors de la tentative de connexion à l'aide de votre identifiant RSA SecurID.

  Solution : reconfigurez la carte à puce ou RSA SecureID.

• La migration de vCenter Server pour Windows vers vCenter Server Appliance 7.0 échoue avec un message d'erreur réseau.

  La migration de vCenter Server pour Windows vers vCenter Server Appliance 7.0 échoue avec le message d'erreur L'adresse IP existe déjà dans le réseau. Cela empêche le processus de migration de configurer les paramètres réseau sur le nouveau dispositif vCenter Server Appliance. Pour plus d'informations, consultez le fichier journal : /var/log/vmware/upgrade/UpgradeRunner.log

  Solution :

  1. vérifiez que toutes les mises à jour Windows ont été effectuées sur le dispositif vCenter Server source pour l'instance de Windows, ou désactivez les mises à jour Windows automatiques jusqu'à la fin de la migration.
  2. Réexécutez la migration de vCenter Server pour Windows vers vCenter Server Appliance 7.0.

   

• Lorsque vous configurez le nombre de fonctions virtuelles pour un périphérique SR-IOV à l'aide du paramètre de module max_vfs, les modifications peuvent ne pas prendre effet.

  Dans vSphere 7.0, vous pouvez configurer le nombre de fonctions virtuelles pour un périphérique SR-IOV à l'aide de l'API de gestion de l'infrastructure virtuelle (VIM), par exemple via vSphere Client. La tâche ne nécessite pas le redémarrage de l'hôte ESXi. Une fois que vous avez utilisé la configuration de l'API VIM, si vous tentez de configurer le nombre de fonctions virtuelles SR-IOV à l'aide du paramètre du module max_vfs, les modifications peuvent ne pas prendre effet, car elles sont remplacées par la configuration de l'API VIM.

  Solution : aucune. Pour configurer le nombre de fonctions virtuelles pour un périphérique SR-IOV, utilisez la même méthode à chaque fois. Utilisez l'API VIM ou utilisez le paramètre du module max_vfs et redémarrez l'hôte ESXi.

• L'instance de vCenter Server Appliance mise à niveau ne conserve pas tous les réseaux secondaires (cartes réseau virtuelles) de l'instance source.

  Lors d'une mise à niveau majeure, si l'instance source du dispositif vCenter Server Appliance est configurée avec plusieurs réseaux secondaires autres que les cartes réseau virtuelles VCHA, l'instance de vCenter Server cible ne conserve pas les cartes réseau virtuelles autres que la carte réseau VCHA. Si l'instance source est configurée avec plusieurs cartes réseau virtuelles faisant partie des groupes de ports DVS, la configuration de la carte réseau virtuelle ne sera pas conservée pendant la mise à niveau. Les configurations des instances de vCenter Server Appliance qui font partie du groupe de ports standard seront conservées.

  Solution : aucune. Configurez manuellement le réseau secondaire dans l'instance cible de vCenter Server Appliance.

• Après la mise à niveau ou la migration d'un dispositif vCenter Server avec une instance externe de Platform Services Controller, les utilisateurs qui s'authentifient à l'aide d'Active Directory perdent l'accès à l'instance de vCenter Server récemment mise à niveau.

  Après la mise à niveau ou la migration d'un dispositif vCenter Server avec une instance externe de Platform Services Controller, si le dispositif vCenter Server récemment mis à niveau n'est pas joint à un domaine Active Directory, les utilisateurs qui s'authentifient à l'aide d'Active Directory perdent l'accès à l'instance de vCenter Server.

  Solution : vérifiez que la nouvelle instance de vCenter Server a été jointe à un domaine Active Directory. Reportez-vous à l'article de la base de connaissances : https://kb.vmware.com/s/article/2118543

• La migration d'une instance de vCenter Server pour Windows avec une instance externe de Platform Services Controller à l'aide d'une base de données Oracle échoue.

  S'il y a des chaînes non-ASCII dans le tableau des événements et tâches Oracle, la migration peut échouer lors de l'exportation des données d'événements et de tâches. Le message d'erreur suivant s'affiche : UnicodeDecodeError

  Solution : aucune.

• Après une mise à niveau de l'hôte ESXi, une vérification de conformité du profil d'hôte indique un état non conforme lorsque les tâches de correction de l'hôte échouent

  Un état non conforme indique une incohérence entre le profil et l'hôte.

  Cette incohérence peut se produire, car ESXi 7.0 n'autorise pas les règles de réclamation en double, mais le profil que vous utilisez contient des règles en double. Par exemple, si vous tentez d'utiliser le profil d'hôte que vous avez extrait de l'hôte avant la mise à niveau d'ESXi 6.5 ou d'ESXi 6.7 vers la version 7.0, et que le profil d'hôte contient des règles de réclamation en double de règles système par défaut, vous pouvez rencontrer des problèmes.

  Solution :

  1. Supprimez les règles de réclamation en double des règles système par défaut dans le document Profil d'hôte.
  2. Vérifiez l'état de conformité.
  3. Corrigez l'hôte.
  4. Si les étapes précédentes ne vous aident pas, redémarrez l'hôte.

   

• Un message d'erreur s'affiche dans l'interface de gestion de vCenter Server

  Après l'installation ou la mise à niveau vers vCenter Server 7.0, lorsque vous accédez au panneau Mettre à jour dans l'interface de gestion de vCenter Server, le message d'erreur « Vérifiez l'URL et réessayez » s'affiche. Ce message d'erreur ne vous empêche pas d'utiliser les fonctions du panneau Mettre à jour et vous pouvez afficher, transférer et installer les mises à jour disponibles.

  Solution : aucune.

Problèmes liés aux fonctionnalités de sécurité

• Dans ESXi, désactivez le service SLP (Service Location Protocol), slpd, pour éviter les vulnérabilités de sécurité potentielles

  Dans ESXi, certains services qui s'exécutent en plus du système d'exploitation hôte, notamment slpd, le Broker d'objets de modèle de données unifié, sfcbd et le service openwsmand associé, ont des vulnérabilités de sécurité avérées. VMware a résolu toutes les vulnérabilités connues dans VMSA-2019-0022 et VMSA-2020-0023, et les correctifs font partie de la version vSphere 7.0 Update 2. Alors que sfcbd et openwsmand sont désactivés par défaut dans ESXi, slpd est activé par défaut et vous devez le désactiver s'il n'est pas nécessaire pour éviter l'exposition à de futures vulnérabilités après une mise à niveau. 

  Solution : pour désactiver le service slpd, exécutez les commandes PowerCLI suivantes :
  $ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Set-VMHostService -policy “off”
$ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Stop-VMHostService -Confirm:$false
  
  Vous pouvez également utiliser la commande chkconfig slpd off && /etc/init.d/slpd stop.
  
  Le service openwsmand ne figure pas sur la liste des services ESXi et vous pouvez vérifier l'état du service à l'aide des commandes PowerCLI suivantes :
  $esx=(Get-EsxCli -vmhost xx.xx.xx.xx -v2)
$esx.system.process.list.invoke() | where CommandLine -like '*openwsman*' | select commandline

  Dans la liste des services ESXi, le service sfcbd s'affiche en tant que sfcbd-watchdog.
  
  Pour plus d'informations, reportez-vous aux articles 76372 et 1025757 de la base de connaissances VMware.

• La machine virtuelle chiffrée ne parvient pas à se mettre sous tension lorsque le cluster approuvé HA contient un hôte non attesté.

  Dans VMware® vSphere Trust Authority™, si vous avez activé HA sur le cluster approuvé et qu'un ou plusieurs hôtes du cluster ont échoué à l'attestation, une machine virtuelle chiffrée ne peut pas être mise sous tension.

  Solution : supprimez ou corrigez tous les hôtes ayant échoué à l'attestation du cluster approuvé.

• La mise sous tension de la machine virtuelle chiffrée échoue lorsque le cluster approuvé sur lequel DRS est activé contient un hôte non attesté.

  Dans VMware® vSphere Trust Authority™, si vous avez activé DRS sur le cluster approuvé et qu'un ou plusieurs hôtes du cluster échouent à l'attestation, DRS peut essayer de mettre sous tension une machine virtuelle chiffrée sur un hôte non attesté du cluster. Cette opération met la machine virtuelle dans un état verrouillé.

  Solution : supprimez ou corrigez tous les hôtes ayant échoué à l'attestation du cluster approuvé.

• La migration ou le clonage de machines virtuelles chiffrées sur des instances de vCenter Server échoue lorsque vous tentez de le faire à l'aide de vSphere Client.

  Si vous essayez de migrer ou de cloner une machine virtuelle chiffrée sur des instances de vCenter Server à l'aide de vSphere Client, l'opération échoue avec le message d'erreur suivant : « L'opération n'est pas autorisée dans l'état actuel. »

  Solution : vous devez utiliser les API vSphere pour migrer ou cloner des machines virtuelles chiffrées sur des instances de vCenter Server.

Problèmes de mise en réseau

• Débit réduit dans les performances de mise en réseau sur les cartes réseau virtuelles Intel 82599/X540/X550.

  La nouvelle fonctionnalité de mise en file d'attente de la paire ajoutée au pilote ixgben pour améliorer les performances de mise en réseau sur les cartes réseau virtuelles Intel 82599EB/X540/X550 peut réduire le débit sous certaines charges de travail dans vSphere 7.0 par rapport à vSphere 6.7.

  Solution : pour obtenir les mêmes performances de mise en réseau que vSphere 6.7, vous pouvez désactiver la mise en file d'attente de la paire avec un paramètre du module. Pour désactiver la mise en file d'attente de la paire, exécutez la commande suivante :

  # esxcli system module parameters set -p "QPair=0,0,0,0..." -m ixgben

  Une fois la commande exécutée, procédez au redémarrage.

• Un ou plusieurs périphériques d'E/S ne génèrent pas d'interruptions lorsque l'unité AMD IOMMU est utilisée

  Si les périphériques d'E/S sur votre hôte ESXi fournissent plus de 512 sources d'interruption distinctes au total, certaines sources reçoivent par erreur un index d'entrée de table de remappage d'interruption (IRTE) dans l'unité AMD IOMMU qui est supérieur à la valeur maximale. Les interruptions de ce type de source sont perdues, de sorte que le périphérique d'E/S correspondant se comporte comme si les interruptions sont désactivées.

  Solution : utilisez la commande ESXCLI esxcli system settings kernel set -s iovDisableIR -v true pour désactiver le remappeur d'interruption AMD IOMMU. Redémarrez l'hôte ESXi pour que la commande prenne effet.

• lorsque vous définissez la négociation automatique sur un adaptateur réseau, le périphérique peut échouer

  Dans certains environnements, si vous définissez la vitesse de liaison pour la négociation automatique des adaptateurs réseau à l'aide de la commande esxcli network nic set -a -n vmmicx, les périphériques peuvent échouer et le redémarrage ne récupère pas la connectivité. Ce problème est spécifique à une combinaison de certains adaptateurs réseau Intel X710/X722, d'un module SFP+ et d'un commutateur physique, dans lequel le scénario de négociation automatique de vitesse/duplex n'est pas pris en charge.

  Solution : assurez-vous d'utiliser un module SFP+ de marque Intel. Vous pouvez également utiliser un câble DAC (Direct Attach Copper).

• Les adaptateurs réseau RDMA paravirtuels (PVRDMA) ne prennent pas en charge les politiques de mise en réseau NSX

  Si vous configurez un port virtuel distribué NSX pour qu'il soit utilisé dans le trafic PVRDMA, le trafic du protocole RDMA sur les adaptateurs réseau PVRDMA n'est pas conforme aux stratégies de mise en réseau NSX.

  Solution : ne configurez pas les ports virtuels distribués NSX pour une utilisation dans le trafic PVRDMA.

• Les adaptateurs réseau Solarflare x2542 et x2541 configurés en mode port 1x100G peuvent atteindre un débit de 70 Gbits/s dans l'environnement vSphere

  vSphere 7.0 Update 2 prend en charge les adaptateurs réseau Solarflare x2542 et x2541 configurés en mode port 1x100G. Cependant, vous pouvez voir une limitation matérielle dans les périphériques qui entraîne un débit réel d'environ 70 Gbits/s dans l'environnement vSphere.

  Solution : aucune.

• Le trafic VLAN peut échouer après une réinitialisation de la carte réseau virtuelle

  Une carte réseau dont l'ID de périphérique PCI est 8086:1537 peut cesser d'envoyer et de recevoir des paquets marqués VLAN après une réinitialisation, par exemple, avec une commande vsish -e set /net/pNics/vmnic0/reset 1.

  Solution : évitez de réinitialiser la carte réseau. Si vous êtes déjà confronté à ce problème, utilisez les commandes suivantes pour restaurer la capacité VLAN, par exemple sur vmnic0 :
  # esxcli network nic software set --tagging=1 -n vmnic0
# esxcli network nic software set --tagging=0 -n vmnic0

• Toute modification des paramètres de l'équilibrage NetQueue entraîne la désactivation de NetQueue après un redémarrage de l'hôte ESXi.

  Toute modification des paramètres de l'équilibrage NetQueue à l'aide de la commande esxcli/localcli network nic queue loadbalancer set -n <nicname> --<lb_setting> entraîne la désactivation de NetQueue, qui est activé par défaut, après le redémarrage d'un hôte ESXi.

  Solution : après une modification des paramètres de l'équilibrage NetQueue et le redémarrage de l'hôte, utilisez la commande configstorecli config current get -c esx -g network -k nics pour récupérer les données ConfigStore afin de vérifier si /esx/network/nics/net_queue/load_balancer/enable fonctionne comme prévu.

  Après avoir exécuté la commande, vous voyez une sortie semblable à ce qui suit :
  {
"mac": "02:00:0e:6d:14:3e",
"name": "vmnic1",
"net_queue": {
  "load_balancer": {
    "dynamic_pool": true,
      "enable": true
  }
 },
 "virtual_mac": "00:50:56:5a:21:11"
}

  Si la sortie n'est pas conforme à ce qui est attendu, par exemple, "load_balancer": "enable": false", exécutez la commande suivante :
  esxcli/localcli network nic queue loadbalancer state set -n <nicname> -e true

• Les machines virtuelles à débit élevé peuvent subir une dégradation des performances réseau lorsque Network I/O Control (NetIOC) est activé.

  Les machines virtuelles qui nécessitent un débit réseau élevé peuvent subir une dégradation du débit lors de la mise à niveau de vSphere 6.7 vers vSphere 7.0 avec NetIOC activé.

  Solution : ajustez le paramètre ethernetx.ctxPerDev pour activer plusieurs mondes.

• Le trafic IPv6 ne parvient pas à traverser les ports VMkernel à l'aide d'IPsec.

  Lorsque vous migrez des ports VMkernel d'un groupe de ports vers un autre, le trafic IPv6 ne traverse pas les ports VMkernel à l'aide d'IPsec.

  Solution : supprimez l'Association de sécurité IPsec du serveur concerné, puis réappliquez l'association de sécurité. Pour en savoir plus sur la définition et la suppression d'une association de sécurité IPsec, reportez-vous à la documentation Sécurité vSphere.

• Les performances du réseau ESX avec une partie d'utilisation du CPU augmentent.

  Les performances du réseau ESX peuvent augmenter avec une partie d'utilisation du CPU.

  Solution : supprimez et ajoutez l'interface réseau avec uniquement 1 file d'attente répartie pour rx. Par exemple :

  esxcli network ip interface remove --interface-name=vmk1

  esxcli network ip interface add --interface-name=vmk1 --num-rxqueue=1

• La machine virtuelle peut perdre le trafic Ethernet après l'ajout à chaud, la suppression à chaud ou Storage vMotion

  Une machine virtuelle peut cesser de recevoir le trafic Ethernet après un ajout à chaud, une suppression à chaud ou Storage vMotion. Ce problème affecte les machines virtuelles pour lesquelles SR-IOV est activé sur la liaison montante de la vNIC. La carte réseau virtuelle PVRDMA présente ce problème lorsque la liaison montante du réseau virtuel est une carte réseau compatible avec la fonctionnalité RDMA de Mellanox et que les espaces de noms RDMA sont configurés.

  Solution : vous pouvez supprimer à chaud et ajouter à chaud les cartes réseau Ethernet affectées de la machine virtuelle pour restaurer le trafic. Sur les systèmes d'exploitation invités Linux, le redémarrage du réseau peut également résoudre le problème. Si ces solutions n'ont aucun effet, vous pouvez redémarrer la machine virtuelle pour restaurer la connectivité réseau.

• La modification de l'adresse IP d'un dispositif VCSA déployé avec une adresse IP statique nécessite que vous ayez créé les enregistrements DNS à l'avance.

  Avec l'introduction du DDNS, la mise à jour de l'enregistrement DNS fonctionne uniquement pour les dispositifs VCSA déployés avec la mise en réseau DHCP configurée. Lors de la modification de l'adresse IP de vCenter Server via l'interface VAMI, l'erreur suivante s'affiche :

  L'adresse IP spécifiée ne résout pas le nom d'hôte spécifié.

  Solution : il existe deux solutions.

  1. Créez une entrée DNS supplémentaire avec le même nom de domaine complet et l'adresse IP souhaitée. Connectez-vous au interface VAMI et suivez les étapes pour modifier l'adresse IP.
  2. Connectez-vous au dispositif VCSA à l'aide de SSH. Exécutez le script suivant :

     ./opt/vmware/share/vami/vami_config_net

     Utilisez l'option 6 pour modifier l'adresse IP d'eth0. Une fois les modifications apportées, exécutez le script suivant :

     ./opt/likewise/bin/lw-update-dns

     Redémarrez tous les services sur le dispositif VCSA pour mettre à jour les informations IP sur le serveur DNS.

• La suppression du groupe de ports virtuels distribués NSX (NSX DVPG) peut prendre plusieurs secondes après la suppression du commutateur logique correspondant dans NSX Manager.

  Au fur et à mesure que le nombre de commutateurs logiques augmente, la suppression du NSX DVPG dans vCenter Server peut prendre davantage de temps après la suppression du commutateur logique correspondant dans NSX Manager. Dans un environnement avec 12 000 commutateurs logiques, il faut environ 10 secondes pour qu'un NSX DVPG soit supprimé de vCenter Server.

  Solution : aucune.

• Hostd manque de mémoire et échoue si de nombreux groupes de ports virtuels distribués NSX sont créés.

  Dans vSphere 7.0, les groupes de ports virtuels distribués NSX consomment des quantités de mémoire beaucoup plus grandes que les réseaux opaques. Pour cette raison, les groupes de ports virtuels distribués NSX ne peuvent pas prendre en charge la même échelle qu'un réseau opaque pour une même quantité de mémoire.

  Solution : pour prendre en charge l'utilisation de groupes de ports virtuels distribués NSX, augmentez la quantité de mémoire dans vos hôtes ESXi. Si vous vérifiez que votre système dispose de suffisamment de mémoire pour prendre en charge vos machines virtuelles, vous pouvez augmenter directement la mémoire de hostd à l'aide de la commande suivante.

  localcli --plugin-dir /usr/lib/vmware/esxcli/int/ sched group setmemconfig --group-path host/vim/vmvisor/hostd --units mb --min 2048 --max 2048

  Notez que cela entraînera l'utilisation par hostd de la mémoire normalement réservée aux machines virtuelles de votre environnement. Cela peut avoir pour effet de réduire le nombre de machines virtuelles que votre hôte ESXi peut prendre en charge.

• DRS peut lancer vMotion de manière incorrecte si la réservation réseau est configurée sur une machine virtuelle

  Si la réservation réseau est configurée sur une machine virtuelle, il est prévu que DRS migre uniquement la machine virtuelle vers un hôte répondant aux exigences spécifiées. Dans un cluster incluant des nœuds de transport NSX, si certains des nœuds de transport rejoignent la zone de transport par NSX-T Virtual Distributed Switch (N-VDS) et d'autres par vSphere Distributed Switch (VDS) 7.0, DRS peut lancer vMotion de manière incorrecte. Vous pouvez rencontrer ce problème lorsque :

  • La machine virtuelle se connecte à un commutateur logique NSX configuré avec une réservation de réseau.
  • Certains nœuds de transport rejoignent la zone de transport à l'aide de N-VDS, d'autres par VDS 7.0 ou, les nœuds de transport rejoignent la zone de transport via différentes instances de VDS 7.0.

  Solution : faites en sorte que tous les nœuds de transport rejoignent la zone de transport par N-VDS ou la même instance de VDS 7.0.

• Lors de l'ajout d'une NIC VMkernel (vmknic) à un groupe de ports NSX, vCenter Server signale l'erreur « La connexion de l'adaptateur VMKernel à un groupe de ports NSX sur un hôte sans état n'est pas une opération prise en charge. Utilisez le groupe de ports distribués à la place. »
  • Pour ESXi sans état sur DVS (Distributed Virtual Switch), la vmknic d'un groupe de ports NSX est bloquée. Vous devez plutôt utiliser un groupe de ports distribués.
  • Pour ESXi avec état sur DVS, vmknic sur le groupe de ports NSX est pris en charge, mais vSAN peut rencontrer un problème s'il utilise vmknic sur un groupe de ports NSX.

  Solution : utilisez un groupe de ports distribués sur le même DVS.

• Échec potentiel de l'activation de SR-IOV à partir de vCenter pour QLogic 4x10GE QL41164HFCU CNA

  Si vous accédez à la boîte de dialogue Modifier les paramètres pour les adaptateurs réseau physiques et que vous tentez d'activer SR-IOV, l'opération peut échouer si vous utilisez QLogic 4x10GE QL41164HFCU CNA. La tentative d'activation de SR-IOV peut entraîner une panne réseau de l'hôte ESXi.

  Solution : utilisez la commande suivante sur l'hôte ESXi pour activer SR-IOV :

  esxcfg-module

• Échec de l'instance de vCenter Server si les hôtes d'un cluster utilisant Distributed Resource Scheduler (DRS) joignent la mise en réseau NSX-T via un commutateur virtuel distribué (VDS) différent ou une combinaison de commutateur virtuel distribué NSX-T (NVDS) et de VDS

  Dans vSphere 7.0, lorsque vous utilisez la mise en réseau NSX-T sur vSphere VDS avec un cluster DRS, si les hôtes ne joignent pas la zone de transport NSX via le même VDS ou NVDS, cela peut entraîner l'échec de l'instance de vCenter Server.

  Solution : les hôtes d'un cluster DRS doivent joindre la zone de transport NSX via le même VDS ou NVDS. 

Problèmes de stockage

• Les banques de données VMFS ne sont pas montées automatiquement après la suppression à chaud du disque et l'insertion à chaud sur les serveurs HPE Gen10 avec des contrôleurs SmartPQI.

  Lorsque des disques SATA sur des serveurs HPE Gen10 avec des contrôleurs SmartPQI sans développeur sont supprimés à chaud et réinsérés à chaud dans une baie de disques différente de la même machine, ou lorsque plusieurs disques sont supprimés à chaud et réinsérés à chaud dans un ordre différent, il arrive parfois qu'un nouveau nom local soit attribué au disque. La banque de données VMFS sur ce disque apparaît sous la forme d'un snapshot et ne sera pas montée automatiquement, car le nom du périphérique a changé.

  Solution : aucune. Le contrôleur SmartPQI ne prend pas en charge les opérations de suppression à chaud et d'insertion à chaud non ordonnées.

• ESXi peut mettre fin aux E/S sur les périphériques NVMeOF en raison d'erreurs sur tous les chemins actifs.

  Parfois, tous les chemins actifs vers le périphérique NVMeOF enregistrent des erreurs d'E/S en raison de problèmes de liaison ou de l'état du contrôleur. Si l'état de l'un des chemins devient inactif, le plug-in haute performance peut ne pas sélectionner un autre chemin si celui-ci indique un volume d'erreurs élevé. Par conséquent, l'E/S échoue.

  Solution : désactivez l'option de configuration /Misc/HppManageDegradedPaths pour débloquer l'E/S.

• La vérification VOMA sur les banques de données VMFS basées sur NVMe échoue avec une erreur.

  La vérification VOMA n'est pas prise en charge pour les banques de données VMFS basées sur NVMe et échoue avec l'erreur :

  ERROR: Échec de réservation du périphérique. Fonction non implémentée 

  Exemple :

  # voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>
  Exécution de VMFS Checker version 2.1 en mode de vérification
  Initialisation des métadonnées LVM, vérifications de base terminées
  
  Vérification de l'activité du système de fichiers
  Exécution du contrôle de réactivité du système de fichiers..|Analyse de l'activité de l'hôte VMFS-6 (4 096 octets/HB, 1 024 HB).
  ERROR: Échec de réservation du périphérique. Fonction non implémentée
  Abandon de la vérification du volume VMFS
  VOMA n'a pas pu vérifier le périphérique : Erreur générale

  Solution : aucune. Si vous devez analyser les métadonnées VMFS, collectez-les à l'aide de l'option -l et passez au support client VMware. La commande de collecte du vidage est la suivante :

  voma -l -f dump -d /vmfs/devices/disks/:<partition#> 

• L'utilisation de l'API de reconfiguration de machine virtuelle pour attacher un disque de première classe chiffré à une machine virtuelle chiffrée peut échouer avec une erreur.

  Si un FCD et une machine virtuelle sont chiffrés avec des clés de chiffrement différentes, vos tentatives pour attacher le FCD chiffré à la machine virtuelle chiffrée à l'aide de l'API de reconfiguration de machine virtuelle peuvent échouer avec le message d'erreur suivant :

  Impossible de déchiffrer le disque, car la clé ou le mot de passe est incorrect.

  Solution : utilisez l'API attachDisk plutôt que l'API de reconfiguration de machine virtuelle pour attacher un FCD chiffré à une machine virtuelle chiffrée.

• L'hôte ESXi peut ne pas répondre si une extension sans tête de sa banque de données VMFS fractionnée passe à l'état de perte permanente de périphérique (PDL).

  Ce problème ne se produit pas lorsqu'une extension hors tête de la banque de données VMFS fractionnée échoue avec l'extension de tête. Dans ce cas, l'intégralité de la banque de données devient inaccessible et n'autorise plus les E/S.

  En revanche, lorsque seule une extension sans tête échoue, mais que l'extension de tête reste accessible, le signal de pulsation de la banque de données semble être normal, et les E/S entre l'hôte et la banque de données continuent. Toutefois, toutes les E/S qui dépendent de l'extension hors tête ayant échoué commencent à échouer également. D'autres transactions d'E/S peuvent s'accumuler en attendant la résolution des E/S ayant échoué et entraîner l'absence de réponse de l'hôte.

  Solution : corrigez la condition PDL de l'extension hors tête pour résoudre ce problème.

• Le contrôleur NVMe virtuel est le contrôleur de disque par défaut pour les systèmes d'exploitation invités Windows 10.

  Le contrôleur NVMe virtuel est le contrôleur de disque par défaut pour les systèmes d'exploitation invités suivants lors de l'utilisation de la version matérielle 15 ou ultérieure :

  Windows 10
  Windows Server 2016
  Windows Server 2019

  Certaines fonctionnalités peuvent ne pas être disponibles lors de l'utilisation d'un contrôleur NVMe virtuel. Pour plus d'informations, reportez-vous à l'article https://kb.vmware.com/s/article/2147714

  Remarque : certains clients utilisent la valeur par défaut précédente de LSI Logic SAS. Cela concerne ESXi Host Client et PowerCLI.

  Solution : si vous avez besoin de fonctionnalités non disponibles sur le contrôleur NVMe virtuel, basculez vers VMware Paravirtual SCSI (PVSCSI) ou LSI Logic SAS. Pour plus d'informations sur l'utilisation de VMware Paravirtual SCSI (PVSCSI), reportez-vous à https://kb.vmware.com/s/article/1010398

• Après la mise à niveau d'un hôte ESXi vers vSphere 7.0, la présence de règles de réclamation de base en double peut entraîner un comportement inattendu

  Les règles de réclamation déterminent quel plug-in de gestion multivoie, tel que NMP, HPP, etc., possède des chemins d'accès à un périphérique de stockage particulier. ESXi 7.0 ne prend pas en charge les règles de réclamation en double. Toutefois, l'hôte ESXi 7.0 ne vous alerte pas si vous ajoutez des règles en double aux règles de réclamation existantes héritées via une mise à niveau d'une version héritée. Du fait de l'utilisation de règles en double, les périphériques de stockage peuvent être réclamés par des plug-ins imprévus, ce qui peut entraîner un résultat inattendu.

  Solution : N'utilisez pas de règles de réclamation de base en double. Avant d'ajouter une nouvelle règle de réclamation, supprimez toute règle de réclamation correspondante existante.

• Une requête CNS avec le filtre d'état de conformité défini peut prendre un temps anormalement long.

  L'API CNS QueryVolume vous permet d'obtenir des informations sur les volumes CNS, telles que l'état de conformité et de santé des volumes. Lorsque vous vérifiez l'état de conformité des volumes individuels, les résultats sont obtenus rapidement. Toutefois, lorsque vous appelez l'API CNS QueryVolume pour vérifier l'état de conformité de plusieurs volumes, plusieurs dizaines ou centaines, la requête peut s'exécuter lentement.

  Solution : évitez d'utiliser les requêtes par lot. Lorsque vous devez obtenir l'état de conformité, interrogez un volume à la fois ou limitez le nombre de volumes dans l'API à 20 requêtes ou moins. Lors de l'utilisation de la requête, évitez d'exécuter d'autres opérations CNS pour obtenir les meilleures performances.

• Une banque de données VMFS sauvegardée par un espace de noms ou un périphérique NVMe over Fabrics peut devenir inaccessible en permanence après la récupération d'une panne de APD ou PDL

  Si une banque de données VMFS sur un hôte ESXi est sauvegardée par un espace de noms ou un périphérique NVMe over Fabrics, en cas d'échec de type Tous chemins hors service (APD) ou PDL (Permanent Device Loss), la banque de données peut être inaccessible même après la récupération. Vous ne pouvez pas accéder à la banque de données à partir de l'hôte ESXi ou du système vCenter Server.

  Solution : pour récupérer à partir de cet état, effectuez une réanalyse au niveau de l'hôte ou du cluster. Pour plus d'informations, reportez-vous à la section Relancez l'analyse du stockage.

• Des volumes de stockage cloud natif supprimés peuvent apparaître temporairement comme existants dans l'interface utilisateur du stockage cloud natif

  Après la suppression d'un disque FCD qui sauvegarde un volume de stockage cloud natif, le volume peut toujours apparaître comme existant dans l'interface utilisateur du stockage cloud natif. Cependant, vos tentatives de suppression du volume échouent. Un message d'erreur similaire au message suivant peut s'afficher :
  L'objet ou l'élément indiqué est introuvable.

  Solution : La synchronisation complète suivante résoudra l'incohérence et mettra correctement à jour l'interface utilisateur du stockage cloud natif.

• Les tentatives d'attachement de plusieurs volumes de stockage cloud natif au même espace peuvent parfois échouer avec une erreur

  Lorsque vous attachez plusieurs volumes simultanément au même espace, l'opération d'attachement peut éventuellement choisir le même emplacement de contrôleur. Par conséquent, une seule des opérations réussit, alors que d'autres montages de volume échouent.

  Solution : Lorsque Kubernetes retente l'opération qui a échoué, celle-ci réussit si un emplacement de contrôleur est disponible sur la machine virtuelle de nœud.

• Dans certaines circonstances, lorsqu'une opération de stockage cloud natif échoue, l'état de la tâche s'affiche comme étant réussi dans vSphere Client

  Cela peut se produire lorsque, par exemple, vous utilisez une stratégie de stockage incompatible pour créer un volume de stockage cloud natif. L'opération échoue, tandis que vSphere Client indique que l'état de la tâche est réussi.

  Solution : l'état de la tâche réussie dans vSphere Client ne garantit pas que l'opération du stockage cloud natif a réussi. Pour vous assurer que l'opération a réussi, vérifiez ses résultats.

• Une opération de suppression infructueuse pour un volume CNS persistant peut laisser ce volume non supprimé sur la banque de données vSphere

  Ce problème peut se produire lorsque l'API de suppression CNS tente de supprimer un volume persistant qui est toujours attaché à un espace. Par exemple, lorsque vous supprimez l'espace de noms Kubernetes dans lequel l'espace s'exécute. Par conséquent, le volume est effacé de CNS et l'opération de requête CNS ne renvoie pas le volume. Cependant, le volume continue de résider sur la banque de données et ne peut pas être supprimé par le biais d'opérations répétées d'API de suppression CNS.

  Solution : aucune.

Problèmes vCenter Server et vSphere Client

• Les fournisseurs de distributeur se déconnectent après une modification de l'identifiant réseau principal.

  Lorsque vous modifiez l'adresse IP de vCenter (modification de l'identifiant réseau principal), les fournisseurs de distributeur enregistrés se déconnectent.

  Solution : réenregistrez les fournisseurs de distributeur.

• La migration entre systèmes vCenter d'une machine virtuelle échoue avec une erreur.

  Lorsque vous utilisez des dispositifs vCenter vMotion croisés pour déplacer le stockage et l'hôte d'une machine virtuelle vers une autre instance de vCenter Server, vous pouvez recevoir l'erreur L'opération n'est pas autorisée dans l'état actuel. 

  Cette erreur apparaît dans l'assistant de l'interface utilisateur après l'étape de sélection de l'hôte et avant l'étape de sélection de la banque de données, dans les cas où la stratégie de stockage attribuée à la machine virtuelle contient des règles basées sur l'hôte, telles que le chiffrement ou toute autre règle de filtre d'E/S.

  Solution : attribuez la machine virtuelle et ses disques à une stratégie de stockage sans règles basées sur l'hôte. Vous devrez peut-être déchiffrer la machine virtuelle si la machine virtuelle source est chiffrée. Réexécutez ensuite l'action entre dispositifs vCenter vMotion.

• Les informations sur les capteurs de stockage dans l'onglet santé du matériel affichent des valeurs incorrectes sur l'interface utilisateur de vCenter, l'interface utilisateur de l'hôte et le MOB.

  Lorsque vous accédez à Hôte > Surveiller > Santé du matériel > Capteurs de stockage sur l'interface utilisateur vCenter, les informations de stockage affichent des valeurs incorrectes ou inconnues. Le même problème se produit également sur l'interface utilisateur de l'hôte et sur le chemin d'accès au MOB « runtime.hardwareStatusInfo.storageStatusInfo ».

  Solution : aucune.

• Les paramètres avancés de l'hôte de l'interface utilisateur vSphere affichent l'emplacement actuel du casier du produit comme étant vide avec une valeur par défaut vide

  Les paramètres avancés de l'hôte de l'interface utilisateur vSphere affichent l'emplacement actuel du casier du produit comme étant vide avec une valeur par défaut vide. Cela est incohérent, car l'emplacement réel du produit symlink est créé et valide, ce qui entraîne une confusion pour l'utilisateur. La valeur par défaut ne peut pas être corrigée à partir de l'interface utilisateur.

  Solution : l'utilisateur peut utiliser la commande esxcli sur l'hôte pour corriger la valeur par défaut de l'emplacement actuel du casier de produit comme ci-dessous.

  1. Supprimez le paramètre d'emplacement du casier de produit existant avec : « esxcli system settings advanced remove -o ProductLockerLocation »

  2. Ajoutez à nouveau le paramètre d'emplacement du casier de produit avec la valeur par défaut appropriée :

        2.a.  Si le dispositif ESXi est une installation complète, la valeur par défaut est « /locker/packages/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/locker/packages/vmtoolsRepo »

        2.b. Si le dispositif ESXi est une configuration PXEboot comme autodeploy, la valeur par défaut est : « /vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/vmtoolsRepo »

        Exécutez la commande suivante pour déterminer automatiquement l'emplacement : export PRODUCT_LOCKER_DEFAULT=`readlink /productLocker`

        Ajoutez le paramètre : esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s $PRODUCT_LOCKER_DEFAULT

  Vous pouvez combiner toutes les étapes ci-dessus dans l'étape 2 en émettant la commande unique :

  esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s `readlink /productLocker`

• Les instances de vCenter Server SDDC (Software-Defined Data Center) s'affichent dans l'instance sur site de vSphere Client si une instance de vCenter Cloud Gateway est liée au SDDC.

  Lorsqu'une instance de vCenter Cloud Gateway est déployée dans le même environnement qu'une instance sur site de vCenter Server, et est liée à un SDDC, l'instance de vCenter Server SDDC s'affiche dans l'instance sur site de vSphere Client. Ce comportement est inattendu et l'instance liée de vCenter Server SDDC doit être ignorée. Toutes les opérations impliquant l'instance liée de vCenter Server SDDC doivent être effectuées sur vSphere Client exécuté dans vCenter Cloud Gateway.

  Solution : aucune.

Problèmes de gestion des machines virtuelles

• Les machines virtuelles sur lesquelles AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES) est activé ne peuvent pas créer de sockets VMCI (Virtual Machine Communication Interface)

  Les performances et les fonctionnalités qui nécessitent VMCI peuvent être affectées sur les machines virtuelles sur lesquelles AMD SEV-ES est activé, car ces machines virtuelles ne peuvent pas créer de sockets VMCI.

  Solution : aucune.

• Échec du démarrage HTTP UEFI des machines virtuelles sur les hôtes ESXi d'une version antérieure à la version 7.0 Update 2

  Le démarrage HTTP UEFI des machines virtuelles est pris en charge uniquement sur les hôtes ESXi 7.0 Update 2 et versions ultérieures, et les machines virtuelles dotées de la version de matériel 19 ou version ultérieure.

  Solution : utilisez le démarrage HTTP UEFI uniquement sur les machines virtuelles avec la version de matériel 19 ou version ultérieure. L'utilisation de la version de matériel 19 garantit que les machines virtuelles sont placées uniquement sur des hôtes disposant d'ESXi version 7.0 Update 2 ou version ultérieure.

• La section « post-personnalisation » du script de personnalisation s'exécute avant la personnalisation de l'invité.

  Lorsque vous exécutez le script de personnalisation de l'invité pour un système d'exploitation invité Linux, la section pré-personnalisation du script de personnalisation qui est défini dans la spécification de personnalisation s'exécute avant la personnalisation de l'invité et la section post-personnalisation s'exécute ensuite. Si vous activez Cloud-Init dans le système d'exploitation invité d'une machine virtuelle, la section post-personnalisation s'exécute avant la personnalisation en raison d'un problème connu dans Cloud-Init.

  Solution : désactivez Cloud-Init et utilisez la personnalisation de l'invité standard. 

• Les opérations de migration de groupe dans vSphere vMotion, Storage vMotion et vMotion sans stockage partagé échouent avec une erreur

  Lorsque vous effectuez des opérations de migration de groupe sur des machines virtuelles avec plusieurs disques et des snapshots à plusieurs niveaux, les opérations peuvent échouer avec l'erreur com.vmware.vc.GenericVmConfigFault n'a pas pu attendre les données. Erreur 195887167. Connexion fermée par l'hôte distant, probablement en raison d'une expiration du délai.

  Solution : réexécutez l'opération de migration sur les machines virtuelles ayant échoué, une à la fois.

• Le déploiement d'un modèle OVF ou OVA à partir d'une URL échoue avec une erreur Interdit 403.

  Les URL qui contiennent un paramètre de requête HTTP ne sont pas prises en charge. Par exemple, http://webaddress.com?file=abc.ovf ou les URL S3 pré-signées par Amazon.

  Solution : téléchargez les fichiers et déployez-les à partir de votre système de fichiers local.

• Le troisième niveau d'objets imbriqués dans un dossier de machine virtuelle n'est pas visible

  Procédez comme suit :

  1. Accédez à un centre de données et créez un dossier de machine virtuelle.
  2. Dans le dossier de la machine virtuelle, créez un dossier de machine virtuelle imbriqué.
  3. Dans le deuxième dossier, créez une autre machine virtuelle imbriquée, un dossier de machine virtuelle, un vApp ou un modèle de machine virtuelle.

  Par exemple, dans l'arborescence de l'inventaire VM et modèles, vous ne pouvez pas voir les objets dans le troisième dossier imbriqué.

  Solution : pour afficher les objets dans le troisième dossier imbriqué, accédez au second dossier imbriqué et sélectionnez l'onglet VM.

Problèmes de vSphere HA et Fault Tolerance

• Les machines virtuelles d'un cluster peuvent être inactives après une restauration suite à l'inaccessibilité de stockage, telle qu'une condition APD à l'échelle du cluster.

  Certaines machines virtuelles peuvent devenir inactives après la restauration d'une condition APD à l'échelle du cluster, même si HA et VMCP sont activés sur le cluster.

  Ce problème peut survenir lorsque les conditions suivantes se produisent simultanément :

  • Tous les hôtes du cluster connaissent une condition APD et ne récupèrent pas jusqu'à l'expiration du délai de VMCP.
  • L'agent HA principal initie le basculement en raison d'une condition APD sur un hôte.
  • La mise sous tension de l'API pendant le basculement HA échoue en raison de l'une des situations suivantes :
    • APD sur le même hôte
    • APD en cascade sur l'ensemble du cluster
    • Problèmes de stockage
    • Indisponibilité des ressources
  • L'annulation de l'enregistrement de FDM et l'utilisation de logique de machine virtuelle par des VC peut démarrer à un moment où FDM n'a pas annulé l'enregistrement de la VM ayant échoué et la synchronisation de l'hôte de VC répond que plusieurs hôtes signalent la même machine virtuelle. FDM et VC annulent tous deux l'enregistrement des différentes copies enregistrées de la même machine virtuelle à partir de différents hôtes, la machine virtuelle devient alors inactive.

   

  Solution : vous devez annuler l'enregistrement et réenregistrer les machines virtuelles inactives manuellement dans le cluster après la restauration d'APD.

  Si vous ne réenregistrez pas manuellement les machines virtuelles inactives, HA tente de basculer les machines virtuelles inactives, mais cela peut prendre entre 5 et 10 heures selon le moment où APD est récupéré.

  Les fonctionnalités globales du cluster ne sont pas affectées dans ces cas et HA continuera à protéger les machines virtuelles. Il s'agit d'une anomalie dans les données affichées sur VC pendant la durée du problème.

Problèmes liés à vSphere Lifecycle Manager

• Vous ne pouvez pas activer NSX-T sur un cluster déjà activé pour gérer la configuration et les mises à jour d'images sur tous les hôtes collectivement.

  NSX-T n'est pas compatible avec la fonctionnalité de vSphere Lifecycle Manager pour la gestion des images. Lorsque vous activez collectivement un cluster pour la configuration et les mises à jour d'images sur tous les hôtes du cluster, vous ne pouvez pas activer NSX-T sur ce cluster. Toutefois, vous pouvez déployer des dispositifs NSX Edge sur ce cluster.

  Solution : déplacez les hôtes vers un nouveau cluster que vous pouvez gérer avec des lignes de base et activez NSX-T sur ce nouveau cluster.

• vSphere Lifecycle Manager et les services de fichiers vSAN ne peuvent pas être activés simultanément sur un cluster vSAN dans vSphere 7.0

  Si vSphere Lifecycle Manager est activé sur un cluster, les services de fichiers vSAN ne peuvent pas être activés sur le même cluster et vice versa. Afin d'activer vSphere Lifecycle Manager sur un cluster sur lequel les services de fichiers vSAN sont déjà activés, désactivez d'abord les services de fichiers vSAN et recommencez l'opération. Notez que si vous effectuez une transition vers un cluster géré par une seule image, vSphere Lifecycle Manager ne peut pas être désactivé sur ce cluster.

  Solution : aucune.

• Lorsqu'un gestionnaire de support matériel n'est pas disponible, la fonctionnalité de vSphere High Availability (HA) est affectée

  Si le gestionnaire de support matériel n'est pas disponible pour un cluster que vous gérez avec une seule image, dans laquelle un complément de microprogramme et de pilotes est sélectionné et où vSphere HA est activé, la fonctionnalité vSphere HA est affectée. Les erreurs suivantes peuvent se produire.

  • Échec de la configuration de vSphere HA sur un cluster.
  • Impossible de terminer la configuration de l'agent vSphere HA sur cet hôte : Une erreur s'est produite lors de l'application de VIB HA sur le cluster.
  • La correction de vSphere HA échoue : Une erreur système générale s'est produite : impossible d'accéder à un mappage de composants effectif.
  • La désactivation de vSphere HA échoue : échec de la tâche de suppression de la solution. Une erreur système générale s'est produite : le module de support matériel est introuvable à partir du dépôt ou du gestionnaire de support matériel.

   

  Solution :

  • si le gestionnaire de support matériel est temporairement indisponible, procédez comme suit.
  1. Reconnectez le gestionnaire de support matériel à l'instance de vCenter Server.
  2. Sélectionnez un cluster dans le menu Hôtes et cluster.
  3. Sélectionnez l'onglet Configurer.
  4. Sous Services, cliquez sur Disponibilité vSphere.
  5. Réactivez vSphere HA.
  • Si le gestionnaire de support matériel est définitivement indisponible, procédez comme suit.
  1. Supprimez le gestionnaire de support matériel et le module de support matériel de la spécification de l'image.
  2. Réactivez vSphere HA.
  3. Sélectionnez un cluster dans le menu Hôtes et cluster.
  4. Sélectionnez l'onglet Mises à jour.
  5. Cliquez sur Modifier.
  6. Supprimez le complément de microprogramme et de pilotes, puis cliquez sur Enregistrer.
  7. Sélectionnez l'onglet Configurer.
  8. Sous Services, cliquez sur Disponibilité vSphere.
  9. Réactivez vSphere HA.

   

• I/OFilter n'est pas supprimé d'un cluster après un processus de correction dans vSphere Lifecycle Manager

  La suppression d'I/OFilter d'un cluster en corrigeant le cluster dans vSphere Lifecycle Manager échoue avec le message d'erreur suivant : Le filtre iofilter XXX existe déjà. Le filtre iofilter reste répertorié comme étant installé.

  Solution :

  1. appelez l'API IOFilter UninstallIoFilter_Task à partir de l'objet géré vCenter Server (IoFilterManager).
  2. Corrigez le cluster dans vSphere Lifecycle Manager.
  3. Appelez l'API IOFilter ResolveInstallationErrorsOnCluster_Task à partir de l'objet géré par vCenter Server (IoFilterManager) pour mettre à jour la base de données.

   

• Lors de la correction d'un cluster activé pour vSphere HA dans vSphere Lifecycle Manager, l'ajout d'hôtes provoque un état d'erreur vSphere HA

  L'ajout d'un ou de plusieurs hôtes ESXi lors d'un processus de correction d'un cluster activé pour vSphere HA génère le message d'erreur suivant : Une erreur s'est produite lors de l'application de VIB HA sur le cluster.

  Solution : une fois l'opération de correction du cluster terminée, effectuez l'une des tâches suivantes.

  • Cliquez avec le bouton droit sur l'hôte ayant échoué ESXi et sélectionnez Reconfigurer pour vSphere HA.
  • Désactivez et réactivez vSphere HA pour le cluster.

   

• Lors de la correction d'un cluster activé pour vSphere HA dans vSphere Lifecycle Manager, la désactivation et la réactivation de vSphere HA provoquent un état d'erreur de vSphere HA

  La désactivation et la réactivation de vSphere HA au cours du processus de correction d'un cluster peuvent entraîner l'échec du processus de correction en raison des rapports sur les contrôles de santé de vSphere HA signalant que les VIB vSphere HA ne sont pas installés sur les hôtes. Le message d'erreur suivant peut s'afficher : La définition de la spécification d'image souhaitée pour le cluster a échoué.

  Solution : une fois l'opération de correction de cluster terminée, désactivez et réactivez vSphere HA pour le cluster.

• La vérification des images recommandées dans vSphere Lifecycle Manager présente des performances ralenties dans les clusters de grande taille.

  Dans les clusters de grande taille comportant plus de 16 hôtes, la tâche de génération de recommandations peut prendre plus d'une heure pour s'achever ou sembler se bloquer. La date de fin de la tâche de la tâche de recommandation dépend du nombre de périphériques configurés sur chaque hôte et du nombre de candidats d'image du dépôt que vSphere Lifecycle Manager doit traiter avant d'obtenir une image valide à recommander.

  Solution : aucune.

• La vérification de la compatibilité matérielle dans vSphere Lifecycle Manager présente des performances ralenties dans les clusters de grande taille.

  Dans les clusters de grande taille comportant plus de 16 hôtes, la tâche de génération des rapports de validation peut prendre jusqu'à 30 minutes ou sembler se bloquer. La durée d'exécution dépend du nombre de périphériques configurés sur chaque hôte et du nombre d'hôtes configurés dans le cluster.

  Solution : aucune.

• Des messages d'erreur incomplets dans des langues autres que l'anglais s'affichent lorsque vous corrigez un cluster dans vSphere Lifecycle Manager.

  Des messages d'erreur incomplets peuvent s'afficher pour les langues localisées dans l'interface utilisateur de vCenter Server. Les messages s'affichent après l'échec d'un processus de correction de cluster dans vSphere Lifecycle Manager. Par exemple, vous pouvez observer le message d'erreur suivant.
  
  Le message d'erreur en langue anglaise : Virtual machine 'VMC on DELL EMC -FileServer' that runs on cluster 'Cluster-1' reported an issue which prevents entering maintenance mode: Impossible d'accéder à la configuration de la machine virtuelle : Impossible d'accéder au fichier [local-0] VMC on Dell EMC-FileServer/VMC on Dell EMC-FileServer.vmx
  
  Le message d'erreur en langue française : La VM « VMC on DELL EMC -FileServer », située sur le cluster « {Cluster-1} », a signalé un problème empêchant le passage en mode de maintenance : Impossible d'accéder à la configuration de la machine virtuelle : Impossible d'accéder au fichier [local-0] VMC on Dell EMC-FileServer/VMC on Dell EMC-FileServer.vmx

  Solution : aucune.

• L'importation d'une image sans complément fournisseur, composant ou complément de microprogramme et de pilotes dans un cluster sur lequel l'image contient ces éléments ne supprime pas les éléments d'image de l'image existante.

  Seule l'image de base ESXi est remplacée par celle de l'image importée.

  Solution : une fois le processus d'importation terminé, modifiez l'image et, si nécessaire, supprimez le complément fournisseur, les composants et le complément de microprogramme et de pilotes.

• Lorsque vous convertissez un cluster qui utilise des lignes de base en un cluster qui utilise une seule image, un avertissement s'affiche indiquant que les VIB vSphere HA seront supprimés.

  La conversion d'un cluster activé pour vSphere HA qui utilise des lignes de base en un cluster qui utilise une seule image peut entraîner l'affichage d'un message d'avertissement indiquant que le composant vmware-fdm sera supprimé.

  Solution : vous pouvez ignorer ces messages. Le processus de conversion installe le composant vmware-fdm.

• Si vSphere Update Manager est configuré pour télécharger des mises à jour de correctifs à partir d'Internet via un serveur proxy, après la mise à niveau vers vSphere 7.0 qui convertit Update Manager en vSphere Lifecycle Manager, le téléchargement de correctifs à partir du référentiel de correctifs de VMware peut échouer.

  Dans les versions antérieures de vCenter Server vous pouviez configurer des paramètres de proxy indépendants pour les dispositifs vCenter Server et vSphere Update Manager. Après une mise à niveau vers vSphere 7.0, vSphere Update Manager service devient partie intégrante du service Lifecycle Manager vSphere. Pour le service de vSphere Lifecycle Manager, les paramètres de proxy sont configurés à partir des paramètres de vCenter Server Appliance. Si vous avez configuré Update Manager pour télécharger des mises à jour de correctifs à partir d'Internet via un serveur proxy, mais que vCenter Server Appliance ne disposait pas d'une configuration de paramètre de proxy, après une mise à niveau de vCenter Server vers la version 7.0, vSphere Lifecycle Manager ne parvient pas à se connecter au dépôt de VMware et ne parvient pas à télécharger les correctifs ou les mises à jour.

  Solution : connectez-vous à l'interface de gestion de vCenter Server Appliance, https://vcenter-server-appliance-FQDN-or-IP-address:5480, pour configurer les paramètres de proxy pour le dispositif vCenter Server Appliance et activer vSphere Lifecycle Manager pour utiliser le proxy.

Problèmes divers

• Lors de l'application d'un profil d'hôte avec la version 6.5 à un hôte ESXi avec la version 7.0, la vérification de conformité échoue.

  L'application d'un profil d'hôte avec la version 6.5 à un hôte ESXi avec la version 7.0 entraîne le signalement du profil de fichier coredump comme non conforme à l'hôte.

  Solution : il existe deux solutions.

  1. Lorsque vous créez un profil d'hôte avec la version 6.5, définissez une option de configuration avancée VMkernel.Boot.autoCreateDumpFile sur false sur l'hôte ESXi.
  2. Lorsque vous appliquez un profil d'hôte existant avec la version 6.5, ajoutez une option de configuration avancée VMkernel.Boot.autoCreateDumpFile dans le profil d'hôte, configurez l'option sur une stratégie fixe et définissez la valeur sur false.

   

• Les pilotes ESXi natifs ConnectX-4 ou ConnectX-5 de Mellanox peuvent présenter une dégradation mineure du débit lorsque la fonctionnalité Dynamic Receive Side Scaling (DYN_RSS) ou Generic RSS (GEN_RSS) est activée.

  Les pilotes ESXi natifs ConnectX-4 ou ConnectX-5 de Mellanox peuvent présenter moins de 5 % de dégradation du débit lorsque les fonctionnalités DYN_RSS et GEN_RSS sont activées, ce qui est peu susceptible d'affecter les charges de travail normales.

  Solution : vous pouvez désactiver les fonctionnalités DYN_RSS et GEN_RSS à l'aide des commandes suivantes :

  # esxcli system module parameters set -m nmlx5_core -p "DYN_RSS=0 GEN_RSS=0"

  # reboot

• Le trafic RDMA entre deux machines virtuelles sur le même hôte peut échouer dans l'environnement PVRDMA.

  Dans une implémentation vSphere 7.0 d'un environnement PVRDMA, les machines virtuelles acheminent le trafic via le HCA pour la communication locale si un HCA est présent. Toutefois, le bouclage du trafic RDMA ne fonctionne pas sur le pilote qedrntv.  Par exemple, les paires RDMA mises en file d'attente exécutées sur des machines virtuelles qui sont configurées sous le même port de liaison montante ne peuvent pas communiquer entre elles.

  Dans vSphere 6.7 et versions antérieures, le HCA a été utilisé pour le trafic RDMA local si le SRQ était activé. vSphere 7.0 utilise le bouclage HCA avec des machines virtuelles utilisant des versions de PVRDMA sur lesquelles SRQ est activé avec une version matérielle minimale de v14 utilisant le protocole RoCE v2.

  La version actuelle du microprogramme de l'adaptateur Marvell FastLinQ ne prend pas en charge le trafic de bouclage entre les paires mises en file d'attente du même PF ou port.

  Solution : la prise en charge requise est ajoutée dans le pilote prédéfini certifié pour vSphere 7.0. Si vous utilisez le pilote qedrntv de boîte de réception, vous devez utiliser une configuration à 3 hôtes et migrer les machines virtuelles vers le troisième hôte.

• Limitations des paires mises en file d'attente (QP) du trafic datagramme non fiable dans le pilote qedrntv.

  Il existe des limitations avec le pilote Marvell FastLinQ qedrntv RoCE et le trafic datagramme non fiable (UD). Les applications UD qui impliquent le trafic en masse peuvent échouer avec le pilote qedrntv. En outre, les paires UD mises en file d'attente peuvent uniquement fonctionner avec des régions de mémoire (MR) DMA. Les MR ou FRMR physiques ne sont pas prises en charge. Les applications tentant d'utiliser des MR ou FRMR physiques avec des paires UD mises en file d'attente ne parviennent pas à transmettre le trafic lorsqu'elles sont utilisées avec le pilote qedrntv. Les exemples connus de ces applications de test sont ibv_ud_pingpong et ib_send_bw.

  Les cas d'utilisation standard RoCE et RoCEv2 dans un environnement ESXi VMware tel que iSER, NVMe-oF (RoCE) et PVRDMA ne sont pas affectés par ce problème. Les cas d'utilisation pour le trafic UD sont limités et ce problème affecte un petit ensemble d'applications nécessitant un trafic UD en masse.

  Le matériel Marvell FastLinQ ne prend pas en charge le déchargement du trafic UD RDMA. Pour répondre aux exigences de VMware PVRDMA pour la prise en charge de GSI QP, une mise en œuvre limitée par logiciel uniquement de la prise en charge de la fonction UD QP a été ajoutée au pilote qedrntv. L'objectif de la mise en œuvre est de fournir la prise en charge de la communication GSI de chemin de contrôle et n'est pas une implémentation complète d'UD QP prenant en charge le trafic en masse et les fonctionnalités avancées.

  Étant donné que la prise en charge de la fonction UD est implémentée dans le logiciel, l'implémentation peut ne pas suivre le trafic intense et des paquets peuvent être abandonnés. Cela peut entraîner des échecs avec le trafic UD en masse.

  Solution : le trafic UD QP en masse n'est pas pris en charge avec le pilote qedrntv et il n'existe aucune solution à ce stade. Les cas d'utilisation RDMA de VMware ESXi (RoCE), tels que iSER, NVMe, RDMA et PVRDMA, ne sont pas affectés par ce problème.

• Les serveurs équipés de la carte réseau QLogic 578xx peuvent échouer lorsque vous connectez ou déconnectez fréquemment des LUN iSCSI

  Si vous déclenchez fréquemment une connexion iSCSI de carte réseau QLogic 578xx ou une déconnexion en peu de temps, le serveur peut échouer en raison d'un problème avec le pilote qfle3. Cela est dû à un défaut connu dans le microprogramme du périphérique.

  Solution : aucune.

• ESXi peut échouer lors du déchargement du pilote ou de l'opération de déconnexion du contrôleur dans un environnement Broadcom NVMe over FC.

  Dans l'environnement Broadcom NVMe over FC, ESXi peut échouer lors du déchargement du pilote ou de l'opération de déconnexion du contrôleur et afficher un message d'erreur tel que : @BlueScreen: #PF Exception 14 dans le monde 2098707:vmknvmeGener IP 0x4200225021cc addr 0x19

  Solution : aucune.

• ESXi n'affiche pas le numéro de version du microprogramme OEM des cartes réseau i350/X550 sur certains serveurs Dell.

  Le pilote ixgben de boîte de réception reconnaît uniquement la version des données de microprogramme ou la signature des cartes réseau i350/X550. Sur certains serveurs Dell, le numéro de version du microprogramme OEM est programmé dans la région de la version du module OEM et le pilote ixgben de boîte de réception ne lit pas ces informations. Seule la signature du microprogramme à 8 chiffres s'affiche.

  Solution : pour afficher le numéro de version du microprogramme OEM, installez la version 1.7.15 ou ultérieure du pilote ixgben asynchrone.

• Les cartes réseau X710 ou XL710 peuvent échouer dans ESXi.

  Lorsque vous lancez certaines opérations destructrices sur des cartes réseau X710 ou XL710, telles que la réinitialisation de la carte réseau ou la manipulation de l'arborescence de périphériques interne de VMKernel, le matériel de la carte réseau peut lire des données de la mémoire non constituée de paquets.

  Solution : ne réinitialisez pas la carte réseau ou ne manipulez pas l'état du périphérique interne VMkernel.

• NVMe-oF ne garantit pas le nom VMHBA persistant après le redémarrage du système

  NVMe-oF est une nouvelle fonctionnalité de vSphere 7.0. Si votre serveur dispose d'une installation de stockage USB qui utilise vmhba30+ et dispose également de la configuration NVMe over RDMA, le nom VMHBA peut changer après un redémarrage du système. Cela est dû au fait que l'attribution de nom VMHBA pour NVMe over RDMA est différente des périphériques PCIe. ESXi ne garantit pas la persistance.

  Solution : aucune.

• Échec de la sauvegarde pour une taille de base de données vCenter de 300 Go ou plus

  Si la taille de la base de données vCenter est de 300 Go ou plus, la sauvegarde basée sur fichier échoue avec un délai d'expiration. Le message d'erreur suivant s'affiche : Délai expiré ! L'opération ne s'est pas terminée dans le délai de 72 000 secondes.

  Solution : aucune.

• Une restauration de vCenter Server 7.0 qui est mise à niveau depuis vCenter Server 6.x avec une instance externe de Platform Services Controller vers vCenter Server 7.0 peut échouer

  Lorsque vous restaurez une instance de vCenter Server 7.0 mise à niveau de la version 6.x incluant une instance externe de Platform Services Controller vers vCenter Server 7.0, la restauration peut échouer et afficher l'erreur suivante : Échec de la récupération de la liste de stockage du dispositif.

  Solution : pendant la première étape du processus de restauration, augmentez le niveau de stockage de vCenter Server 7.0. Par exemple, si le type de stockage de la configuration externe de Platform Services Controller de vCenter Server 6.7 est petit, sélectionnez le type de stockage grand pour le processus de restauration.

• Le paramètre de configuration des protocoles SSL activé n'est pas configuré lors du processus de correction d'un profil d'hôte.

  Le paramètre de configuration des protocoles SSL activés ne sont pas configurés lors de la correction d'un profil d'hôte et seul le protocole par défaut du système tlsv1.2 est activé. Ce comportement est observé pour un profil d'hôte avec la version 7.0 et les versions antérieures dans un environnement vCenter Server 7.0.

  Solution : Pour activer les protocoles SSL TLSV 1.0 ou TLSV 1.1 pour SFCB, connectez-vous à un hôte ESXi à l'aide de SSH, puis exécutez la commande ESXCLI suivante : esxcli system wbem -P <protocol_name>

• Impossible de configurer les paramètres du mode de verrouillage à l'aide des profils d'hôte.

  Le mode de verrouillage ne peut pas être configuré à l'aide d'un profil d'hôte de sécurité et ne peut pas être appliqué à plusieurs hôtes ESXi à la fois. Vous devez configurer manuellement chaque hôte.  

  Solution : Dans vCenter Server 7.0, vous pouvez configurer le mode de verrouillage et gérer la liste des utilisateurs avec exception en mode de verrouillage à l'aide d'un profil d'hôte de sécurité.

• Lorsqu'un profil d'hôte est appliqué à un cluster, les paramètres Enhanced vMotion Compatibility (EVC) sont manquants dans les hôtes ESXi.

  Certains paramètres du fichier de configuration de VMware /etc/vmware/config ne sont pas gérés par les profils d'hôte et sont bloqués lorsque le fichier de configuration est modifié. Par conséquent, lorsque le profil d'hôte est appliqué à un cluster, les paramètres EVC sont perdus, ce qui entraîne la perte des fonctionnalités EVC. Par exemple, les CPU non masqués peuvent être exposés aux charges de travail.

  Solution : reconfigurez la ligne de base EVC pertinente sur le cluster pour récupérer les paramètres EVC.

• L'utilisation d'un profil d'hôte qui définit une partition de vidage de mémoire dans vCenter Server 7.0 génère une erreur.

  Dans vCenter Server 7.0, la configuration et la gestion d'une partition de vidage de mémoire dans un profil d'hôte ne sont pas disponibles. La tentative d'application d'un profil d'hôte qui définit une partition de vidage de mémoire entraîne l'erreur suivante : Aucune partition de coredump valide n'a été trouvée.

  Solution : aucune. Dans vCenter Server 7.0., les profils d'hôte ne prennent en charge que les vidages de mémoire basés sur des fichiers.

• Si vous exécutez la commande ESXCLI pour décharger le module du pare-feu, le service hostd échoue et les hôtes ESXi perdent la connectivité

  Si vous automatisez la configuration du pare-feu dans un environnement qui inclut plusieurs hôtes ESXi et que vous exécutez la commande ESXCLI esxcli network firewall unload qui détruit les filtres et décharge le module du pare-feu, le service hostd échoue et les hôtes ESXi perdent la connectivité.

  Solution : le déchargement du module de pare-feu n'est pas recommandé à tout moment. Si vous devez décharger le module du pare-feu, suivez les étapes ci-dessous :

  1. Arrêtez le service hostd en utilisant la commande :
     /etc/init.d/hostd stop.
  2. Déchargez le module du pare-feu à l'aide de la commande :
     esxcli network firewall unload.
  3. Réalisez les opérations requises.
  4. Chargez le module de pare-feu à l'aide de la commande :
     esxcli network firewall load.
  5. Démarrez le service hostd à l'aide de la commande :
     /etc/init.d/hostd start.
• Les opérations de vSphere Storage vMotion peuvent échouer dans un environnement vSAN en raison d'une session non authentifiée du gestionnaire NFC (Network File Copy)

  Les migrations vers une banque de données vSAN à l'aide de machines virtuelles vSphere Storage vMotion ayant au moins un snapshot et plusieurs disques virtuels avec une stratégie de stockage différente peuvent échouer. Ce problème se produit en raison d'une session non authentifiée du gestionnaire NFC, car le corps SOAP (Simple Object Access Protocol) dépasse la taille autorisée.

  Solution : migrez d'abord l'espace de noms d'accueil de la machine virtuelle et un seul des disques virtuels. Une fois l'opération terminée, effectuez une migration de disque uniquement des 2 disques restants. 

• Les modifications des propriétés et des attributs des périphériques et du stockage sur un hôte ESXi peuvent ne pas persister après un redémarrage

  Si la routine de détection de périphériques lors d'un redémarrage d'un hôte ESXi expire, il se peut que le plug-in de démarrage rapide ne reçoive pas toutes les modifications de configuration des périphériques et du stockage à partir de tous les périphériques enregistrés sur l'hôte. Par conséquent, le processus peut restaurer les propriétés de certains périphériques ou du stockage sur les valeurs par défaut après le redémarrage.

  Solution : restaurez manuellement les modifications apportées aux propriétés du périphérique ou du stockage concerné.

• Si vous utilisez un build bêta d'ESXi 7.0, les hôtes ESXi peuvent échouer avec un écran de diagnostic violet lors de certaines opérations de cycle de vie

  Si vous utilisez une build bêta d'ESXi 7.0, les hôtes ESXi peuvent échouer avec un écran de diagnostic violet lors de certaines opérations de cycle de vie, telles que le déchargement d'un pilote ou le basculement entre le mode ENS et le mode pilote natif. Par exemple, si vous tentez de modifier le mode ENS, vous voyez un message d'erreur semblable à celui-ci dans la trace de débogage : case ENS::INTERRUPT::NoVM_DeviceStateWithGracefulRemove hit BlueScreen: ASSERT bora/vmkernel/main/dlmalloc.c:2733 Ce problème est spécifique aux builds bêta et n'affecte pas les builds de version, telles qu'ESXi 7.0.

  Solution : mettez à jour vers ESXi 7.0 GA.

• Impossible de créer de snapshots de machines virtuelles en raison d'une erreur d'échec d'une opération de synthèse

  Lorsqu'un état Tous chemins hors service (All Paths Down, APD) se produit lors de la mise à jour du fichier de synthèse CBRC (Content Based Read Cache), une condition de trace rare peut entraîner des incohérences dans le fichier de synthèse. Par conséquent, vous ne pouvez pas créer de snapshots de machines virtuelles. Vous voyez une erreur de type Une erreur s'est produite lors de l'enregistrement du snapshot : Une opération de synthèse a échoué dans la trace de débogage.

  Solution : effectuez un cycle d'alimentation des machines virtuelles pour déclencher un recalcul des hachages CBRC et effacer les incohérences dans le fichier de synthèse.

• Les requêtes HTTP de certaines bibliothèques vers vSphere peuvent être rejetées.

  Le proxy inverse HTTP dans vSphere 7.0 applique une conformité standard plus stricte que dans les versions précédentes. Cela peut exposer des problèmes préexistants dans certaines bibliothèques tierces utilisées par les applications pour les appels SOAP à vSphere.

  Si vous développez des applications vSphere qui utilisent de telles bibliothèques ou si vous incluez des applications basées sur ces bibliothèques dans votre pile vSphere, vous pouvez rencontrer des problèmes de connexion lorsque ces bibliothèques envoient des requêtes HTTP à VMOMI. Par exemple, les requêtes HTTP émises à partir de bibliothèques vijava peuvent prendre le format suivant :

  POST /sdk HTTP/1.1
  SOAPAction
  Content-Type: text/xml; charset=utf-8
  User-Agent: Java/1.8.0_221

  Dans cet exemple, la syntaxe enfreint une exigence de champ d'en-tête de protocole HTTP qui impose deux-points après SOAPAction. Par conséquent, la requête est rejetée dans Flight.

  Solution : les développeurs qui exploitent des bibliothèques non conformes dans leurs applications peuvent envisager d'utiliser une bibliothèque qui suit les normes HTTP à la place. Par exemple, les développeurs qui utilisent la bibliothèque vijava peuvent envisager à la place d'utiliser la dernière version de la bibliothèque yavijava.

• Vous pouvez voir un fichier de vidage lorsque vous utilisez les pilotes Broadcom lsi_msgpt3, lsi_msgpt35 et lsi_mr3

  Lors de l'utilisation des contrôleurs lsi_msgpt3, lsi_msgpt35 et lsi_mr3, vous risquez d'obtenir le fichier de vidage lsuv2-lsi-drivers-plugin-util-zdump. Un problème se produit lors de la sortie de storelib utilisé dans cet utilitaire de plug-in. Il n'y a aucun impact sur les opérations ESXi et vous pouvez ignorer le fichier de vidage.

  Solution : vous pouvez ignorer ce message. Vous pouvez supprimer lsuv2-lsi-drivers-plugin à l'aide de la commande suivante :
  
  esxcli software vib remove -n lsuv2-lsiv2-drivers-plugin

• Le redémarrage n'est peut-être pas nécessaire après la configuration de SR-IOV sur un périphérique PCI dans vCenter, mais les configurations de périphérique effectuées par des extensions tierces peuvent être perdues et le redémarrage doit être effectué.

  Dans ESXi 7.0, la configuration de SR-IOV est appliquée sans redémarrage et le pilote de périphérique est rechargé. Les hôtes ESXi peuvent avoir des extensions tierces exécutant des configurations de périphérique qui doivent être exécutées après le chargement du pilote de périphérique pendant le démarrage. Un redémarrage est nécessaire pour ces extensions tierces afin de réappliquer la configuration du périphérique.

  Solution : vous devez redémarrer après la configuration de SR-IOV pour appliquer les configurations de périphérique tierces.

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