VMware ESXi 7.0 Update 3o | 28 septembre 2023 | Build 22348816

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

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

Nouveautés

  • ESXi 7.0 Update 3o ajoute la prise en charge de vSphere Quick Boot à plusieurs serveurs, notamment : 

    • Dell

      • PowerEdge XR4510c

      • PowerEdge XR4520c

      • PowerEdge XR5610

      • PowerEdge XR7620

      • PowerEdge XR8620t

      • R6615 vSAN Ready Node

      • R7615 vSAN Ready Node

      • VxRail VD-4510c

      • VxRail VD-4520c

    • Lenovo

      • ThinkSystem SR635 V3

      • ThinkSystem SR645 V3

      • ThinkSystem ST650 V3

      • ThinkSystem SR655 V3

    • HPE

      • Alletra 4120

      • Cray XD220v

      • ProLiant DL320 Gen 11

      • ProLiant DL380a Gen 11

      • ProLiant DL560 Gen 11

      • ProLiant ML110 Gen 11

      • ProLiant DL360 Gen 11

      • ProLiant DL380 Gen 11

      • ProLiant ML350 Gen 11

  • ESXi 7.0 Update 3o ajoute la prise en charge de vSphere Quick Boot à plusieurs pilotes, notamment : 

    • Intel

      • Technologie QuickAssist (QAT, QuickAssist Technology)

      • Équilibreur de charge dynamique (DLB, Dynamic Load Balancer) 

    • Cisco

      • NENIC_ENS

    Pour obtenir la liste complète des serveurs et pilotes pris en charge, reportez-vous au Guide de compatibilité VMware.

Versions antérieures d'ESXi 7.0

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

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

Remarques relatives à la prise en charge du produit

Prise en charge des espaces dans les noms des unités d'organisation : Avec ESXi 7.0 Update 3o, le service de fichiers vSAN prend en charge les espaces dans les noms des unités d'organisation.

Correctifs contenus dans cette version

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

Détails de la build

Nom de fichier de téléchargement :

VMware-ESXi-7.0U3o-22348816-depot.zip

Build :

22348816

Taille du téléchargement :

574,5 Mo

md5sum :

2dc3fe97405d94a12c3a7b14570e24c1

sha256checksum :

42594bd42b9cf2f7d002780d8fee9062a61567a9f3f1a0675726a6f29075d607

Redémarrage de l'hôte requis :

Oui

Migration ou arrêt de la machine virtuelle requis :

Oui

Composants

Composant

Bulletin

Catégorie

Gravité

Composant ESXi - VIB ESXi principaux

ESXi_7.0.3-0.105.22348816

Correctif de bogues

Critique

Composant d'installation/mise à niveau d'ESXi

esx-update_7.0.3-0.105.22348816

Correctif de bogues

Critique

Pilote AHCI natif VMware

VMware-ahci_2.0.11-2vmw.703.0.105.22348816

Correctif de bogues

Critique

Plug-in de gestion de LSU SMARTPQI

Microchip-smartpqiv2-plugin_1.0.0-9vmw.703.0.105.22348816

Correctif de bogues

Critique

Pilote de contrôleur de mémoire non volatile

VMware-NVMe-PCIe_1.2.3.16-3vmw.703.0.105.22348816

Correctif de bogues

Critique

Pilote SAS MPT 12 Gbit/s natif Avago (LSI)

Broadcom-lsi-msgpt3_17.00.12.00-2vmw.703.0.105.22348816

Correctif de bogues

Critique

Pilote Intel NVME avec technologie VMD

Intel-Volume-Mgmt-Device_2.7.0.1157-3vmw.703.0.105.22348816

Correctif de bogues

Critique

Composant ESXi - VIB ESXi principaux

ESXi_7.0.3-0.100.22348808

Sécurité

Critique

Composant d'installation/mise à niveau d'ESXi

esx-update_7.0.3-0.100.22348808

Sécurité

Critique

Composant ESXi Tools

VMware-VM-Tools_12.2.6.22229486-22348808

Sécurité

Critique

IMPORTANT :

  • À partir de vSphere 7.0, VMware utilise des composants pour le conditionnement des VIB avec des bulletins. Les bulletins ESXi et esx-update sont interdépendants. Incluez toujours les deux dans une ligne de base de correctifs d'hôte ESXi ou incluez le bulletin de cumul dans la ligne de base pour éviter un échec pendant le correctif de l'hôte.

  • Lorsque vous appliquez un correctif aux hôtes ESXi à l'aide de VMware Update Manager à partir d'une version antérieure à ESXi 7.0 Update 2, il est vivement recommandé d'utiliser le bulletin de cumul dans la ligne de base de correctifs. Si vous ne pouvez pas utiliser le bulletin de cumul, assurez-vous d'inclure tous les modules suivants dans la ligne de base de correctifs. Si les modules suivants ne sont pas inclus dans la ligne de base, l'opération de mise à jour échoue :

    • VMware-vmkusb_0.1-1vmw.701.0.0.16850804 ou version ultérieure

    • VMware-vmkata_0.1-1vmw.701.0.0.16850804 ou version ultérieure

    • VMware-vmkfcoe_1.0.0.2-1vmw.701.0.0.16850804 ou version ultérieure

    • VMware-NVMeoF-RDMA_1.0.1.2-1vmw.701.0.0.16850804 ou version ultérieure

Bulletin de cumul

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

ID de bulletin

Catégorie

Gravité

Détails

ESXi70U3o-22348816

Correctif de bogues

Critique

Sécurité et correctif de bogues

ESXi70U3so-22348808

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.0U3o-22348816-standard

ESXi-7.0U3o-22348816-no-tools

ESXi-7.0U3so-22348808-standard

ESXi-7.0U3so-22348808-no-tools

Image ESXi

Nom et version

Date de publication

Catégorie

Détails

ESXi7.0U3o - 22348816

28 septembre 2023

Correctif de bogues

Image de sécurité et de résolutions de bogues

ESXi7.0U3so - 22348808

28 septembre 2023

Sécurité

Image de sécurité uniquement

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

Téléchargement et installation de correctifs

Dans vSphere 7.x, le plug-in Update Manager, utilisé pour l'administration de vSphere Update Manager, est remplacé par le plug-in Lifecycle Manager. Les opérations d'administration pour vSphere Update Manager sont toujours disponibles sous le plug-in Lifecycle Manager, avec de nouvelles capacités pour vSphere Lifecycle Manager.

La manière habituelle d'appliquer des correctifs aux hôtes ESXi 7.x consiste à utiliser vSphere Lifecycle Manager. Pour plus d'informations, reportez-vous aux sections À propos de vSphere Lifecycle Manager et Lignes de base et images de vSphere Lifecycle Manager.

Vous pouvez également mettre à jour des hôtes ESXi sans utiliser le plug-in Lifecycle Manager et utiliser un profil d'image à la place. Pour ce faire, vous devez télécharger manuellement le fichier ZIP du bundle hors ligne du correctif à partir de VMware Customer Connect. Pour plus d'informations, reportez-vous aux sections Comment télécharger un fichier ZIP pour les correctifs et les mises à jour ESXi, Mise à niveau des hôtes à l'aide des commandes ESXCLI et au guide Mise à niveau de VMware ESXi.

Problèmes résolus

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

ESXi_7.0.3-0.105.22348816

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 affectés inclus

  • VMware_bootbank_gc_7.0.3-0.105.22348816

  • VMware_bootbank_native-misc-drivers_7.0.3-0.105.22348816

  • VMware_bootbank_vsanhealth_7.0.3-0.105.22348816

  • VMware_bootbank_crx_7.0.3-0.105.22348816

  • VMware_bootbank_esx-xserver_7.0.3-0.105.22348816

  • VMware_bootbank_vdfs_7.0.3-0.105.22348816

  • VMware_bootbank_cpu-microcode_7.0.3-0.105.22348816

  • VMware_bootbank_esx-base_7.0.3-0.105.22348816

  • VMware_bootbank_vsan_7.0.3-0.105.22348816

  • VMware_bootbank_esxio-combiner_7.0.3-0.105.22348816

  • VMware_bootbank_esx-ui_2.11.2-21988676

  • VMware_bootbank_bmcal_7.0.3-0.105.22348816

  • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.105.22348816

  • VMware_bootbank_trx_7.0.3-0.105.22348816

PR résolus

3244098, 3216958, 3245763, 3242021, 3246132, 3253205, 3256804, 3239170, 3251981, 3215370, 3117615, 3248478, 3252676, 3235496, 3238026, 3236064, 3224739, 3224306, 3223755, 3216958, 3233958, 3185125, 3219264, 3221620, 3218835, 3185560, 3221099, 3211625, 3221860, 3228586, 3224604, 3223539, 3222601, 3217258, 3213041, 3216522, 3221591, 3216389, 3220004, 3217633, 3216548, 3216449, 3156666, 3181574, 3180746, 3155476, 3211807, 3154090, 3184008, 3183519, 3183519, 3209853, 3100552, 3187846, 3113263, 3176350, 3185827, 3095511, 3184425, 3186351, 3186367, 3154090, 3158524, 3181601, 3180391, 3180283, 3184608, 3181774, 3155476, 3163361, 3182978, 3184368, 3160456, 3164575, 3181901, 3184871, 3166818, 3157195, 3164355, 3163271, 3112194, 3161690, 3261925, 3178589, 3178721, 3162963, 3168950, 3159168, 3158491, 3158866, 3096769, 3165374, 3122037, 3098760, 3164439, 3161473, 3162790, 3100030, 3096974, 3161473, 3165651, 3083007, 3118240, 3151076, 3118402, 3160480, 3156627, 3158531, 3162499, 3158512, 3053430, 3153395, 3117615, 3099192, 3158508, 3115870, 3119834, 3158220, 3110401, 2625439, 3099357, 3152811, 3108979, 3120165

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 gc, native-misc-drivers, vsanhealth, crx, esx-xserver, vdfs, cpu-microcode, esx-base, vsan, esxio-combiner, esx-ui, bmcal, esx-dvfilter-generic-fastpath et trx pour résoudre les problèmes suivants :

  • PR 3253205 : la passerelle IPv6 statique disparaît au bout de 18 heures

    Si vous configurez une adresse de passerelle IPv6 statique dans votre environnement vSphere, ces passerelles peuvent ne plus exister après un maximum de 18 heures en raison d'un délai d'expiration.

    Ce problème est résolu dans cette version. Le correctif supprime le délai d'expiration existant pour les passerelles statiques.

  • PR 3272532 : vous voyez la vitesse comme Semi-duplex après la modification de la vitesse de Auto à Intégral sur une vmnic

    Dans certains cas, les vérifications de longueur lors de l'analyse des TLV en duplex dans un environnement avec le protocole CDP (Cisco Discovery Protocol) activé peuvent échouer. Par conséquent, lorsque vous modifiez la vitesse d'Auto à Intégral sur une NIC physique sur des périphériques homologues, vous ne voyez pas la valeur de duplex réelle dans le TLV sous les informations du voisin, mais la valeur Semi-duplex par défaut.

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

  • PR 3251981 : un fichier NFSv4.1 peut sembler vide, même s'il contient des données

    Lorsque vous ouvrez un fichier NFSv4.1 existant avec un accès en écriture seule, si, pour une raison quelconque, le client NFS ouvre à nouveau le même fichier avec un accès en lecture seule, les opérations de lecture du client peuvent ne renvoyer aucune donnée bien que le fichier ne soit pas vide.

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

  • PR 3116601 : lorsque vous remplacez la passerelle par défaut de l'adaptateur VMkernel vSAN sur un hôte ESXi, l'agent vSphere HA sur l'hôte s'affiche comme étant inaccessible

    Dans certains cas, lorsque vous remplacez la passerelle par défaut pour l'adaptateur VMkernel vSAN sur un hôte ESXi, Fault Domain Manager (FDM), qui est l'agent que vSphere HA déploie sur les hôtes ESX, peut cesser de recevoir des pings ICMP (Internet Control Message Protocol). Par conséquent, FDM peut émettre de fausses alarmes de cluster indiquant que l'agent vSphere HA sur l'hôte ne peut pas accéder à certaines adresses réseau de gestion pour d'autres hôtes.

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

  • PR 3251801 : une opération vSphere vMotion à partir d'un hôte ESXi 6.7.x avec un CPU Intel Ice Lake échoue avec l'erreur msg.checkpoint.cpucheck.fail

    Les opérations vSphere vMotion à l'aide de vSphere Client ou de VMware Hybrid Cloud Extension (HCX) à partir d'un hôte avec un CPU Intel Ice Lake qui exécute ESXi 6.7.x échoue avec une erreur telle que msg.checkpoint.cpucheck.fail. Dans vSphere Client, vous voyez un message indiquant que cpuid.PSFD n'est pas pris en charge sur l'hôte cible. Dans HCX, vous voyez un rapport tel que A general system error occurred: vMotion failed:.

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

  • PR 3224739 : vous voyez des alarmes pour les messages Syslog abandonnés

    Si le débit réseau de votre système vSphere ne correspond pas à la vitesse à laquelle les messages de journal sont générés, certains messages de journal envoyés au serveur Syslog distant peuvent être abandonnés. Par conséquent, dans vSphere Client, vous voyez des erreurs d'hôte de type Triggered Alarm et vous voyez dans les journaux des avertissements tels que ALERT: vmsyslog logger xxxx:514 lost yyyy log messages.

    Ce problème est résolu dans cette version. Le correctif améliore les performances de journalisation réseau du service de journalisation pour réduire le nombre de ces messages de journal perdus.

  • PR 3247027 : si une panne se produit lors d'une migration vSphere vMotion de la machine virtuelle NVIDIA Virtual GPU (vGPU), l'hôte ESXi de destination peut échouer avec un écran de diagnostic violet

    Dans de très rares cas, si un type de panne se produit lors d'une migration vSphere vMotion d'une machine virtuelle vGPU, l'opération vMotion est marquée comme un échec lorsqu'une opération interne spécifique est en cours. Par conséquent, l'hôte ESXi de destination peut échouer avec un écran de diagnostic violet.

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

  • PR 3095511 : le service SFCB échoue par intermittence et génère des fichiers « sfcb-vmware_bas-zdump » sur plusieurs hôtes ESXi

    Dans de très rares cas, lorsque le service SFCB tente d'accéder à une variable non initialisée, le service peut échouer avec un fichier de vidage tel que sfcb-vmware_bas-zdump.000. Ce problème se produit, car l'accès à une variable non initialisée peut amener le processus SFCB à continuer de demander de la mémoire jusqu'à ce qu'il dépasse l'allocation de segment de mémoire.

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

  • PR 3256804 : le serveur de fichiers perd la connectivité après le basculement lors de l'exécution du service de fichiers vSAN sur le réseau de superposition NSX

    Si le service de fichiers vSAN est en cours d'exécution sur un réseau de superposition NSX, le serveur de fichiers peut perdre la connectivité après le basculement d'une machine virtuelle d'agent vers une autre machine virtuelle d'agent. Le serveur de fichiers peut basculer lors de la reconfiguration d'un domaine de service de fichiers sans Active Directory (AD) vers un tel domaine de service avec AD, ou si vSAN détecte un comportement défectueux dans le serveur de fichiers, le partage de fichiers ou le serveur AD. Si la connectivité au serveur de fichiers est perdue après un basculement, les clients du service de fichiers ne peuvent pas accéder au partage de fichiers. L'avertissement de santé suivant peut être signalé :

    One or more DNS servers is not reachable.

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

  • PR 3217633 : le service de gestion vSAN sur l'hôte d'orchestration ne fonctionne pas correctement lors du redémarrage de vCenter

    Ce problème peut se produire sur les clusters vSAN sur lesquels vCenter est déployé. Si plusieurs opérations d'arrêt de cluster sont effectuées, le fichier/etc/vmware/vsan/vsanperf.conf sur l'hôte d'orchestration peut contenir deux versions de la machine virtuelle de gestion suivante : vc_vm_moIdvc_vm_moid Ces options de configuration sont en conflit les unes avec les autres et peuvent entraîner un dysfonctionnement du service de gestion vSAN.

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

  • PR 3224306 : lorsque vous modifiez le paramètre du Syslog ESXi syslog.global.logDir, si syslog.global.logDirUnique est actif, vous pouvez voir 2 niveaux de sous-répertoires <hostname> sous le chemin logdir

    Après la mise à niveau d'un hôte ESXi vers la version 7.0 Update 3c et versions ultérieures, si vous modifiez le paramètre Syslog syslog.global.logDir et que le paramètre syslog.global.logDirUnique est actif, vous pouvez voir 2 niveaux de sous-répertoires <hostname> sous le chemin d'accès logdir sur l'hôte. Le paramètre syslog.global.logDirUnique est utile si le même répertoire NFS est configuré en tant que Syslog.global.LogDir par plusieurs hôtes ESXi, car il crée un sous-répertoire avec le nom de l'hôte ESXi sous logdir.

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

  • PR 3223755 : le démon Syslog d'ESXi ne parvient pas à reprendre la transmission des journaux au serveur Syslog distant SSL configuré lorsqu'une perte de connectivité réseau est restaurée

    Si un serveur Syslog SSL distant perd temporairement la connectivité, le démon Syslog d'ESXi peut ne pas reprendre la transmission des journaux après la restauration de la connectivité et vous devez redémarrer le service pour réactiver les transmissions. Ce problème se produit en raison d'exceptions non gérées lorsque le démon Syslog d'ESXi tente de restaurer la connexion au serveur Syslog distant SSL.

    Ce problème est résolu dans cette version. Le correctif ajoute une capture générique pour toutes les exceptions non gérées.

  • PR 3185536 : erreur de correction de cluster vSAN après la mise à niveau de vCenter vers la version 7.0 Update 3

    Lorsque vous mettez à niveau vCenter de la version 6.5.x vers la version 7.0 Update 3 et que vous reconfigurez le cluster vSAN, une correction de cluster vSAN est déclenchée, mais échoue dans certains cas.

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

  • PR 3110401 : le paramètre Notification explicite de congestion (ECN, Explicit Congestion Notification) n'est pas persistant lors du redémarrage de l'hôte ESXi

    L'ECN, spécifiée dans RFC 3168, permet à un expéditeur TCP de réduire le taux de transmission pour éviter les abandons de paquets. Cette fonctionnalité est activée par défaut. Cependant, si vous modifiez le paramètre par défaut ou désactivez manuellement l'ECN, ces modifications apportées à la configuration ESXi peuvent ne pas persister après un redémarrage de l'hôte.

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

  • PR 3153395 : lors de l'actualisation, certaines règles de pare-feu dynamiques peuvent ne pas persister et entraîner l'échec du service cible iSCSI vSAN

    Si vous exécutez fréquemment la commande esxcli network firewall refresh, une condition de concurrence peut entraîner la suppression de certaines règles de pare-feu dynamiques lors de l'actualisation ou du chargement. Par conséquent, certains services tels que le démon cible vSAN iSCSI, qui fournit un stockage vSAN avec le protocole iSCSI, peuvent échouer.

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

  • PR 3096769 : vous voyez une latence élevée pour les opérations d'E/S de machine virtuelle dans un cluster vSAN dans lequel Unmap est activé

    Ce problème affecte les clusters vSAN dans lesquels Unmap est activé. Un problème lors de la gestion de l'opération Unmap dans LSOM crée un encombrement des journaux. L'encombrement des journaux peut entraîner une latence d'E/S de machine virtuelle élevée.

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

  • PR 3163361 : le paramètre Capacité de stockage des enregistrements d'audit n'est pas conservé lors des redémarrages de l'hôte ESXi

    Après un redémarrage de l'hôte ESXi, vous voyez le paramètre Capacité de stockage des enregistrements d'audit restauré à la valeur par défaut de 4 Mo, quelles que soient les modifications précédentes.

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

  • PR 3162496 : Si le protocole ICMPA (Internet Control Message Protocol) n'est pas actif, le redémarrage de l'hôte ESXi peut prendre beaucoup de temps après la mise à niveau vers vSphere 8.0 et versions ultérieures

    Si le protocole ICMPA n'est pas actif sur les serveurs NFS de votre environnement, après la mise à niveau de votre système vers vSphere 8.0 et versions ultérieures, le redémarrage de l'hôte ESXi peut prendre une heure, car les opérations de restauration des banques de données NFS échouent. NFS utilise l'utilitaire vmkping pour identifier les adresses IP accessibles des serveurs NFS avant d'exécuter une opération de montage et, lorsque le protocole ICMP n'est pas actif, les opérations de montage échouent.

    Ce problème est résolu dans cette version. Pour supprimer la dépendance sur le protocole ICMP afin de rechercher des adresses IP accessibles, le correctif ajoute des API de socket pour garantir que les adresses IP sur un serveur NFS donné sont disponibles.

  • PR 3220004 : les machines virtuelles Windows sur lesquelles la VBS est activée peuvent échouer avec un écran de diagnostic bleu lorsqu'un hôte ESXi subit une pression de mémoire

    Les machines virtuelles Windows sur lesquelles la sécurité basée sur la virtualisation (VBS) est activée peuvent échouer par intermittence avec un écran de diagnostic bleu lors d'opérations qui contiennent beaucoup de mémoire, telles que la suppression de snapshots ou la consolidation de disques. Le BSOD comprend la signature suivante :

    DRIVER_VERIFIER_DMA_VIOLATION (e6)

    An illegal DMA operation was attempted by a driver being verified.

    Arguments :

    Arg1: 0000000000000026, IOMMU detected DMA violation.

    Arg2: 0000000000000000, Device Object of faulting device.

    Arg3: xxxxxxxxxxxxxxxx, Faulting information (usually faulting physical address).

    Arg4: 0000000000000008, Fault type (hardware specific).

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

  • PR 3162905 : les hôtes ESXi peuvent se déconnecter de vCenter par intermittence en cas de panne de mémoire

    Dans de rares cas, si vCenter ne parvient pas à allouer ou à transférer des bitmaps actifs en raison d'une alerte de mémoire insuffisante pour une raison quelconque, le service hostd peut échouer à plusieurs reprises et vous ne pouvez pas reconnecter l'hôte à vCenter.

    Ce problème est résolu dans cette version. Le correctif s'assure que dans de tels cas, vous voyez une erreur plutôt que l'échec du service hostd.

  • PR 3108979 : le transfert des correctifs ESXi et des tâches de mise à niveau ESXi peut cesser de répondre indéfiniment en raison d'une limite de tampon de journal

    Si une chaîne ou un journal volumineux dépasse la limite de tampon de journal Python de 16 Ko, la journalisation cesse de répondre. Par conséquent, lorsque vous transférez des correctifs ESXi sur un hôte à l'aide de vSphere Client, le processus chargé de terminer la tâche de transfert sur ESXi peut cesser de répondre indéfiniment. La tâche expire et signale une erreur. Ce problème se produit également lorsque vous corrigez des hôtes ESXi à l'aide d'une ligne de base de correctifs.

    Ce problème est résolu dans cette version. Le correctif divise la chaîne d'entrée volumineuse en fragments plus petits pour la journalisation.

  • PR 3219264 : la vérification préalable vSAN du mode de maintenance ou de la désaffectation du disque ne répertorie pas les objets susceptibles de perdre l'accès

    Ce problème affecte les objets avec des composants se resynchronisant, lorsque certains composants résident sur un périphérique à supprimer ou à placer en mode de maintenance. Lorsque vous exécutez une vérification préalable avec l'option No-Action, la vérification préalable n'évalue pas correctement l'objet pour le signaler dans la liste inaccessibleObjects.

    Ce problème est résolu dans cette version. La vérification préalable inclut tous les objets affectés dans la liste inaccessibleObjects.

  • PR 3186545 : Les analyses de vulnérabilité peuvent signaler la méthode HTTP TRACE comme vulnérable sur les ports 9084 et 9087 de vCenter

    Certains outils tiers d'analyses de vulnérabilité peuvent signaler la méthode HTTP TRACE comme vulnérable sur les ports 9084 et 9087 de vCenter

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

  • PR 3221591 : L'initiateur ESXi NVMe/TCP ne parvient pas à récupérer les chemins après une récupération d'échec de la cible

    Lorsqu'une cible NVMe/TCP récupère d'un échec, ESXi ne peut pas récupérer le chemin.

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

  • PR 3186351 : vous voyez un indicateur de remplacement de la stratégie d'association de NIC, de sécurité ou de formation du trafic sur un groupe de ports activé de manière inattendue après un redémarrage de l'hôte ESXi

    Dans certains cas, une configuration de mise en réseau peut ne pas persister dans ESXi ConfigStore et vous voyez un indicateur de remplacement de la stratégie d'association de NIC, de sécurité ou de formation du trafic sur un groupe de ports activé de manière inattendue après un redémarrage de l'hôte ESXi.

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

  • PR 3162790 : le démon sfcb peut échouer avec un vidage de mémoire lors de l'installation d'un fournisseur CIM tiers

    Le démon sfcb peut tenter d'accéder à la mémoire déjà libérée lors de l'enregistrement d'un fournisseur CIM et échouer avec un vidage de mémoire lors de l'installation d'un fournisseur CIM tiers, tel que Dell OpenManage Server Administrator.

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

  • PR 3157195 : Les hôtes ESX peuvent échouer avec un écran de diagnostic violet et une erreur NMI IPI : Panic requested by another PCPU.

    Le cache du pool de ressources est un cache de niveau volume spécifique à VMFS qui stocke les clusters de ressources correspondant au volume VMFS. Lors de la recherche de clusters prioritaires, le workflow de vidage du cache effectue une itération dans une liste volumineuse de clusters de ressources mis en cache, ce qui peut entraîner le blocage des CPU physiques. De ce fait, les hôtes ESX peuvent échouer avec un écran de diagnostic violet. Dans le fichier logDump, vous voyez une erreur telle que :

    ^[[7m2022-10-22T07:56:47.322Z cpu13:2101160)WARNING: Heartbeat: 827: PCPU 0 didn't have a heartbeat for 7 seconds, timeout is 14, 1 IPIs sent; *may* be locked up.^[[0m^

    [[31;1m2022-10-22T07:56:47.322Z cpu0:2110633)ALERT: NMI: 710: NMI IPI: RIPOFF(base):RBP:CS

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

  • PR 3230493 : si une synchronisation delta s'exécute alors que le serveur vSphere Replication cible n'est pas actif, les machines virtuelles Windows peuvent cesser de répondre

    Si le serveur vSphere Replication cible n'est pas actif lors d'une synchronisation delta, le processus de synchronisation ne peut pas se terminer et les machines virtuelles cessent de répondre.

    Ce problème est résolu dans cette version. Le correctif s'assure qu'aucune tâche de synchronisation delta ne démarre lorsqu'un serveur vSphere Replication n'est pas actif.

  • PR 3122037 : La base de données ESXi ConfigStore se remplit et les écritures échouent

    Les données périmées liées aux périphériques de traitement par blocs peuvent ne pas être supprimées à temps de la base de données ESXi ConfigStore et entraîner une condition de manque d'espace. De ce fait, les opérations d'écriture dans ConfigStore commencent à échouer. Dans la trace de débogage, vous voyez des entrées de journaux telles que :

    2022-12-19T03:51:42.733Z cpu53:26745174)WARNING: VisorFSRam: 203: Cannot extend visorfs file /etc/vmware/configstore/current-store-1-journal because its ramdisk (configstore) is full.

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

  • PR 3246132 : vous voyez une dérive d'horloge système sur un hôte ESXi après l'échec d'une synchronisation avec le serveur NTP

    Si la connectivité entre le serveur NTP et un hôte ESXi est retardée pour une raison quelconque, l'horloge système sur l'hôte ESXi peut subir une dérive. Lorsque vous exécutez la commande vsishvsish -e get /system/ntpclock/clockData, vous pouvez voir une grande valeur négative pour le champ adjtime. Par exemple :

    NTP clock data {  
...  adjtime() (usec):-309237290312 <<<<<<  
...
}

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

  • PR 3185560 : les opérations vSphere vMotion pour les machines virtuelles comportant des fichiers d'échange sur une banque de données vSphere Virtual Volumes échouent par intermittence après une extension à chaud du disque de machine virtuelle

    Les opérations vSphere vMotion pour les machines virtuelles comportant des fichiers d'échange sur une banque de données vSphere Virtual Volumes peuvent échouer dans les circonstances suivantes :

    Une machine virtuelle qui s'exécute sur l'hôte ESXi A est migrée vers l'hôte ESXi B, puis le disque de machine virtuelle est étendu à chaud et la machine virtuelle est migrée de nouveau vers l'hôte ESXi A. Ce problème se produit en raison de statistiques périmées sur le volume virtuel d'échange.

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

  • PR 3236207 : vous ne pouvez pas démonter une banque de données NFS v3 d'un système vCenter, car la banque de données s'affiche comme étant inaccessible

    Lors du démontage d'une banque de données NFSv3 d'un système vCenter à l'aide de vSphere Client ou d'ESXCLI, vous pouvez voir la banque de données comme étant inaccessible ou obtenir une erreur Unable to Refresh. Ce problème se produit lorsqu'une actualisation du cache hostd se produit avant que NFS supprime les détails de montage de ConfigStore, ce qui crée une condition de concurrence rare.

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

  • PR 3236064 : les analyses de conformité ou de correction utilisant vSphere Lifecycle Manager peuvent prendre beaucoup de temps sur les hôtes ESXi disposant d'un grand nombre de banques de données

    Les analyses de conformité ou de correction à l'aide de vSphere Lifecycle Manager incluent une vérification préalable à la mise à niveau qui répertorie tous les volumes attachés à un hôte ESXi, leur espace libre, leurs versions et d'autres détails. Si de nombreuses banques de données sont attachées à un hôte, chacune disposant d'une grande capacité, la vérification préalable peut prendre beaucoup de temps. La durée est multipliée par le nombre de lignes de base attachées au cluster ou à l'hôte.

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, déconnectez les banques de données attachées lors de l'exécution des analyses de correction ou de conformité, puis reconnectez-les une fois les opérations terminées.

  • PR 3245763 : lors d'une opération vSphere vMotion, les hôtes de destination ESXi avec un pare-feu distribué (DFW) activé peuvent échouer avec un écran de diagnostic violet

    Si un DFW est activé sur l'hôte de destination d'une opération vSphere vMotion, une condition de concurrence rare peut entraîner l'échec de l'hôte avec un écran de diagnostic violet.

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

  • PR 3158866 : les machines virtuelles peuvent cesser de répondre lors de l'extension de volume VMFS en raison d'une vérification LVM (Logical Volume Manager)

    Si une opération d'extension de volume VMFS se produit lors d'une sonde LVM pour mettre à jour les attributs de volume, comme la taille de la partition VMFS qui prend en charge le volume VMFS, la taille actuelle du volume VMFS peut ne pas correspondre aux métadonnées LVM sur le disque. Par conséquent, LVM marque un tel volume comme hors ligne et les machines virtuelles sur ce volume cessent de répondre.

    Ce problème est résolu dans cette version. Le correctif améliore le contrôle d'entrée/sortie (IOCTL, Input Output Control) pour accélérer la mise à jour des attributs du périphérique et éviter de tels cas.

  • PR 3152717 : les workflows vSphere Auto Deploy peuvent échouer après une mise à niveau vers vCenter Server 7.0 Update 3j ou version ultérieure

    En raison d'un problème de mise en réseau dans les environnements de configuration de proxy inverse, les workflows vSphere Auto Deploy peuvent échouer après une mise à niveau vers vCenter Server 7.0 Update 3j ou version ultérieure. Dans la console de gestion ESXi et dans le/var/log/vmware/rbd/rbd-cgi.log file, vous voyez une erreur de client HTTP.

    Ce problème est résolu dans cette version. Le correctif s'assure que les workflows Auto Deploy s'exécutent correctement dans les environnements de configuration de proxy inverse.

  • PR 3185125 : la table SLIT virtuelle n'est pas renseignée pour le SE invité lors de l'utilisation de sched.nodeX.affinity

    Lorsque vous spécifiez l'affinité de nœud NUMA virtuel, la table vSLIT peut ne pas être renseignée et l'erreur suivante s'affiche dans vmware.log : vSLIT: NumaGetLatencyInfo failed with status: 195887107.

    Cela se produit lors de la définition de l'affinité de nœud comme suit :

    numa.slit.enable = "TRUE"

    sched.node0.affinity = 0

    sched.node1.affinity = 1

    ...sched.nodeN.affinity = N

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, spécifiez l'affinité VCPU aux CPU physiques sur les nœuds NUMA associés, au lieu de l'affinité de nœud.

    Par exemple :

    numa.slit.enable = "TRUE"

    sched.vcpu0.affinity = "0-7"

    sched.vcpu1.affinity = "0-7"

    ...sched.vcpuN.affinity = "Y-Z"

  • PR 3181774 : vous ne voyez pas d'erreur lorsque vous attachez un FCD avec CBT activé à une machine virtuelle sur laquelle le CBT est désactivé

    L'attachement d'un disque de première classe (FCD, First Class Disk) avec le suivi de modification des blocs (CBT, Changed Block Tracking) à une machine virtuelle sur laquelle le CBT est désactivé ne génère pas d'erreur détaillée, mais l'opération ne peut pas être appliquée. Dans la trace de débogage, vous pouvez voir un message d'erreur tel que InvalidState, qui est générique et ne fournit pas de détails sur le problème.

    Ce problème est résolu dans cette version. Le correctif ajoute le message d'erreur Cannot attach a CBT enabled fcd: {path} to CBT disabled VM. aux journaux du service hostd et ajoute un message d'état pour la tâche dans vSphere Client.

  • PR 3185827 : Vous voyez des fichiers d'interruption dans un répertoire SNMP sous /var/spool, même si SNMP n'est pas activé

    Après le démarrage du service hostd, par exemple après un redémarrage de l'hôte ESXi, le service peut créer un répertoire SNMP sous /var/spool et vous voyez de nombreux fichiers .trp s'accumuler dans ce répertoire.

    Ce problème est résolu dans cette version. Le correctif s'assure que le répertoire /var/spool/snmp existe uniquement lorsque SNMP est activé.

  • PR 3082867 : un hôte ESXi peut échouer avec un écran de diagnostic violet après la migration d'une machine virtuelle répliquée vers l'hôte

    Dans certains environnements, lorsqu'une machine virtuelle répliquée migre vers un hôte ESXi spécifique, lors d'une synchronisation complète, certaines commandes SCSI WRITE peuvent cibler des plages d'adresses au-delà de la fin du mappage de transfert. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet et une trace de débogage semblable à celle-ci s'affiche :

    #0 DLM_free (msp=0x43238f2c9cc0, mem=mem@entry=0x43238f6db860, allowTrim=allowTrim@entry=1 '\001') at bora/vmkernel/main/dlmalloc.c:4924

    #1 0x000041802a151e01 in Heap_Free (heap=0x43238f2c9000, mem=<optimized out>) at bora/vmkernel/main/heap.c:4217

    #2 0x000041802a3b0fa1 in BitVector_Free (heap=<optimized out>, bv=<optimized out>) at bora/vmkernel/util/bitvector.c:94

    #3 0x000041802b9f4f3f in HbrBitmapFree (bitmap=<optimized out>) at bora/modules/vmkernel/hbr_filter/hbr_bitmap.c:91

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

  • PR 3162499 : lors de l'insertion de services pour les machines virtuelles de charge de travail gérées par NSX, certaines machines virtuelles peuvent cesser de répondre par intermittence et le périphérique virtuel peut se réinitialiser

    Lors de l'insertion de services pour les machines virtuelles de charge de travail gérées par NSX, une liste de paquets peut être réinjectée de la chaîne d'entrée d'un port de commutateur vers un autre port de commutateur. Dans ce cas, le port de commutateur source ne correspond pas au portID réel de la chaîne d'entrée et le périphérique virtuel n'obtient pas l'état d'achèvement de la trame transmise. De ce fait, lorsque vous exécutez une tâche d'insertion de services, certaines machines virtuelles peuvent cesser de répondre par intermittence en raison de problèmes de connectivité réseau.

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

  • PR 3219441 : vous ne pouvez pas envoyer de clés à un SE invité à l'aide de la console de navigateur dans ESXi Host Client

    Dans ESXi Host Client, lorsque vous ouvrez la console de navigateur d'une machine virtuelle et que vous sélectionnez SE invité > Envoyer les clés, lorsque vous sélectionnez une entrée de clé (par exemple, Ctrl-Alt-Delete), la sélection n'est pas envoyée au système d'exploitation invité.

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

  • PR 3209853 : les machines virtuelles Windows peuvent échouer avec un écran de diagnostic bleu avec une signature 0x5c en raison de retards de plate-forme

    Les machines virtuelles Windows peuvent échouer avec un écran de diagnostic bleu et la signature suivante en raison d'une combinaison de facteurs impliquant le code de temporisateur Windows et des retards de plate-forme, tels que des retards de stockage ou de réseau :

    HAL_INITIALIZATION_FAILED (0x5c) (Cela indique que l'initialisation HAL a échoué.)

    Arguments :

    Arg1: 0000000000000115, HAL_TIMER_INITIALIZATION_FAILURE

    Arg2: fffff7ea800153e0, Timer address

    Arg3: 00000000000014da, Delta in QPC units (delta to program the timer with)

    Arg4: ffffffffc0000001, invalid status code (STATUS_UNSUCCESSFUL)

    Les vérifications effectuées par les temporisateurs HPET dans Windows peuvent échouer en raison de ces retards de plate-forme et provoquer ce problème.

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

  • PR 3178109 : la vérification de conformité de vSphere Lifecycle Manager échoue avec « Une erreur inconnue s'est produite lors de l'exécution de l'opération »

    L'image ESXi de base contient des composants de pilote qui peuvent être remplacés par des composants de pilote asynchrones de version supérieure fournis par un module complémentaire OEM. Si un tel composant est supprimé manuellement sur un hôte, la vérification de conformité de vSphere Lifecycle Manager peut échouer de manière inattendue. Dans vSphere Client, vous pouvez voir des erreurs telles que Host status is unknown et An unknown error occurred while performing the operation.

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

  • PR 3180634 : Les performances de certaines machines virtuelles imbriquées sur les CPU AMD peuvent se dégrader

    Les machines virtuelles imbriquées sur les CPU AMD disposant de systèmes d'exploitation tels que Windows avec sécurité basée sur la virtualisation (VBS) peuvent subir une dégradation des performances, des délais d'expiration ou une absence de réponse en raison d'un problème de virtualisation de l'indexation de virtualisation rapide (RVI) d'AMD, également appelée Tables de page imbriquées (NTP).

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

  • PR 3223539 : certaines vmnic peuvent ne pas être visibles après un redémarrage de l'hôte ESXi en raison d'un périphérique NVMe défectueux

    Si un périphérique NVMe échoue pendant la phase d'attachement, le pilote NVMe désactive le contrôleur NVMe et réinitialise les ressources de file d'attente matérielle. Lorsque vous tentez de rattacher le périphérique, une non-correspondance entre les pointeurs de file d'attente du matériel et du pilote peut entraîner une panne IOMMU sur le périphérique NVMe, ce qui entraîne une corruption de la mémoire et l'échec du service vmkdevmgr. Par conséquent, vous ne voyez pas certaines vmnic dans votre réseau.

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

  • PR 3218835 : lorsque vous désactivez ou interrompez vSphere Fault Tolerance, les machines virtuelles peuvent cesser de répondre pendant environ 10 secondes

    Lorsque vous désactivez ou interrompez vSphere FT, certaines machines virtuelles peuvent prendre environ 10 secondes pour libérer les ressources vSphere FT. Par conséquent, ces machines virtuelles cessent temporairement de répondre aux demandes réseau ou aux opérations de console.

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

  • PR 3181901 : L'hôte ESXi cesse de répondre et vous ne pouvez pas le mettre en mode de maintenance ou migrer des machines virtuelles à partir de cet hôte

    Les lectures asynchrones de métadonnées sur un volume VMFS attaché à un hôte ESXi peuvent entraîner une condition de concurrence avec d'autres threads sur l'hôte et empêcher l'hôte de répondre. De ce fait, vous ne pouvez pas mettre l'hôte en mode de maintenance ou migrer des machines virtuelles à partir de cet hôte.

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

  • PR 3156666 : les paquets d'une longueur inférieure à 60 octets peuvent être abandonnés

    Un hôte ESXi peut ajouter des octets non valides, autres que zéro, à des paquets de moins de 60 octets. Par conséquent, les paquets avec ces octets non valides sont abandonnés.

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

  • PR 3180283 : Lorsque vous migrez une machine virtuelle avec de la mémoire récemment ajoutée à chaud, un hôte ESXi peut échouer à plusieurs reprises avec un écran de diagnostic violet

    En raison d'une condition de concurrence lorsque le module d'enfichage à chaud de mémoire recalcule la disposition de mémoire NUMA d'une machine virtuelle sur un hôte de destination après la migration, un hôte ESXi peut échouer à plusieurs reprises avec un écran de diagnostic violet. Dans la trace de débogage, vous voyez des erreurs telles que :

    0x452900262cf0:[0x4200138fee8b]PanicvPanicInt@vmkernel#nover+0x327 stack: 0x452900262dc8, 0x4302f6c06508, 0x4200138fee8b, 0x420013df1300, 0x452900262cf0  0x452900262dc0:[0x4200138ff43d]Panic_WithBacktrace@vmkernel#nover+0x56 stack: 0x452900262e30, 0x452900262de0, 0x452900262e40, 0x452900262df0, 0x3e7514  0x452900262e30:[0x4200138fbb90]NMI_Interrupt@vmkernel#nover+0x561 stack: 0x0, 0xf48, 0x0, 0x0, 0x0  0x452900262f00:[0x420013953392]IDTNMIWork@vmkernel#nover+0x7f stack: 0x420049800000, 0x4200139546dd, 0x0, 0x452900262fd0, 0x0  0x452900262f20:[0x4200139546dc]Int2_NMI@vmkernel#nover+0x19 stack: 0x0, 0x42001394e068, 0xf50, 0xf50, 0x0  0x452900262f40:[0x42001394e067]gate_entry@vmkernel#nover+0x68 stack: 0x0, 0x43207bc02088, 0xd, 0x0, 0x43207bc02088  0x45397b61bd30:[0x420013be7514]NUMASched_PageNum2PhysicalDomain@vmkernel#nover+0x58 stack: 0x1, 0x420013be34c3, 0x45396f79f000, 0x1, 0x100005cf757  0x45397b61bd50:[0x420013be34c2]NUMASched_UpdateAllocStats@vmkernel#nover+0x4b stack: 0x100005cf757, 0x0, 0x0, 0x4200139b36d9, 0x0  0x45397b61bd80:[0x4200139b36d8]VmMem_NodeStatsSub@vmkernel#nover+0x59 stack: 0x39, 0x45396f79f000, 0xbce0dbf, 0x100005cf757, 0x0  0x45397b61bdc0:[0x4200139b4372]VmMem_FreePageNoBackmap@vmkernel#nover+0x8b stack: 0x465ec0001be0, 0xa, 0x465ec18748b0, 0x420014e7685f, 0x465ec14437d0

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

  • PR 3100552 : le démarrage d'ESXi expire après cinq minutes et l'hôte redémarre automatiquement

    Lors du démarrage ESXi initial, lorsque la barre de progression Chargement de VMware ESXi s'affiche, si le chargeur de démarrage met plus de cinq minutes à charger tous les modules de démarrage avant de passer à la phase de démarrage suivante, le microprogramme de l'hôte fait expirer le processus de démarrage et réinitialise le système.

    Ce problème est résolu dans cette version. Avec ESXi 7.0 Update 3o, le chargeur de démarrage ESXi réinitialise le délai d'expiration de cinq minutes après le chargement de chaque module de démarrage.

  • PR 3184368 : Le nom durable d'un LUN SCSI peut ne pas être défini

    La propriété de nom durable pour un périphérique compatible SCSI-3 provient des pages 80h et 83h des données de produit vitales (VPD) telles que définies par les normes T10 et SMI. Pour renseigner le nom durable, ESXi envoie d'abord une commande de requête pour obtenir une liste des pages VPD prises en charge par le périphérique. Ensuite, ESXi émet des commandes pour obtenir des données pour toutes les pages VPD prises en charge. En raison d'un problème avec la baie cible, le périphérique peut faire échouer une commande d'obtention des données de page VPD pour une page de la liste avec une erreur not supported. De ce fait, ESXi ne peut pas renseigner la propriété de nom durable pour le périphérique.

    Ce problème est résolu dans cette version. Le correctif ignore l'erreur sur la commande d'obtention des données de page VPD, à l'exception des pages 80h et 83h, si ces données ne sont pas requises pour la génération d'un nom durable.

  • PR 3184425 : l'analyse de port d'un VTEP (VXLAN Tunnel End Point) sur un hôte ESXi peut entraîner une perte de connectivité intermittente

    L'analyse de port d'un VTEP sur un hôte ESXi peut entraîner une perte de connectivité intermittente, mais uniquement dans les conditions suivantes :

    1. Votre environnement comporte de nombreux VTEP.

    2. Tous les VTEP se trouvent dans le même sous-réseau IP.

    3. Le commutateur en amont est Cisco ACI.

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

  • PR 3156627 : la modification du mode du disque virtuel sur une machine virtuelle en cours d'exécution peut entraîner l'échec de celle-ci

    Si vous utilisez VMware Host Client pour modifier le mode de disque d'une machine virtuelle en cours d'exécution, par exemple de Indépendant - Non persistant à Dépendant ou Indépendant - Persistant, l'opération échoue et peut entraîner l'échec de la machine virtuelle. Dans le fichier vmware.log, vous pouvez voir des erreurs telles que :

    msg.disk.notConfigured2] Failed to configure disk 'scsi0:4'. The virtual machine cannot be powered on with an unconfigured disk.

    [msg.checkpoint.continuesync.error] An operation required the virtual machine to quiesce and the virtual machine was unable to continue running.

    Ce problème est résolu dans cette version. Le correctif bloque la modification à l'aide de VMware Host Client du mode d'un disque Indépendant - Non persistant sur une machine virtuelle en cours d'exécution. vSphere Client bloque déjà ces opérations.

  • PR 3164477 : dans VMware Skyline Health Diagnostics, plusieurs avertissements s'affichent pour les pools de mémoire vSAN

    La logique d'estimation de la mémoire libre du segment de mémoire pour certains pools de mémoire vSAN peut tenir compte d'un segment de mémoire supérieur à la valeur réelle et déclencher des avertissements en cas de mémoire insuffisante. Par conséquent, vous voyez des avertissements de santé Memory pools (heap) pour de nombreux hôtes sous la section Disques physiques dans Skyline Health.

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

  • PR 3168950 : les hôtes ESXi échouent avec un écran de diagnostic violet lors de l'installation de VMware NSX-T Data Center en raison d'un espace de segment TCP/IP insuffisant

    VMware NSX-T Data Center dispose de plusieurs piles réseau et l'espace de segment TCP/IP par défaut peut ne pas être suffisant pour l'installation. Par conséquent, les hôtes ESXi peuvent échouer avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version. Le correctif augmente le paramètre TcpipHeapSize par défaut de 0 Mo à 8 Mo et la taille maximale de 32 Mo à 128 Mo. Dans vSphere Client, vous pouvez modifier la valeur TcpipHeapSize en accédant à Hôtes et clusters > Configurer > Système > Paramètres système avancés > TcpipHeapSize. Dans les systèmes vCenter avec VMware NSX-T Data Center, définissez la valeur sur 128 Mo.

  • PR 3096974 : une condition de concurrence rare dans les filtres d'E/S peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet

    Les hôtes ESXi dans lesquels les machines virtuelles utilisent des filtres d'E/S peuvent échouer de manière aléatoire avec un écran de diagnostics violet et une erreur telle que #DF Exception 8 IP 0x42002c54b19f SP 0x453a9e8c2000 en raison d'une condition de concurrence rare.

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

  • PR 3112194 : Spherelet peut ne pas démarrer sur un hôte ESXi en raison du paramètre execInstalledOnly

    Le paramètre execInstalledOnly est un paramètre d'exécution qui limite l'exécution des fichiers binaires tels que les applications et les modules VMkernel afin d'améliorer la sécurité et de se protéger contre les violations et les compromissions. Certaines vérifications de sécurité execInstalledOnly peuvent interférer avec Spherelet, l'agent ESXi UserWorld qui agit comme une extension du plan de contrôle Kubernetes, et peut l'empêcher de démarrer, même lorsque tous les fichiers sont installés.

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

  • PR 3115870 : L'installation de VIB VMware peut échouer lors d'installations simultanées de modules de fournisseur

    Lorsque vous installez des modules de mise à jour de plusieurs fournisseurs, tels que JetStream Software, Microsoft et VMware, plusieurs clients appellent les mêmes API PatchManager et peuvent entraîner une condition de concurrence. De ce fait, l'installation des modules d'installation de VMware (VIB) peut échouer. Dans les journaux, vous voyez une erreur telle que vim.fault.PlatformConfigFault, qui est une erreur générique indiquant qu'une erreur s'est produite concernant la configuration de l'hôte ESXi. Dans vSphere Client, vous voyez un message tel que An error occurred during host configuration.

    Ce problème est résolu dans cette version. Le correctif consiste à renvoyer un avertissement TaskInProgress au lieu de PlatformConfigFault, afin que vous soyez informé du problème réel et puissiez réessayer l'installation.

  • PR 3164439 : Certaines applications peuvent occuper trop de handles de fichiers ESXi et entraîner une détérioration des performances

    Dans de très rares cas, des applications telles que NVIDIA virtual GPU (vGPU) peuvent consommer tellement de handles de fichiers que ESXi ne parvient pas à traiter d'autres services ou machines virtuelles. De ce fait, vous pouvez voir le GPU disparaître sur certains nœuds ou signaler une mémoire GPU nulle, ou constater une dégradation des performances.

    Ce problème est résolu dans cette version. Le correctif réduit le nombre de handles de fichiers qu'une machine virtuelle vGPU peut consommer.

  • PR 3162963 : Si des opérations parallèles de développement de volume et d'actualisation de volume sur le même volume VMFS s'exécutent sur deux hôtes ESXi dans le même cluster, le volume VMFS peut se déconnecter

    Pendant qu'une opération de développement de volume VMFS est en cours sur un hôte ESXi dans un cluster vCenter, si, sur un autre hôte, un utilisateur ou vCenter lance une actualisation de la même capacité de volume VMFS, ce volume peut se déconnecter. Ce problème se produit en raison d'une éventuelle non-concordance entre la taille du périphérique, qui est inscrite sur le disque dans les métadonnées du volume lors d'une réanalyse du périphérique, et la valeur de la taille du périphérique dans la couche PSA (Pluggable Storage Architecture) sur l'hôte, qui peut ne pas être mise à jour si la réanalyse du périphérique n'est pas terminée.

    Ce problème est résolu dans cette version. Le correctif améliore la résilience du code du gestionnaire de volume pour forcer une actualisation consécutive des attributs du périphérique et une nouvelle comparaison des tailles du périphérique si vCenter signale une non-correspondance de la taille du périphérique.

  • PR 3161690 : l'utilisation du CPU des hôtes ESXi peut augmenter par intermittence dans certains environnements

    En raison d'une condition de concurrence rare, lorsqu'une commande de mise hors tension de machine virtuelle est en conflit avec une fonction de rappel, vous pouvez observer une augmentation de l'utilisation du CPU sur les hôtes ESXi (par exemple, après une mise à niveau).

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

  • PR 3165374 : les hôtes ESXi peuvent cesser de répondre et échouer avec un écran de diagnostic violet au cours de TIME_WAIT TCP

    Le temporisateur lent TCP peut bloquer le traitement d'entrée TCP alors qu'il couvre la liste des connexions dans TIME_WAIT qui ferment les connexions expirées en raison d'une contention sur le verrouillage pcbinfo TCP global. Par conséquent, VMkernel peut échouer avec un écran de diagnostic violet et l'erreur Spin count exceeded - possible deadlock lors du nettoyage des sockets TCP TIME_WAIT. La trace de débogage pointe vers des fonctions tcpip telles que tcp_slowtimo() ou tcp_twstart().

    Ce problème est résolu dans cette version. Le correctif ajoute un nouveau verrou global pour protéger la liste des connexions dans TIME_WAIT et pour acquérir le verrou tcpinfo TCP uniquement lors de la fermeture d'une connexion expirée.

  • PR 3166818 : si l'un des points de montage qui utilisent la même adresse IP de serveur NFS renvoie une erreur, VAAI-NAS peut marquer tous les points de montage comme non pris en charge

    Lorsque vous utilisez un plug-in de fournisseur VAAI-NAS, plusieurs systèmes de fichiers sur un hôte ESXi utilisent la même adresse IP de serveur NFS pour créer une banque de données. Pour certains fournisseurs NAS, si l'un des montages renvoie une erreur VIX_E_OBJECT_NOT_FOUND (25) lors de l'appel startSession, l'accélération matérielle de tous les systèmes de fichiers ayant la même adresse IP de serveur NFS peut ne plus être prise en charge. Ce problème se produit lorsqu'un hôte ESXi monte un répertoire sur un serveur NFS, mais que ce répertoire n'est pas disponible au moment de l'appel startSession (par exemple, parce qu'il a été déplacé de ce serveur NFS).

    Ce problème est résolu dans cette version. Le correctif s'assure que VAAI-NAS marque comme non pris en charge uniquement les montages qui signalent une erreur.

  • PR 3100030 : un hôte ESXi échoue avec un écran de diagnostic violet indiquant une corruption du segment de mémoire VMFS

    Une condition de concurrence dans le cache de l'hôte d'une banque de données VMFS peut entraîner une corruption du segment de mémoire et l'hôte ESXi échoue avec un écran de diagnostic violet et un message tel que :

    PF Exception 14 in world xxxxx:res3HelperQu IP 0xxxxxxe2 addr 0xXXXXXXXXX

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

  • PR 3121216 : si le protocole ICMPA (Internet Control Message Protocol) n'est pas actif, le redémarrage de l'hôte ESXi peut prendre beaucoup de temps après une mise à niveau

    Si le protocole ICMPA n'est pas actif sur les serveurs NFS de votre environnement, après la mise à niveau de votre système, le redémarrage de l'hôte ESXi peut prendre une heure, car les opérations de restauration des banques de données NFS échouent. NFS utilise l'utilitaire vmkping pour identifier les adresses IP accessibles des serveurs NFS avant d'exécuter une opération de montage et, lorsque le protocole ICMP n'est pas actif, les opérations de montage échouent.

    Ce problème est résolu dans cette version. Pour supprimer la dépendance sur le protocole ICMP afin de rechercher des adresses IP accessibles, le correctif ajoute des API de socket pour garantir que les adresses IP sur un serveur NFS donné sont disponibles.

  • PR 3098760 : les hôtes ESXi se déconnectent de manière aléatoire du domaine Active Directory ou vCenter en raison de l'épuisement de la mémoire Likewise

    Des fuites de mémoire dans les opérations Active Directory et les bibliothèques associées, ou lorsque l'authentification par carte à puce est activée sur un hôte ESXi, peuvent entraîner l'épuisement de la mémoire Likewise.

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

  • PR 3118402 : la fonction de surveillance NTP renvoie un échec de synchronisation de l'heure intermittent dans le rapport de test des services de temps, même lorsque l'horloge système de l'hôte ESXi est correctement synchronisée

    L'infrastructure de surveillance des services de temps interroge périodiquement le démon NTP, ntpd, pour obtenir l'état de synchronisation de l'heure sur les hôtes ESXi. Des échecs de requête intermittents peuvent se produire en raison de délais d'expiration dans l'appel de socket pour lire ces informations d'état. Par conséquent, vous pouvez voir des alertes d'échec de synchronisation de l'heure dans les rapports de test NTP.

    Ce problème est résolu dans cette version. Le correctif s'assure que les requêtes de surveillance NTP n'échouent pas.

  • PR 3159168 : plusieurs messages « End path evaluation for device » s'affichent dans le fichier vmkernel.log

    Une sonde de périphérique périodique qui évalue l'état de tous les chemins d'accès à un périphérique peut créer plusieurs messages End path evaluation for device inutiles dans le fichier vmkernel.log sur une build de version.

    Ce problème est résolu dans cette version. Le correctif limite les messages End path evaluation for device aux builds de non-version, telles que les builds bêta. Vous devez activer le niveau de journalisation VERBOSE pour afficher ces journaux.

  • PR 3101512 : vous voyez un avertissement pour une perte de redondance de la liaison montante, même lorsque la liaison montante est active

    Si vous retirez rapidement le câble réseau d'une carte réseau physique et que vous le réinsérez, l'agent hôte ESXi, hostd, déclenche un événement pour restaurer la redondance de la liaison montante. Pourtant, dans certains cas, bien que la liaison montante soit restaurée en une seconde, vous voyez toujours une alarme erronée qui indique une perte de redondance de la liaison montante.

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

  • PR 3161473 : les opérations avec des hôtes ESXi sans état peuvent ne pas choisir le disque distant prévu pour le cache système, ce qui entraîne des problèmes de correction ou de conformité

    Les opérations avec des hôtes ESXi sans état, telles que la migration du stockage, peuvent ne pas choisir le disque distant prévu pour le cache système. Par exemple, vous voulez conserver le nouveau LUN de démarrage en tant que LUN 0, mais vSphere Auto Deploy sélectionne LUN 1.

    Ce problème est résolu dans cette version. Le correctif offre un moyen cohérent de trier les disques distants et de toujours choisir le disque avec l'ID de LUN le plus faible. Pour vous assurer que vous activez le correctif, procédez comme suit :

    1. Sur la page Modifier le profil d'hôte de l'assistant Auto Deploy, sélectionnez Paramètres de configuration avancés > Configuration du cache SystemImage > Configuration du cache de l'image système

    2. Dans le menu déroulant Paramètres de profil du cache d'image système, sélectionnez Activer la mise en cache sans état sur l'hôte.

    3. Modifiez Arguments pour le premier disque en remplaçant remote par sortedremote et/ou remoteesx par sortedremoteesx.

  • PR 3187846 : La définition de la résolution d'écran d'une machine virtuelle chiffrée hors tension ne fonctionne pas toujours lors de la modification manuelle du fichier VMX

    Si vous spécifiez manuellement la résolution d'écran d'une machine virtuelle chiffrée hors tension en modifiant le fichier VMX, il se peut que la modification ne prenne pas effet.

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

esx-update_7.0.3-0.105.22348816

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 concernés

  • VMware_bootbank_loadesx_7.0.3-0.105.22348816

  • VMware_bootbank_esx-update_7.0.3-0.105.22348816

PR résolus

3245953, 3178109, 3211395, 3164477, 3119959, 3164462

Numéros CVE

S.O.

Met à jours les VIB loadesx et esx-update.

Broadcom-lsi-msgpt3_17.00.12.00-2vmw.703.0.105.22348816

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 concernés

  • VMW_bootbank_lsi-msgpt3_17.00.12.00-2vmw.703.0.105.22348816

PR résolus

3036883

Numéros CVE

S.O.

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

  • PR 3036883 : un chemin SAS peut être perdu lors de la mise à niveau de pilotes lsi_msgpt3

    La mise à niveau de pilotes lsi_msgpt3 de version 17.00.12.00-1 et versions antérieures peut entraîner l'arrêt des connexions de stockage et des machines virtuelles sur l'hôte ESXi en raison d'une perte de chemin SAS. Dans les journaux VMkernel, vous voyez des messages d'erreur tels que :

    2022-06-19T05:25:51.949Z cpu26:2097947)WARNING: NMP: nmpDeviceAttemptFailover:640: Retry world failover device "naa.6000d310045e2c000000000000000043" - issuing command 0x459acc1f5dc0

    2022-06-19T05:25:51.949Z cpu26:2097947)WARNING: vmw_psp_rr: psp_rrSelectPath:2177: Could not select path for device "naa.6000d310045e2c000000000000000043".

    2022-06-19T05:25:51.949Z cpu26:2097947)WARNING: NMP: nmpDeviceAttemptFailover:715: Retry world failover device "naa.6000d310045e2c000000000000000043" - failed to issue command due to Not found (APD), try again...

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, réanalysez votre stockage après la restauration sur le contrôleur de stockage pour récupérer les chemins d'accès et les connexions de stockage.

Microchip-smartpqiv2-plugin_1.0.0-9vmw.703.0.105.22348816

Catégorie des correctifs

Correctif de bogues

Gravité des correctifs

Critique

Redémarrage de l'hôte requis

Oui

Migration ou arrêt de la machine virtuelle requis

Non

Matériel concerné

S.O.

Logiciels concernés

S.O.

VIB concernés

  • VMware_bootbank_lsuv2-smartpqiv2-plugin_1.0.0-9vmw.703.0.105.22348816

PR résolus

3112692

Numéros CVE

S.O.

Met à jour le VIB lsuv2-smartpqiv2-plugin pour résoudre le problème suivant :

  • PR 3112692 : le pilote smartpqi ne peut pas obtenir l'emplacement des périphériques SSD SAS ThinkSystem PM1645a

    Dans de rares cas, le smartpqi plugin in LSU service peut obtenir une chaîne de numéro de série plus longue depuis la page VPD 0x80 que le numéro de série réel, et la recherche de périphériques dans le cache échoue. Par conséquent, lorsque vous exécutez la commande esxcli storage core device physical get -d <device_id> pour obtenir l'emplacement d'un périphérique, vous voyez une erreur telle que Unable to get location for device. Device is not found..

    Ce problème est résolu dans cette version. Le correctif s'assure que le smartpqi plugin in LSU service vérifie toujours la longueur correcte du numéro de série et trouve l'emplacement du périphérique.

VMware-NVMe-PCIe_1.2.3.16-3vmw.703.0.105.22348816

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 concernés

  • VMW_bootbank_nvme-pcie_1.2.3.16-3vmw.703.0.105.22348816

PR résolus

3218578

Numéros CVE

S.O.

Met à jour le VIB nvme-pcie pour résoudre le problème suivant :

  • PR 3218578 : vous voyez des descriptions de périphérique incorrectes pour certains adaptateurs RAID de démarrage Lenovo ThinkSystem

    Dans une interface client vSphere (telle que vSphere Client) ou lorsque vous exécutez des commandes telles que lspci et esxcfg-scsidevs -a depuis ESXi Shell, vous pouvez voir les noms de périphérique de certains adaptateurs SATA/NVMe de démarrage Lenovo sous la forme de noms génériques des puces de contrôleur qu'ils utilisent. Par exemple, Lenovo ThinkSystem M.2 avec kit d'activation de la mise en miroir s'affiche sous la forme Contrôleur 88SE9230 PCIe SATA 6 Go/s.

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

VMware-ahci_2.0.11-2vmw.703.0.105.22348816

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 concernés

  • VMW_bootbank_vmw-ahci_2.0.11-2vmw.703.0.105.22348816

PR résolus

3218578

Numéros CVE

S.O.

Met à jour le VIB vmw-ahci.

Intel-Volume-Mgmt-Device_2.7.0.1157-3vmw.703.0.105.22348816

Catégorie des correctifs

Correctif de bogues

Gravité des correctifs

Critique

Redémarrage de l'hôte requis

Oui

Migration ou arrêt de la machine virtuelle requis

Non

Matériel concerné

S.O.

Logiciels concernés

S.O.

VIB concernés

  • VMW_bootbank_iavmd_2.7.0.1157-3vmw.703.0.105.22348816

PR résolus

3224847

Numéros CVE

S.O.

Met à jour le VIB iavmd.

ESXi_7.0.3-0.100.22348808

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 concernés

  • VMware_bootbank_vsanhealth_7.0.3-0.100.22348808

  • VMware_bootbank_crx_7.0.3-0.100.22348808

  • VMware_bootbank_vdfs_7.0.3-0.100.22348808

  • VMware_bootbank_esxio-combiner_7.0.3-0.100.22348808

  • VMware_bootbank_native-misc-drivers_7.0.3-0.100.22348808

  • VMware_bootbank_esx-base_7.0.3-0.100.22348808

  • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.100.22348808

  • VMware_bootbank_cpu-microcode_7.0.3-0.100.22348808

  • VMware_bootbank_bmcal_7.0.3-0.100.22348808

  • VMware_bootbank_esx-ui_2.11.2-21988676

  • VMware_bootbank_gc_7.0.3-0.100.22348808

  • VMware_bootbank_trx_7.0.3-0.100.22348808

  • VMware_bootbank_vsan_7.0.3-0.100.22348808

  • VMware_bootbank_esx-xserver_7.0.3-0.100.22348808

PR résolus

3219441, 3239369, 3236018, 3232099, 3232034, 3222887, 3217141, 3213025, 3187868, 3186342, 3164962, 3089785, 3160789, 3098679, 3089785, 3256457

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 vsanhealth, crx, vdfs, esxio-combiner, native-misc-drivers, esx-base, esx-dvfilter-generic-fastpath, cpu-microcode, bmcal, esx-ui, gc, trx, vsan, et esx-xserver pour résoudre les problèmes suivants :

  • ESXi 7.0 Update 3o fournit les mises à jour de sécurité suivantes :

    • La bibliothèque cURL a été mise à jour vers la version 8.1.2.

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

    • La bibliothèque SQLite a été mise à jour vers la version 3.42.0.

    • Le module OpenSSL a été mis à jour vers la version 1.0.2zh.

  • Le VIB cpu-microcode inclut le microcode AMD suivant :

    Nom de code

    FMS

    Révision de MCU

    Date de MCU

    Noms de marque

    Bulldozer

    0x600f12 (15/01/2)

    0x0600063e

    07/02/2018

    Opteron série 6200/4200/3200

    Piledriver

    0x600f20 (15/02/0)

    0x06000852

    06/02/2018

    Opteron série 6300/4300/3300

    Zen-Naples

    0x800f12 (17/01/2)

    0x0800126e

    11/11/2021

    EPYC série 7001

    Zen2-Rome

    0x830f10 (31/17/0)

    0x0830107a

    17/05/2023

    EPYC série 7002/7Fx2/7Hx2

    Zen3-Milan-B1

    0xa00f11 (19/01/1)

    0x0a0011d1

    10/07/2023

    EPYC série 7003/7003X

    Zen3-Milan-B2

    0xa00f12 (19/01/2)

    0x0a001234

    10/07/2023

    EPYC série 7003/7003X

  • Le VIB cpu-microcode inclut le microcode Intel suivant :

    Nom de code

    FMS

    ID de PLT

    Révision de MCU

    Date de MCU

    Noms de marque

    Nehalem EP

    0x106a5 (06/1a/5)

    0x03

    0x1d

    11/05/2018

    Intel Xeon 35xx Series ; Intel Xeon 55xx Series

    Clarkdale

    0x20652 (06/25/2)

    0x12

    0x11

    08/05/2018

    Intel i3/i5 Clarkdale Series ; Intel Xeon 34xx Clarkdale Series

    Arrandale

    0x20655 (06/25/5)

    0x92

    0x7

    23/04/2018

    Processeur Intel Core i7-620LE

    Sandy Bridge DT

    0x206a7 (06/2a/7)

    0x12

    0x2f

    17/02/2019

    Intel Xeon E3-1100 Series ; Intel Xeon E3-1200 Series ; Intel i7-2655-LE Series ; Intel i3-2100 Series

    Westmere EP

    0x206c2 (06/2c/2)

    0x03

    0x1f

    08/05/2018

    Intel Xeon 56xx Series ; Intel Xeon 36xx Series

    Sandy Bridge EP

    0x206d6 (06/2d/6)

    0x6d

    0x621

    04/03/2020

    Intel Pentium 1400 Series ; Intel Xeon E5-1400 Series ; Intel Xeon E5-1600 Series ; Intel Xeon E5-2400 Series ; Intel Xeon E5-2600 Series ; Intel Xeon E5-4600 Series

    Sandy Bridge EP

    0x206d7 (06/2d/7)

    0x6d

    0x71a

    24/03/2020

    Intel Pentium 1400 Series ; Intel Xeon E5-1400 Series ; Intel Xeon E5-1600 Series ; Intel Xeon E5-2400 Series ; Intel Xeon E5-2600 Series ; Intel Xeon E5-4600 Series

    Nehalem EX

    0x206e6 (06/2e/6)

    0x04

    0xd

    15/05/2018

    Intel Xeon 65xx Series ; Intel Xeon 75xx Series

    Westmere EX

    0x206f2 (06/2f/2)

    0x05

    0x3b

    16/05/2018

    Intel Xeon E7-8800 Series ; Intel Xeon E7-4800 Series ; Intel Xeon E7-2800 Series

    Ivy Bridge DT

    0x306a9 (06/3a/9)

    0x12

    0x21

    13/02/2019

    Intel i3-3200 Series ; Intel i7-3500-LE/UE ; Intel i7-3600-QE ; Intel Xeon E3-1200-v2 Series ; Intel Xeon E3-1100-C-v2 Series ; Intel Pentium B925C

    Haswell DT

    0x306c3 (06/3c/3)

    0x32

    0x28

    12/11/2019

    Intel Xeon E3-1200-v3 Series ; Intel i7-4700-EQ Series ; Intel i5-4500-TE Series ; Intel i3-4300 Series

    Ivy Bridge EP

    0x306e4 (06/3e/4)

    0xed

    0x42e

    14/03/2019

    Intel Xeon E5-4600-v2 Series ; Intel Xeon E5-2600-v2 Series ; Intel Xeon E5-2400-v2 Series ; Intel Xeon E5-1600-v2 Series ; Intel Xeon E5-1400-v2 Series

    Ivy Bridge EX

    0x306e7 (06/3e/7)

    0xed

    0x715

    14/03/2019

    Intel Xeon E7-8800/4800/2800-v2 Series

    Haswell EP

    0x306f2 (06/3f/2)

    0x6f

    0x49

    11/08/2021

    Intel Xeon E5-4600-v3 Series ; Intel Xeon E5-2600-v3 Series ; Intel Xeon E5-2400-v3 Series ; Intel Xeon E5-1600-v3 Series ; Intel Xeon E5-1400-v3 Series

    Haswell EX

    0x306f4 (06/3f/4)

    0x80

    0x1a

    24/05/2021

    Intel Xeon E7-8800/4800-v3 Series

    Broadwell H

    0x40671 (06/47/1)

    0x22

    0x22

    12/11/2019

    Intel Core i7-5700EQ ; Intel Xeon E3-1200-v4 Series

    Avoton

    0x406d8 (06/4d/8)

    0x01

    0x12d

    16/09/2019

    Intel Atom C2300 Series ; Intel Atom C2500 Series ; Intel Atom C2700 Series

    Broadwell EP/EX

    0x406f1 (06/4f/1)

    0xef

    0xb000040

    19/05/2021

    Intel Xeon E7-8800/4800-v4 Series ; Intel Xeon E5-4600-v4 Series ; Intel Xeon E5-2600-v4 Series ; Intel Xeon E5-1600-v4 Series

    Skylake SP

    0x50654 (06/55/4)

    0xb7

    0x2007006

    6/03/2023

    Intel Xeon Platinum 8100 Series ; Intel Xeon Gold 6100/5100, Silver 4100, Bronze 3100 Series ; Intel Xeon D-2100 Series ; Intel Xeon D-1600 Series ; Intel Xeon W-3100 Series ; Intel Xeon W-2100 Series

    Cascade Lake B-0

    0x50656 (06/55/6)

    0xbf

    0x4003604

    17/03/2023

    Intel Xeon Platinum 9200/8200 Series ; Intel Xeon Gold 6200/5200 ; Intel Xeon Silver 4200/Bronze 3200 ; Intel Xeon W-3200

    Cascade Lake

    0x50657 (06/55/7)

    0xbf

    0x5003604

    17/03/2023

    Intel Xeon Platinum 9200/8200 Series ; Intel Xeon Gold 6200/5200 ; Intel Xeon Silver 4200/Bronze 3200 ; Intel Xeon W-3200

    Cooper Lake

    0x5065b (06/55/b)

    0xbf

    0x7002703

    21/03/2023

    Intel Xeon Platinum 8300 Series ; Intel Xeon Gold 6300/5300

    Broadwell DE

    0x50662 (06/56/2)

    0x10

    0x1c

    17/06/2019

    Intel Xeon D-1500 Series

    Broadwell DE

    0x50663 (06/56/3)

    0x10

    0x700001c

    12/06/2021

    Intel Xeon D-1500 Series

    Broadwell DE

    0x50664 (06/56/4)

    0x10

    0xf00001a

    12/06/2021

    Intel Xeon D-1500 Series

    Broadwell NS

    0x50665 (06/56/5)

    0x10

    0xe000014

    18/09/2021

    Intel Xeon D-1600 Series

    Skylake H/S

    0x506e3 (06/5e/3)

    0x36

    0xf0

    11/12/2021

    Intel Xeon E3-1500-v5 Series ; Intel Xeon E3-1200-v5 Series

    Denverton

    0x506f1 (06/5f/1)

    0x01

    0x38

    02/12/2021

    Intel Atom C3000 Series

    Ice Lake SP

    0x606a6 (06/6a/6)

    0x87

    0xd0003a5

    3/30/2023

    Intel Xeon Platinum 8300 Series ; Intel Xeon Gold 6300/5300 Series ; Intel Xeon Silver 4300 Series

    Ice Lake D

    0x606c1 (06/6c/1)

    0x10

    0x1000230

    27/01/2023

    Intel Xeon D-2700 Series ; Intel Xeon D-1700 Series

    Snow Ridge

    0x80665 (06/86/5)

    0x01

    0x4c000023

    22/02/2023

    Intel Atom P5000 Series

    Snow Ridge

    0x80667 (06/86/7)

    0x01

    0x4c000023

    22/02/2023

    Intel Atom P5000 Series

    Tiger Lake U

    0x806c1 (06/8c/1)

    0x80

    0xac

    27/02/2023

    Intel Core i3/i5/i7-1100 Series

    Actualisation de Tiger Lake U Refresh

    0x806c2 (06/8c/2)

    0xc2

    0x2c

    27/02/2023

    Intel Core i3/i5/i7-1100 Series

    Tiger Lake H

    0x806d1 (06/8d/1)

    0xc2

    0x46

    27/02/2023

    Intel Xeon W-11000E Series

    Sapphire Rapids SP HBM

    0x806f8 (06/8f/8)

    0x10

    0x2c0001d1

    14/02/2023

    Intel Xeon Max 9400 Series

    Sapphire Rapids SP

    0x806f8 (06/8f/8)

    0x87

    0x2b000461

    13/03/2023

    Intel Xeon Platinum 8400 Series ; Intel Xeon Gold 6400/5400 Series ; Intel Xeon Silver 4400 Series ; Intel Xeon Bronze 3400 Series

    Kaby Lake H/S/X

    0x906e9 (06/9e/9)

    0x2a

    0xf4

    23/02/2023

    Intel Xeon E3-1200-v6 Series ; Intel Xeon E3-1500-v6 Series

    Coffee Lake

    0x906ea (06/9e/a)

    0x22

    0xf4

    23/02/2023

    Intel Xeon E-2100 Series ; Intel Xeon E-2200 Series (4 ou 6 cœurs)

    Coffee Lake

    0x906eb (06/9e/b)

    0x02

    0xf4

    23/02/2023

    Intel Xeon E-2100 Series

    Coffee Lake

    0x906ec (06/9e/c)

    0x22

    0xf4

    23/02/2023

    Intel Xeon E-2100 Series

    Coffee Lake Refresh

    0x906ed (06/9e/d)

    0x22

    0xfa

    27/02/2023

    Intel Xeon E-2200 Series (8 cœurs)

    Rocket Lake S

    0xa0671 (06/a7/1)

    0x02

    0x59

    26/02/2023

    Intel Xeon E-2300 Series

esx-update_7.0.3-0.100.22348808

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 concernés

  • VMware_bootbank_loadesx_7.0.3-0.100.22348808

  • VMware_bootbank_esx-update_7.0.3-0.100.22348808

PR résolus

S.O.

Numéros CVE

S.O.

Met à jours les VIB loadesx et esx-update.

VMware-VM-Tools_12.2.6.22229486-22348808

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 concernés

  • VMware_locker_tools-light_12.2.6.22229486-22348808

PR résolus

3178522, 3178519

Numéros CVE

S.O.

Met à jour le VIB tools-light.

  • Les images ISO de VMware Tools suivantes sont intégrées à ESXi 7.0 Update 3o :

    • windows.iso : VMware Tools 12.2.6 prend en charge Windows 7 SP1 ou Windows Server 2008 R2 SP1 et versions ultérieures.

    • linux.iso: Image ISO de VMware Tools 10.3.25 pour le système d'exploitation Linux avec glibc 2.11 ou version ultérieure.

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

    • VMware Tools 11.0.6 :

      • windows.iso : pour Windows Vista (SP2) et Windows Server 2008 Service Pack 2 (SP2).

    • VMware Tools 10.0.12 :

      • winPreVista.iso : pour Windows 2000, Windows XP et Windows 2003.

      • linuxPreGLibc25.iso : prend en charge les systèmes d'exploitation invités Linux antérieurs à Red Hat Enterprise Linux (RHEL) 5, SUSE Linux Enterprise Server (SLES) 11, Ubuntu 7.04 et autres distributions avec glibc d'une version antérieure à la version 2.5.

    • solaris.iso: Image de VMware Tools 10.3.10 pour Solaris.

    • darwin.iso: Prend en charge Mac OS X 10.11 et versions ultérieures. VMware Tools 12.1.0 était la dernière version régulière pour macOS. Pour plus de détails, consultez l'article 88698 de la base de connaissances VMware.

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

ESXi-7.0U3o-22348816-standard

Nom du profil

ESXi-7.0U3o-22348816-standard

Build

Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.

Fournisseur

VMware, Inc.

Date de publication

28 septembre 2023

Niveau d'acceptation

PartnerSupported

Matériel concerné

S.O.

Logiciels concernés

S.O.

VIB concernés

  • VMware_bootbank_gc_7.0.3-0.105.22348816

  • VMware_bootbank_native-misc-drivers_7.0.3-0.105.22348816

  • VMware_bootbank_vsanhealth_7.0.3-0.105.22348816

  • VMware_bootbank_crx_7.0.3-0.105.22348816

  • VMware_bootbank_esx-xserver_7.0.3-0.105.22348816

  • VMware_bootbank_vdfs_7.0.3-0.105.22348816

  • VMware_bootbank_cpu-microcode_7.0.3-0.105.22348816

  • VMware_bootbank_esx-base_7.0.3-0.105.22348816

  • VMware_bootbank_vsan_7.0.3-0.105.22348816

  • VMware_bootbank_esxio-combiner_7.0.3-0.105.22348816

  • VMware_bootbank_esx-ui_2.11.2-21988676

  • VMware_bootbank_bmcal_7.0.3-0.105.22348816

  • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.105.22348816

  • VMware_bootbank_trx_7.0.3-0.105.22348816

  • VMware_bootbank_loadesx_7.0.3-0.105.22348816

  • VMware_bootbank_esx-update_7.0.3-0.105.22348816

  • VMW_bootbank_lsi-msgpt3_17.00.12.00-2vmw.703.0.105.22348816

  • VMware_bootbank_lsuv2-smartpqiv2-plugin_1.0.0-9vmw.703.0.105.22348816

  • VMW_bootbank_nvme-pcie_1.2.3.16-3vmw.703.0.105.22348816

  • VMW_bootbank_vmw-ahci_2.0.11-2vmw.703.0.105.22348816

  • VMW_bootbank_iavmd_2.7.0.1157-3vmw.703.0.105.22348816

  • VMware_locker_tools-light_12.2.6.22229486-22233486

PR résolus

3244098, 3216958, 3245763, 3242021, 3246132, 3253205, 3256804, 3239170, 3251981, 3215370, 3117615, 3248478, 3252676, 3235496, 3238026, 3236064, 3224739, 3224306, 3223755, 3216958, 3233958, 3185125, 3219264, 3221620, 3218835, 3185560, 3221099, 3211625, 3221860, 3228586, 3224604, 3223539, 3222601, 3217258, 3213041, 3216522, 3221591, 3216389, 3220004, 3217633, 3216548, 3216449, 3156666, 3181574, 3180746, 3155476, 3211807, 3154090, 3184008, 3183519, 3183519, 3209853, 3100552, 3187846, 3113263, 3176350, 3185827, 3095511, 3184425, 3186351, 3186367, 3154090, 3158524, 3181601, 3180391, 3180283, 3184608, 3181774, 3155476, 3163361, 3182978, 3184368, 3160456, 3164575, 3181901, 3184871, 3166818, 3157195, 3164355, 3163271, 3112194, 3161690, 3261925, 3178589, 3178721, 3162963, 3168950, 3159168, 3158491, 3158866, 3096769, 3165374, 3122037, 3098760, 3164439, 3161473, 3162790, 3100030, 3096974, 3161473, 3165651, 3083007, 3118240, 3151076, 3118402, 3160480, 3156627, 3158531, 3162499, 3158512, 3053430, 3153395, 3117615, 3099192, 3158508, 3115870, 3119834, 3158220, 3110401, 2625439, 3099357, 3152811, 3108979, 3120165, 3245953, 3178109, 3211395, 3164477, 3119959, 3164462, 3036883, 3112692, 3218578, 3224847

Numéros CVE associés

S/O

Ce correctif met à jour les problèmes suivants :

  • PR 3187846 : La définition de la résolution d'écran d'une machine virtuelle chiffrée hors tension ne fonctionne pas toujours lors de la modification manuelle du fichier VMX

    Si vous spécifiez manuellement la résolution d'écran d'une machine virtuelle chiffrée hors tension en modifiant le fichier VMX, il se peut que la modification ne prenne pas effet.

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

  • PR 3253205 : la passerelle IPv6 statique disparaît au bout de 18 heures

    Si vous configurez une adresse de passerelle IPv6 statique dans votre environnement vSphere, ces passerelles peuvent ne plus exister après un maximum de 18 heures en raison d'un délai d'expiration.

    Ce problème est résolu dans cette version. Le correctif supprime le délai d'expiration existant pour les passerelles statiques.

  • PR 3272532 : vous voyez la vitesse comme Semi-duplex après la modification de la vitesse de Auto à Intégral sur une vmnic

    Dans certains cas, les vérifications de longueur lors de l'analyse des TLV en duplex dans un environnement avec le protocole CDP (Cisco Discovery Protocol) activé peuvent échouer. Par conséquent, lorsque vous modifiez la vitesse d'Auto à Intégral sur une NIC physique sur des périphériques homologues, vous ne voyez pas la valeur de duplex réelle dans le TLV sous les informations du voisin, mais la valeur Semi-duplex par défaut.

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

  • PR 3251981 : un fichier NFSv4.1 peut sembler vide, même s'il contient des données

    Lorsque vous ouvrez un fichier NFSv4.1 existant avec un accès en écriture seule, si, pour une raison quelconque, le client NFS ouvre à nouveau le même fichier avec un accès en lecture seule, les opérations de lecture du client peuvent ne renvoyer aucune donnée bien que le fichier ne soit pas vide.

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

  • PR 3116601 : lorsque vous remplacez la passerelle par défaut de l'adaptateur VMkernel vSAN sur un hôte ESXi, l'agent vSphere HA sur l'hôte s'affiche comme étant inaccessible

    Dans certains cas, lorsque vous remplacez la passerelle par défaut pour l'adaptateur VMkernel vSAN sur un hôte ESXi, Fault Domain Manager (FDM), qui est l'agent que vSphere HA déploie sur les hôtes ESX, peut cesser de recevoir des pings ICMP (Internet Control Message Protocol). Par conséquent, FDM peut émettre de fausses alarmes de cluster indiquant que l'agent vSphere HA sur l'hôte ne peut pas accéder à certaines adresses réseau de gestion pour d'autres hôtes.

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

  • PR 3251801 : une opération vSphere vMotion à partir d'un hôte ESXi 6.7.x avec un CPU Intel Ice Lake échoue avec l'erreur msg.checkpoint.cpucheck.fail

    Les opérations vSphere vMotion à l'aide de vSphere Client ou de VMware Hybrid Cloud Extension (HCX) à partir d'un hôte avec un CPU Intel Ice Lake qui exécute ESXi 6.7.x échoue avec une erreur telle que msg.checkpoint.cpucheck.fail. Dans vSphere Client, vous voyez un message indiquant que cpuid.PSFD n'est pas pris en charge sur l'hôte cible. Dans HCX, vous voyez un rapport tel que A general system error occurred: vMotion failed:.

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

  • PR 3036883 : un chemin SAS peut être perdu lors de la mise à niveau de pilotes lsi_msgpt3

    La mise à niveau de pilotes lsi_msgpt3 de version 17.00.12.00-1 et versions antérieures peut entraîner l'arrêt des connexions de stockage et des machines virtuelles sur l'hôte ESXi en raison d'une perte de chemin SAS. Dans les journaux VMkernel, vous voyez des messages d'erreur tels que :

    2022-06-19T05:25:51.949Z cpu26:2097947)WARNING: NMP: nmpDeviceAttemptFailover:640: Retry world failover device "naa.6000d310045e2c000000000000000043" - issuing command 0x459acc1f5dc0

    2022-06-19T05:25:51.949Z cpu26:2097947)WARNING: vmw_psp_rr: psp_rrSelectPath:2177: Could not select path for device "naa.6000d310045e2c000000000000000043".

    2022-06-19T05:25:51.949Z cpu26:2097947)WARNING: NMP: nmpDeviceAttemptFailover:715: Retry world failover device "naa.6000d310045e2c000000000000000043" - failed to issue command due to Not found (APD), try again...

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, réanalysez votre stockage après la restauration sur le contrôleur de stockage pour récupérer les chemins d'accès et les connexions de stockage.

  • PR 3224739 : vous voyez des alarmes pour les messages Syslog abandonnés

    Si le débit réseau de votre système vSphere ne correspond pas à la vitesse à laquelle les messages de journal sont générés, certains messages de journal envoyés au serveur Syslog distant peuvent être abandonnés. Par conséquent, dans vSphere Client, vous voyez des erreurs d'hôte de type Triggered Alarm et vous voyez dans les journaux des avertissements tels que ALERT: vmsyslog logger xxxx:514 lost yyyy log messages.

    Ce problème est résolu dans cette version. Le correctif améliore les performances de journalisation réseau du service de journalisation pour réduire le nombre de ces messages de journal perdus.

  • PR 3247027 : si une panne se produit lors d'une migration vSphere vMotion de la machine virtuelle NVIDIA Virtual GPU (vGPU), l'hôte ESXi de destination peut échouer avec un écran de diagnostic violet

    Dans de très rares cas, si un type de panne se produit lors d'une migration vSphere vMotion d'une machine virtuelle vGPU, l'opération vMotion est marquée comme un échec lorsqu'une opération interne spécifique est en cours. Par conséquent, l'hôte ESXi de destination peut échouer avec un écran de diagnostic violet.

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

  • PR 3095511 : le service SFCB échoue par intermittence et génère des fichiers « sfcb-vmware_bas-zdump » sur plusieurs hôtes ESXi

    Dans de très rares cas, lorsque le service SFCB tente d'accéder à une variable non initialisée, le service peut échouer avec un fichier de vidage tel que sfcb-vmware_bas-zdump.000. Ce problème se produit, car l'accès à une variable non initialisée peut amener le processus SFCB à continuer de demander de la mémoire jusqu'à ce qu'il dépasse l'allocation de segment de mémoire.

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

  • PR 3218578 : vous voyez des descriptions de périphérique incorrectes pour certains adaptateurs RAID de démarrage Lenovo ThinkSystem

    Dans une interface client vSphere (telle que vSphere Client) ou lorsque vous exécutez des commandes telles que lspci et esxcfg-scsidevs -a depuis ESXi Shell, vous pouvez voir les noms de périphérique de certains adaptateurs SATA/NVMe de démarrage Lenovo sous la forme de noms génériques des puces de contrôleur qu'ils utilisent. Par exemple, Lenovo ThinkSystem M.2 avec kit d'activation de la mise en miroir s'affiche sous la forme Contrôleur 88SE9230 PCIe SATA 6 Go/s.

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

  • PR 3256804 : le serveur de fichiers perd la connectivité après le basculement lors de l'exécution du service de fichiers vSAN sur le réseau de superposition NSX

    Si le service de fichiers vSAN est en cours d'exécution sur un réseau de superposition NSX, le serveur de fichiers peut perdre la connectivité après le basculement d'une machine virtuelle d'agent vers une autre machine virtuelle d'agent. Le serveur de fichiers peut basculer lors de la reconfiguration d'un domaine de service de fichiers sans Active Directory (AD) vers un tel domaine de service avec AD, ou si vSAN détecte un comportement défectueux dans le serveur de fichiers, le partage de fichiers ou le serveur AD. Si la connectivité au serveur de fichiers est perdue après un basculement, les clients du service de fichiers ne peuvent pas accéder au partage de fichiers. L'avertissement de santé suivant peut être signalé :

    One or more DNS servers is not reachable.

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

  • PR 3217633 : le service de gestion vSAN sur l'hôte d'orchestration ne fonctionne pas correctement lors du redémarrage de vCenter

    Ce problème peut se produire sur les clusters vSAN sur lesquels vCenter est déployé. Si plusieurs opérations d'arrêt de cluster sont effectuées, le fichier/etc/vmware/vsan/vsanperf.conf sur l'hôte d'orchestration peut contenir deux versions de la machine virtuelle de gestion suivante : vc_vm_moIdvc_vm_moid Ces options de configuration sont en conflit les unes avec les autres et peuvent entraîner un dysfonctionnement du service de gestion vSAN.

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

  • PR 3224306 : lorsque vous modifiez le paramètre du Syslog ESXi syslog.global.logDir, si syslog.global.logDirUnique est actif, vous pouvez voir 2 niveaux de sous-répertoires <hostname> sous le chemin logdir

    Après la mise à niveau d'un hôte ESXi vers la version 7.0 Update 3c et versions ultérieures, si vous modifiez le paramètre Syslog syslog.global.logDir et que le paramètre syslog.global.logDirUnique est actif, vous pouvez voir 2 niveaux de sous-répertoires <hostname> sous le chemin d'accès logdir sur l'hôte. Le paramètre syslog.global.logDirUnique est utile si le même répertoire NFS est configuré en tant que Syslog.global.LogDir par plusieurs hôtes ESXi, car il crée un sous-répertoire avec le nom de l'hôte ESXi sous logdir.

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

  • PR 3223755 : le démon Syslog d'ESXi ne parvient pas à reprendre la transmission des journaux au serveur Syslog distant SSL configuré lorsqu'une perte de connectivité réseau est restaurée

    Si un serveur Syslog SSL distant perd temporairement la connectivité, le démon Syslog d'ESXi peut ne pas reprendre la transmission des journaux après la restauration de la connectivité et vous devez redémarrer le service pour réactiver les transmissions. Ce problème se produit en raison d'exceptions non gérées lorsque le démon Syslog d'ESXi tente de restaurer la connexion au serveur Syslog distant SSL.

    Ce problème est résolu dans cette version. Le correctif ajoute une capture générique pour toutes les exceptions non gérées.

  • PR 3185536 : erreur de correction de cluster vSAN après la mise à niveau de vCenter vers la version 7.0 Update 3

    Lorsque vous mettez à niveau vCenter de la version 6.5.x vers la version 7.0 Update 3 et que vous reconfigurez le cluster vSAN, une correction de cluster vSAN est déclenchée, mais échoue dans certains cas.

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

  • PR 3110401 : le paramètre Notification explicite de congestion (ECN, Explicit Congestion Notification) n'est pas persistant lors du redémarrage de l'hôte ESXi

    L'ECN, spécifiée dans RFC 3168, permet à un expéditeur TCP de réduire le taux de transmission pour éviter les abandons de paquets. Cette fonctionnalité est activée par défaut. Cependant, si vous modifiez le paramètre par défaut ou désactivez manuellement l'ECN, ces modifications apportées à la configuration ESXi peuvent ne pas persister après un redémarrage de l'hôte.

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

  • PR 3153395 : lors de l'actualisation, certaines règles de pare-feu dynamiques peuvent ne pas persister et entraîner l'échec du service cible iSCSI vSAN

    Si vous exécutez fréquemment la commande esxcli network firewall refresh, une condition de concurrence peut entraîner la suppression de certaines règles de pare-feu dynamiques lors de l'actualisation ou du chargement. Par conséquent, certains services tels que le démon cible vSAN iSCSI, qui fournit un stockage vSAN avec le protocole iSCSI, peuvent échouer.

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

  • PR 3096769 : vous voyez une latence élevée pour les opérations d'E/S de machine virtuelle dans un cluster vSAN dans lequel Unmap est activé

    Ce problème affecte les clusters vSAN dans lesquels Unmap est activé. Un problème lors de la gestion de l'opération Unmap dans LSOM crée un encombrement des journaux. L'encombrement des journaux peut entraîner une latence d'E/S de machine virtuelle élevée.

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

  • PR 3163361 : le paramètre Capacité de stockage des enregistrements d'audit n'est pas conservé lors des redémarrages de l'hôte ESXi

    Après un redémarrage de l'hôte ESXi, vous voyez le paramètre Capacité de stockage des enregistrements d'audit restauré à la valeur par défaut de 4 Mo, quelles que soient les modifications précédentes.

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

  • PR 3162496 : Si le protocole ICMPA (Internet Control Message Protocol) n'est pas actif, le redémarrage de l'hôte ESXi peut prendre beaucoup de temps après la mise à niveau vers vSphere 8.0 et versions ultérieures

    Si le protocole ICMPA n'est pas actif sur les serveurs NFS de votre environnement, après la mise à niveau de votre système vers vSphere 8.0 et versions ultérieures, le redémarrage de l'hôte ESXi peut prendre une heure, car les opérations de restauration des banques de données NFS échouent. NFS utilise l'utilitaire vmkping pour identifier les adresses IP accessibles des serveurs NFS avant d'exécuter une opération de montage et, lorsque le protocole ICMP n'est pas actif, les opérations de montage échouent.

    Ce problème est résolu dans cette version. Pour supprimer la dépendance sur le protocole ICMP afin de rechercher des adresses IP accessibles, le correctif ajoute des API de socket pour garantir que les adresses IP sur un serveur NFS donné sont disponibles.

  • PR 3220004 : les machines virtuelles Windows sur lesquelles la VBS est activée peuvent échouer avec un écran de diagnostic bleu lorsqu'un hôte ESXi subit une pression de mémoire

    Les machines virtuelles Windows sur lesquelles la sécurité basée sur la virtualisation (VBS) est activée peuvent échouer par intermittence avec un écran de diagnostic bleu lors d'opérations qui contiennent beaucoup de mémoire, telles que la suppression de snapshots ou la consolidation de disques. Le BSOD comprend la signature suivante :

    DRIVER_VERIFIER_DMA_VIOLATION (e6)

    An illegal DMA operation was attempted by a driver being verified.

    Arguments :

    Arg1: 0000000000000026, IOMMU detected DMA violation.

    Arg2: 0000000000000000, Device Object of faulting device.

    Arg3: xxxxxxxxxxxxxxxx, Faulting information (usually faulting physical address).

    Arg4: 0000000000000008, Fault type (hardware specific).

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

  • PR 3162905 : les hôtes ESXi peuvent se déconnecter de vCenter par intermittence en cas de panne de mémoire

    Dans de rares cas, si vCenter ne parvient pas à allouer ou à transférer des bitmaps actifs en raison d'une alerte de mémoire insuffisante pour une raison quelconque, le service hostd peut échouer à plusieurs reprises et vous ne pouvez pas reconnecter l'hôte à vCenter.

    Ce problème est résolu dans cette version. Le correctif s'assure que dans de tels cas, vous voyez une erreur plutôt que l'échec du service hostd.

  • PR 3108979 : le transfert des correctifs ESXi et des tâches de mise à niveau ESXi peut cesser de répondre indéfiniment en raison d'une limite de tampon de journal

    Si une chaîne ou un journal volumineux dépasse la limite de tampon de journal Python de 16 Ko, la journalisation cesse de répondre. Par conséquent, lorsque vous transférez des correctifs ESXi sur un hôte à l'aide de vSphere Client, le processus chargé de terminer la tâche de transfert sur ESXi peut cesser de répondre indéfiniment. La tâche expire et signale une erreur. Ce problème se produit également lorsque vous corrigez des hôtes ESXi à l'aide d'une ligne de base de correctifs.

    Ce problème est résolu dans cette version. Le correctif divise la chaîne d'entrée volumineuse en fragments plus petits pour la journalisation.

  • PR 3219264 : la vérification préalable vSAN du mode de maintenance ou de la désaffectation du disque ne répertorie pas les objets susceptibles de perdre l'accès

    Ce problème affecte les objets avec des composants se resynchronisant, lorsque certains composants résident sur un périphérique à supprimer ou à placer en mode de maintenance. Lorsque vous exécutez une vérification préalable avec l'option No-Action, la vérification préalable n'évalue pas correctement l'objet pour le signaler dans la liste inaccessibleObjects.

    Ce problème est résolu dans cette version. La vérification préalable inclut tous les objets affectés dans la liste inaccessibleObjects.

  • PR 3186545 : Les analyses de vulnérabilité peuvent signaler la méthode HTTP TRACE comme vulnérable sur les ports 9084 et 9087 de vCenter

    Certains outils tiers d'analyses de vulnérabilité peuvent signaler la méthode HTTP TRACE comme vulnérable sur les ports 9084 et 9087 de vCenter

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

  • PR 3221591 : L'initiateur ESXi NVMe/TCP ne parvient pas à récupérer les chemins après une récupération d'échec de la cible

    Lorsqu'une cible NVMe/TCP récupère d'un échec, ESXi ne peut pas récupérer le chemin.

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

  • PR 3186351 : vous voyez un indicateur de remplacement de la stratégie d'association de NIC, de sécurité ou de formation du trafic sur un groupe de ports activé de manière inattendue après un redémarrage de l'hôte ESXi

    Dans certains cas, une configuration de mise en réseau peut ne pas persister dans ESXi ConfigStore et vous voyez un indicateur de remplacement de la stratégie d'association de NIC, de sécurité ou de formation du trafic sur un groupe de ports activé de manière inattendue après un redémarrage de l'hôte ESXi.

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

  • PR 3162790 : le démon sfcb peut échouer avec un vidage de mémoire lors de l'installation d'un fournisseur CIM tiers

    Le démon sfcb peut tenter d'accéder à la mémoire déjà libérée lors de l'enregistrement d'un fournisseur CIM et échouer avec un vidage de mémoire lors de l'installation d'un fournisseur CIM tiers, tel que Dell OpenManage Server Administrator.

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

  • PR 3157195 : Les hôtes ESX peuvent échouer avec un écran de diagnostic violet et une erreur NMI IPI : Panic requested by another PCPU.

    Le cache du pool de ressources est un cache de niveau volume spécifique à VMFS qui stocke les clusters de ressources correspondant au volume VMFS. Lors de la recherche de clusters prioritaires, le workflow de vidage du cache effectue une itération dans une liste volumineuse de clusters de ressources mis en cache, ce qui peut entraîner le blocage des CPU physiques. De ce fait, les hôtes ESX peuvent échouer avec un écran de diagnostic violet. Dans le fichier logDump, vous voyez une erreur telle que :

    ^[[7m2022-10-22T07:56:47.322Z cpu13:2101160)WARNING: Heartbeat: 827: PCPU 0 didn't have a heartbeat for 7 seconds, timeout is 14, 1 IPIs sent; *may* be locked up.^[[0m^

    [[31;1m2022-10-22T07:56:47.322Z cpu0:2110633)ALERT: NMI: 710: NMI IPI: RIPOFF(base):RBP:CS

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

  • PR 3230493 : si une synchronisation delta s'exécute alors que le serveur vSphere Replication cible n'est pas actif, les machines virtuelles Windows peuvent cesser de répondre

    Si le serveur vSphere Replication cible n'est pas actif lors d'une synchronisation delta, le processus de synchronisation ne peut pas se terminer et les machines virtuelles cessent de répondre.

    Ce problème est résolu dans cette version. Le correctif s'assure qu'aucune tâche de synchronisation delta ne démarre lorsqu'un serveur vSphere Replication n'est pas actif.

  • PR 3122037 : La base de données ESXi ConfigStore se remplit et les écritures échouent

    Les données périmées liées aux périphériques de traitement par blocs peuvent ne pas être supprimées à temps de la base de données ESXi ConfigStore et entraîner une condition de manque d'espace. De ce fait, les opérations d'écriture dans ConfigStore commencent à échouer. Dans la trace de débogage, vous voyez des entrées de journaux telles que :

    2022-12-19T03:51:42.733Z cpu53:26745174)WARNING: VisorFSRam: 203: Cannot extend visorfs file /etc/vmware/configstore/current-store-1-journal because its ramdisk (configstore) is full.

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

  • PR 3246132 : vous voyez une dérive d'horloge système sur un hôte ESXi après l'échec d'une synchronisation avec le serveur NTP

    Si la connectivité entre le serveur NTP et un hôte ESXi est retardée pour une raison quelconque, l'horloge système sur l'hôte ESXi peut subir une dérive. Lorsque vous exécutez la commande vsishvsish -e get /system/ntpclock/clockData, vous pouvez voir une grande valeur négative pour le champ adjtime. Par exemple :

    NTP clock data {  
...  adjtime() (usec):-309237290312 <<<<<<  
...
}

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

  • PR 3185560 : les opérations vSphere vMotion pour les machines virtuelles comportant des fichiers d'échange sur une banque de données vSphere Virtual Volumes échouent par intermittence après une extension à chaud du disque de machine virtuelle

    Les opérations vSphere vMotion pour les machines virtuelles comportant des fichiers d'échange sur une banque de données vSphere Virtual Volumes peuvent échouer dans les circonstances suivantes :

    Une machine virtuelle qui s'exécute sur l'hôte ESXi A est migrée vers l'hôte ESXi B, puis le disque de machine virtuelle est étendu à chaud et la machine virtuelle est migrée de nouveau vers l'hôte ESXi A. Ce problème se produit en raison de statistiques périmées sur le volume virtuel d'échange.

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

  • PR 3236207 : vous ne pouvez pas démonter une banque de données NFS v3 d'un système vCenter, car la banque de données s'affiche comme étant inaccessible

    Lors du démontage d'une banque de données NFSv3 d'un système vCenter à l'aide de vSphere Client ou d'ESXCLI, vous pouvez voir la banque de données comme étant inaccessible ou obtenir une erreur Unable to Refresh. Ce problème se produit lorsqu'une actualisation du cache hostd se produit avant que NFS supprime les détails de montage de ConfigStore, ce qui crée une condition de concurrence rare.

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

  • PR 3236064 : les analyses de conformité ou de correction utilisant vSphere Lifecycle Manager peuvent prendre beaucoup de temps sur les hôtes ESXi disposant d'un grand nombre de banques de données

    Les analyses de conformité ou de correction à l'aide de vSphere Lifecycle Manager incluent une vérification préalable à la mise à niveau qui répertorie tous les volumes attachés à un hôte ESXi, leur espace libre, leurs versions et d'autres détails. Si de nombreuses banques de données sont attachées à un hôte, chacune disposant d'une grande capacité, la vérification préalable peut prendre beaucoup de temps. La durée est multipliée par le nombre de lignes de base attachées au cluster ou à l'hôte.

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, déconnectez les banques de données attachées lors de l'exécution des analyses de correction ou de conformité, puis reconnectez-les une fois les opérations terminées.

  • PR 3245763 : lors d'une opération vSphere vMotion, les hôtes de destination ESXi avec un pare-feu distribué (DFW) activé peuvent échouer avec un écran de diagnostic violet

    Si un DFW est activé sur l'hôte de destination d'une opération vSphere vMotion, une condition de concurrence rare peut entraîner l'échec de l'hôte avec un écran de diagnostic violet.

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

  • PR 3158866 : les machines virtuelles peuvent cesser de répondre lors de l'extension de volume VMFS en raison d'une vérification LVM (Logical Volume Manager)

    Si une opération d'extension de volume VMFS se produit lors d'une sonde LVM pour mettre à jour les attributs de volume, comme la taille de la partition VMFS qui prend en charge le volume VMFS, la taille actuelle du volume VMFS peut ne pas correspondre aux métadonnées LVM sur le disque. Par conséquent, LVM marque un tel volume comme hors ligne et les machines virtuelles sur ce volume cessent de répondre.

    Ce problème est résolu dans cette version. Le correctif améliore le contrôle d'entrée/sortie (IOCTL, Input Output Control) pour accélérer la mise à jour des attributs du périphérique et éviter de tels cas.

  • PR 3152717 : les workflows vSphere Auto Deploy peuvent échouer après une mise à niveau vers vCenter Server 7.0 Update 3j ou version ultérieure

    En raison d'un problème de mise en réseau dans les environnements de configuration de proxy inverse, les workflows vSphere Auto Deploy peuvent échouer après une mise à niveau vers vCenter Server 7.0 Update 3j ou version ultérieure. Dans la console de gestion ESXi et dans le/var/log/vmware/rbd/rbd-cgi.log file, vous voyez une erreur de client HTTP.

    Ce problème est résolu dans cette version. Le correctif s'assure que les workflows Auto Deploy s'exécutent correctement dans les environnements de configuration de proxy inverse.

  • PR 3185125 : la table SLIT virtuelle n'est pas renseignée pour le SE invité lors de l'utilisation de sched.nodeX.affinity

    Lorsque vous spécifiez l'affinité de nœud NUMA virtuel, la table vSLIT peut ne pas être renseignée et l'erreur suivante s'affiche dans vmware.log : vSLIT: NumaGetLatencyInfo failed with status: 195887107.

    Cela se produit lors de la définition de l'affinité de nœud comme suit :

    numa.slit.enable = "TRUE"

    sched.node0.affinity = 0

    sched.node1.affinity = 1

    ...sched.nodeN.affinity = N

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, spécifiez l'affinité VCPU aux CPU physiques sur les nœuds NUMA associés, au lieu de l'affinité de nœud.

    Par exemple :

    numa.slit.enable = "TRUE"

    sched.vcpu0.affinity = "0-7"

    sched.vcpu1.affinity = "0-7"

    ...sched.vcpuN.affinity = "Y-Z"

  • PR 3181774 : vous ne voyez pas d'erreur lorsque vous attachez un FCD avec CBT activé à une machine virtuelle sur laquelle le CBT est désactivé

    L'attachement d'un disque de première classe (FCD, First Class Disk) avec le suivi de modification des blocs (CBT, Changed Block Tracking) à une machine virtuelle sur laquelle le CBT est désactivé ne génère pas d'erreur détaillée, mais l'opération ne peut pas être appliquée. Dans la trace de débogage, vous pouvez voir un message d'erreur tel que InvalidState, qui est générique et ne fournit pas de détails sur le problème.

    Ce problème est résolu dans cette version. Le correctif ajoute le message d'erreur Cannot attach a CBT enabled fcd: {path} to CBT disabled VM. aux journaux du service hostd et ajoute un message d'état pour la tâche dans vSphere Client.

  • PR 3185827 : Vous voyez des fichiers d'interruption dans un répertoire SNMP sous /var/spool, même si SNMP n'est pas activé

    Après le démarrage du service hostd, par exemple après un redémarrage de l'hôte ESXi, le service peut créer un répertoire SNMP sous /var/spool et vous voyez de nombreux fichiers .trp s'accumuler dans ce répertoire.

    Ce problème est résolu dans cette version. Le correctif s'assure que le répertoire /var/spool/snmp existe uniquement lorsque SNMP est activé.

  • PR 3082867 : un hôte ESXi peut échouer avec un écran de diagnostic violet après la migration d'une machine virtuelle répliquée vers l'hôte

    Dans certains environnements, lorsqu'une machine virtuelle répliquée migre vers un hôte ESXi spécifique, lors d'une synchronisation complète, certaines commandes SCSI WRITE peuvent cibler des plages d'adresses au-delà de la fin du mappage de transfert. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet et une trace de débogage semblable à celle-ci s'affiche :

    #0 DLM_free (msp=0x43238f2c9cc0, mem=mem@entry=0x43238f6db860, allowTrim=allowTrim@entry=1 '\001') at bora/vmkernel/main/dlmalloc.c:4924

    #1 0x000041802a151e01 in Heap_Free (heap=0x43238f2c9000, mem=<optimized out>) at bora/vmkernel/main/heap.c:4217

    #2 0x000041802a3b0fa1 in BitVector_Free (heap=<optimized out>, bv=<optimized out>) at bora/vmkernel/util/bitvector.c:94

    #3 0x000041802b9f4f3f in HbrBitmapFree (bitmap=<optimized out>) at bora/modules/vmkernel/hbr_filter/hbr_bitmap.c:91

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

  • PR 3162499 : lors de l'insertion de services pour les machines virtuelles de charge de travail gérées par NSX, certaines machines virtuelles peuvent cesser de répondre par intermittence et le périphérique virtuel peut se réinitialiser

    Lors de l'insertion de services pour les machines virtuelles de charge de travail gérées par NSX, une liste de paquets peut être réinjectée de la chaîne d'entrée d'un port de commutateur vers un autre port de commutateur. Dans ce cas, le port de commutateur source ne correspond pas au portID réel de la chaîne d'entrée et le périphérique virtuel n'obtient pas l'état d'achèvement de la trame transmise. De ce fait, lorsque vous exécutez une tâche d'insertion de services, certaines machines virtuelles peuvent cesser de répondre par intermittence en raison de problèmes de connectivité réseau.

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

  • PR 3219441 : vous ne pouvez pas envoyer de clés à un SE invité à l'aide de la console de navigateur dans ESXi Host Client

    Dans ESXi Host Client, lorsque vous ouvrez la console de navigateur d'une machine virtuelle et que vous sélectionnez SE invité > Envoyer les clés, lorsque vous sélectionnez une entrée de clé (par exemple, Ctrl-Alt-Delete), la sélection n'est pas envoyée au système d'exploitation invité.

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

  • PR 3209853 : les machines virtuelles Windows peuvent échouer avec un écran de diagnostic bleu avec une signature 0x5c en raison de retards de plate-forme

    Les machines virtuelles Windows peuvent échouer avec un écran de diagnostic bleu et la signature suivante en raison d'une combinaison de facteurs impliquant le code de temporisateur Windows et des retards de plate-forme, tels que des retards de stockage ou de réseau :

    HAL_INITIALIZATION_FAILED (0x5c) (Cela indique que l'initialisation HAL a échoué.)

    Arguments :

    Arg1: 0000000000000115, HAL_TIMER_INITIALIZATION_FAILURE

    Arg2: fffff7ea800153e0, Timer address

    Arg3: 00000000000014da, Delta in QPC units (delta to program the timer with)

    Arg4: ffffffffc0000001, invalid status code (STATUS_UNSUCCESSFUL)

    Les vérifications effectuées par les temporisateurs HPET dans Windows peuvent échouer en raison de ces retards de plate-forme et provoquer ce problème.

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

  • PR 3178109 : la vérification de conformité de vSphere Lifecycle Manager échoue avec « Une erreur inconnue s'est produite lors de l'exécution de l'opération »

    L'image ESXi de base contient des composants de pilote qui peuvent être remplacés par des composants de pilote asynchrones de version supérieure fournis par un module complémentaire OEM. Si un tel composant est supprimé manuellement sur un hôte, la vérification de conformité de vSphere Lifecycle Manager peut échouer de manière inattendue. Dans vSphere Client, vous pouvez voir des erreurs telles que Host status is unknown et An unknown error occurred while performing the operation.

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

  • PR 3180634 : Les performances de certaines machines virtuelles imbriquées sur les CPU AMD peuvent se dégrader

    Les machines virtuelles imbriquées sur les CPU AMD disposant de systèmes d'exploitation tels que Windows avec sécurité basée sur la virtualisation (VBS) peuvent subir une dégradation des performances, des délais d'expiration ou une absence de réponse en raison d'un problème de virtualisation de l'indexation de virtualisation rapide (RVI) d'AMD, également appelée Tables de page imbriquées (NTP).

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

  • PR 3223539 : certaines vmnic peuvent ne pas être visibles après un redémarrage de l'hôte ESXi en raison d'un périphérique NVMe défectueux

    Si un périphérique NVMe échoue pendant la phase d'attachement, le pilote NVMe désactive le contrôleur NVMe et réinitialise les ressources de file d'attente matérielle. Lorsque vous tentez de rattacher le périphérique, une non-correspondance entre les pointeurs de file d'attente du matériel et du pilote peut entraîner une panne IOMMU sur le périphérique NVMe, ce qui entraîne une corruption de la mémoire et l'échec du service vmkdevmgr. Par conséquent, vous ne voyez pas certaines vmnic dans votre réseau.

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

  • PR 3218835 : lorsque vous désactivez ou interrompez vSphere Fault Tolerance, les machines virtuelles peuvent cesser de répondre pendant environ 10 secondes

    Lorsque vous désactivez ou interrompez vSphere FT, certaines machines virtuelles peuvent prendre environ 10 secondes pour libérer les ressources vSphere FT. Par conséquent, ces machines virtuelles cessent temporairement de répondre aux demandes réseau ou aux opérations de console.

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

  • PR 3181901 : L'hôte ESXi cesse de répondre et vous ne pouvez pas le mettre en mode de maintenance ou migrer des machines virtuelles à partir de cet hôte

    Les lectures asynchrones de métadonnées sur un volume VMFS attaché à un hôte ESXi peuvent entraîner une condition de concurrence avec d'autres threads sur l'hôte et empêcher l'hôte de répondre. De ce fait, vous ne pouvez pas mettre l'hôte en mode de maintenance ou migrer des machines virtuelles à partir de cet hôte.

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

  • PR 3156666 : les paquets d'une longueur inférieure à 60 octets peuvent être abandonnés

    Un hôte ESXi peut ajouter des octets non valides, autres que zéro, à des paquets de moins de 60 octets. Par conséquent, les paquets avec ces octets non valides sont abandonnés.

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

  • PR 3180283 : Lorsque vous migrez une machine virtuelle avec de la mémoire récemment ajoutée à chaud, un hôte ESXi peut échouer à plusieurs reprises avec un écran de diagnostic violet

    En raison d'une condition de concurrence lorsque le module d'enfichage à chaud de mémoire recalcule la disposition de mémoire NUMA d'une machine virtuelle sur un hôte de destination après la migration, un hôte ESXi peut échouer à plusieurs reprises avec un écran de diagnostic violet. Dans la trace de débogage, vous voyez des erreurs telles que :

    0x452900262cf0:[0x4200138fee8b]PanicvPanicInt@vmkernel#nover+0x327 stack: 0x452900262dc8, 0x4302f6c06508, 0x4200138fee8b, 0x420013df1300, 0x452900262cf0  0x452900262dc0:[0x4200138ff43d]Panic_WithBacktrace@vmkernel#nover+0x56 stack: 0x452900262e30, 0x452900262de0, 0x452900262e40, 0x452900262df0, 0x3e7514  0x452900262e30:[0x4200138fbb90]NMI_Interrupt@vmkernel#nover+0x561 stack: 0x0, 0xf48, 0x0, 0x0, 0x0  0x452900262f00:[0x420013953392]IDTNMIWork@vmkernel#nover+0x7f stack: 0x420049800000, 0x4200139546dd, 0x0, 0x452900262fd0, 0x0  0x452900262f20:[0x4200139546dc]Int2_NMI@vmkernel#nover+0x19 stack: 0x0, 0x42001394e068, 0xf50, 0xf50, 0x0  0x452900262f40:[0x42001394e067]gate_entry@vmkernel#nover+0x68 stack: 0x0, 0x43207bc02088, 0xd, 0x0, 0x43207bc02088  0x45397b61bd30:[0x420013be7514]NUMASched_PageNum2PhysicalDomain@vmkernel#nover+0x58 stack: 0x1, 0x420013be34c3, 0x45396f79f000, 0x1, 0x100005cf757  0x45397b61bd50:[0x420013be34c2]NUMASched_UpdateAllocStats@vmkernel#nover+0x4b stack: 0x100005cf757, 0x0, 0x0, 0x4200139b36d9, 0x0  0x45397b61bd80:[0x4200139b36d8]VmMem_NodeStatsSub@vmkernel#nover+0x59 stack: 0x39, 0x45396f79f000, 0xbce0dbf, 0x100005cf757, 0x0  0x45397b61bdc0:[0x4200139b4372]VmMem_FreePageNoBackmap@vmkernel#nover+0x8b stack: 0x465ec0001be0, 0xa, 0x465ec18748b0, 0x420014e7685f, 0x465ec14437d0

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

  • PR 3100552 : le démarrage d'ESXi expire après cinq minutes et l'hôte redémarre automatiquement

    Lors du démarrage ESXi initial, lorsque la barre de progression Chargement de VMware ESXi s'affiche, si le chargeur de démarrage met plus de cinq minutes à charger tous les modules de démarrage avant de passer à la phase de démarrage suivante, le microprogramme de l'hôte fait expirer le processus de démarrage et réinitialise le système.

    Ce problème est résolu dans cette version. Avec ESXi 7.0 Update 3o, le chargeur de démarrage ESXi réinitialise le délai d'expiration de cinq minutes après le chargement de chaque module de démarrage.

  • PR 3184368 : Le nom durable d'un LUN SCSI peut ne pas être défini

    La propriété de nom durable pour un périphérique compatible SCSI-3 provient des pages 80h et 83h des données de produit vitales (VPD) telles que définies par les normes T10 et SMI. Pour renseigner le nom durable, ESXi envoie d'abord une commande de requête pour obtenir une liste des pages VPD prises en charge par le périphérique. Ensuite, ESXi émet des commandes pour obtenir des données pour toutes les pages VPD prises en charge. En raison d'un problème avec la baie cible, le périphérique peut faire échouer une commande d'obtention des données de page VPD pour une page de la liste avec une erreur not supported. De ce fait, ESXi ne peut pas renseigner la propriété de nom durable pour le périphérique.

    Ce problème est résolu dans cette version. Le correctif ignore l'erreur sur la commande d'obtention des données de page VPD, à l'exception des pages 80h et 83h, si ces données ne sont pas requises pour la génération d'un nom durable.

  • PR 3184425 : l'analyse de port d'un VTEP (VXLAN Tunnel End Point) sur un hôte ESXi peut entraîner une perte de connectivité intermittente

    L'analyse de port d'un VTEP sur un hôte ESXi peut entraîner une perte de connectivité intermittente, mais uniquement dans les conditions suivantes :

    1. Votre environnement comporte de nombreux VTEP.

    2. Tous les VTEP se trouvent dans le même sous-réseau IP.

    3. Le commutateur en amont est Cisco ACI.

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

  • PR 3156627 : la modification du mode du disque virtuel sur une machine virtuelle en cours d'exécution peut entraîner l'échec de celle-ci

    Si vous utilisez VMware Host Client pour modifier le mode de disque d'une machine virtuelle en cours d'exécution, par exemple de Indépendant - Non persistant à Dépendant ou Indépendant - Persistant, l'opération échoue et peut entraîner l'échec de la machine virtuelle. Dans le fichier vmware.log, vous pouvez voir des erreurs telles que :

    msg.disk.notConfigured2] Failed to configure disk 'scsi0:4'. The virtual machine cannot be powered on with an unconfigured disk.

    [msg.checkpoint.continuesync.error] An operation required the virtual machine to quiesce and the virtual machine was unable to continue running.

    Ce problème est résolu dans cette version. Le correctif bloque la modification à l'aide de VMware Host Client du mode d'un disque Indépendant - Non persistant sur une machine virtuelle en cours d'exécution. vSphere Client bloque déjà ces opérations.

  • PR 3164477 : dans VMware Skyline Health Diagnostics, plusieurs avertissements s'affichent pour les pools de mémoire vSAN

    La logique d'estimation de la mémoire libre du segment de mémoire pour certains pools de mémoire vSAN peut tenir compte d'un segment de mémoire supérieur à la valeur réelle et déclencher des avertissements en cas de mémoire insuffisante. Par conséquent, vous voyez des avertissements de santé Memory pools (heap) pour de nombreux hôtes sous la section Disques physiques dans Skyline Health.

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

  • PR 3168950 : les hôtes ESXi échouent avec un écran de diagnostic violet lors de l'installation de VMware NSX-T Data Center en raison d'un espace de segment TCP/IP insuffisant

    VMware NSX-T Data Center dispose de plusieurs piles réseau et l'espace de segment TCP/IP par défaut peut ne pas être suffisant pour l'installation. Par conséquent, les hôtes ESXi peuvent échouer avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version. Le correctif augmente le paramètre TcpipHeapSize par défaut de 0 Mo à 8 Mo et la taille maximale de 32 Mo à 128 Mo. Dans vSphere Client, vous pouvez modifier la valeur TcpipHeapSize en accédant à Hôtes et clusters > Configurer > Système > Paramètres système avancés > TcpipHeadSize. Dans les systèmes vCenter avec VMware NSX-T Data Center, définissez la valeur sur 128 Mo.

  • PR 3096974 : une condition de concurrence rare dans les filtres d'E/S peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet

    Les hôtes ESXi dans lesquels les machines virtuelles utilisent des filtres d'E/S peuvent échouer de manière aléatoire avec un écran de diagnostics violet et une erreur telle que #DF Exception 8 IP 0x42002c54b19f SP 0x453a9e8c2000 en raison d'une condition de concurrence rare.

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

  • PR 3112194 : Spherelet peut ne pas démarrer sur un hôte ESXi en raison du paramètre execInstalledOnly

    Le paramètre execInstalledOnly est un paramètre d'exécution qui limite l'exécution des fichiers binaires tels que les applications et les modules VMkernel afin d'améliorer la sécurité et de se protéger contre les violations et les compromissions. Certaines vérifications de sécurité execInstalledOnly peuvent interférer avec Spherelet, l'agent ESXi UserWorld qui agit comme une extension du plan de contrôle Kubernetes, et peut l'empêcher de démarrer, même lorsque tous les fichiers sont installés.

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

  • PR 3115870 : L'installation de VIB VMware peut échouer lors d'installations simultanées de modules de fournisseur

    Lorsque vous installez des modules de mise à jour de plusieurs fournisseurs, tels que JetStream Software, Microsoft et VMware, plusieurs clients appellent les mêmes API PatchManager et peuvent entraîner une condition de concurrence. De ce fait, l'installation des modules d'installation de VMware (VIB) peut échouer. Dans les journaux, vous voyez une erreur telle que vim.fault.PlatformConfigFault, qui est une erreur générique indiquant qu'une erreur s'est produite concernant la configuration de l'hôte ESXi. Dans vSphere Client, vous voyez un message tel que An error occurred during host configuration.

    Ce problème est résolu dans cette version. Le correctif consiste à renvoyer un avertissement TaskInProgress au lieu de PlatformConfigFault, afin que vous soyez informé du problème réel et puissiez réessayer l'installation.

  • PR 3164439 : Certaines applications peuvent occuper trop de handles de fichiers ESXi et entraîner une détérioration des performances

    Dans de très rares cas, des applications telles que NVIDIA virtual GPU (vGPU) peuvent consommer tellement de handles de fichiers que ESXi ne parvient pas à traiter d'autres services ou machines virtuelles. De ce fait, vous pouvez voir le GPU disparaître sur certains nœuds ou signaler une mémoire GPU nulle, ou constater une dégradation des performances.

    Ce problème est résolu dans cette version. Le correctif réduit le nombre de handles de fichiers qu'une machine virtuelle vGPU peut consommer.

  • PR 3162963 : Si des opérations parallèles de développement de volume et d'actualisation de volume sur le même volume VMFS s'exécutent sur deux hôtes ESXi dans le même cluster, le volume VMFS peut se déconnecter

    Pendant qu'une opération de développement de volume VMFS est en cours sur un hôte ESXi dans un cluster vCenter, si, sur un autre hôte, un utilisateur ou vCenter lance une actualisation de la même capacité de volume VMFS, ce volume peut se déconnecter. Ce problème se produit en raison d'une éventuelle non-concordance entre la taille du périphérique, qui est inscrite sur le disque dans les métadonnées du volume lors d'une réanalyse du périphérique, et la valeur de la taille du périphérique dans la couche PSA (Pluggable Storage Architecture) sur l'hôte, qui peut ne pas être mise à jour si la réanalyse du périphérique n'est pas terminée.

    Ce problème est résolu dans cette version. Le correctif améliore la résilience du code du gestionnaire de volume pour forcer une actualisation consécutive des attributs du périphérique et une nouvelle comparaison des tailles du périphérique si vCenter signale une non-correspondance de la taille du périphérique.

  • PR 3161690 : l'utilisation du CPU des hôtes ESXi peut augmenter par intermittence dans les environnements qui utilisent un routeur Vigor

    En raison d'une condition de concurrence rare, lorsqu'une commande de mise hors tension de machine virtuelle est en conflit avec une fonction de rappel par un routeur Vigor, vous pouvez observer une augmentation de l'utilisation du CPU sur les hôtes ESXi (par exemple, après une mise à niveau).

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

  • PR 3165374 : les hôtes ESXi peuvent cesser de répondre et échouer avec un écran de diagnostic violet au cours de TIME_WAIT TCP

    Le temporisateur lent TCP peut bloquer le traitement d'entrée TCP alors qu'il couvre la liste des connexions dans TIME_WAIT qui ferment les connexions expirées en raison d'une contention sur le verrouillage pcbinfo TCP global. Par conséquent, VMkernel peut échouer avec un écran de diagnostic violet et l'erreur Spin count exceeded - possible deadlock lors du nettoyage des sockets TCP TIME_WAIT. La trace de débogage pointe vers des fonctions tcpip telles que tcp_slowtimo() ou tcp_twstart().

    Ce problème est résolu dans cette version. Le correctif ajoute un nouveau verrou global pour protéger la liste des connexions dans TIME_WAIT et pour acquérir le verrou tcpinfo TCP uniquement lors de la fermeture d'une connexion expirée.

  • PR 3166818 : si l'un des points de montage qui utilisent la même adresse IP de serveur NFS renvoie une erreur, VAAI-NAS peut marquer tous les points de montage comme non pris en charge

    Lorsque vous utilisez un plug-in de fournisseur VAAI-NAS, plusieurs systèmes de fichiers sur un hôte ESXi utilisent la même adresse IP de serveur NFS pour créer une banque de données. Pour certains fournisseurs NAS, si l'un des montages renvoie une erreur VIX_E_OBJECT_NOT_FOUND (25) lors de l'appel startSession, l'accélération matérielle de tous les systèmes de fichiers ayant la même adresse IP de serveur NFS peut ne plus être prise en charge. Ce problème se produit lorsqu'un hôte ESXi monte un répertoire sur un serveur NFS, mais que ce répertoire n'est pas disponible au moment de l'appel startSession (par exemple, parce qu'il a été déplacé de ce serveur NFS).

    Ce problème est résolu dans cette version. Le correctif s'assure que VAAI-NAS marque comme non pris en charge uniquement les montages qui signalent une erreur.

  • PR 3112692 : le pilote smartpqi ne peut pas obtenir l'emplacement des périphériques SSD SAS ThinkSystem PM1645a

    Dans de rares cas, le smartpqi plugin in LSU service peut obtenir une chaîne de numéro de série plus longue depuis la page VPD 0x80 que le numéro de série réel, et la recherche de périphériques dans le cache échoue. Par conséquent, lorsque vous exécutez la commande esxcli storage core device physical get -d <device_id> pour obtenir l'emplacement d'un périphérique, vous voyez une erreur telle que Unable to get location for device. Device is not found..

    Ce problème est résolu dans cette version. Le correctif s'assure que le smartpqi plugin in LSU service vérifie toujours la longueur correcte du numéro de série et trouve l'emplacement du périphérique.

  • PR 3100030 : un hôte ESXi échoue avec un écran de diagnostic violet indiquant une corruption du segment de mémoire VMFS

    Une condition de concurrence dans le cache de l'hôte d'une banque de données VMFS peut entraîner une corruption du segment de mémoire et l'hôte ESXi échoue avec un écran de diagnostic violet et un message tel que :

    PF Exception 14 in world xxxxx:res3HelperQu IP 0xxxxxxe2 addr 0xXXXXXXXXX

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

  • PR 3121216 : si le protocole ICMPA (Internet Control Message Protocol) n'est pas actif, le redémarrage de l'hôte ESXi peut prendre beaucoup de temps après une mise à niveau

    Si le protocole ICMPA n'est pas actif sur les serveurs NFS de votre environnement, après la mise à niveau de votre système, le redémarrage de l'hôte ESXi peut prendre une heure, car les opérations de restauration des banques de données NFS échouent. NFS utilise l'utilitaire vmkping pour identifier les adresses IP accessibles des serveurs NFS avant d'exécuter une opération de montage et, lorsque le protocole ICMP n'est pas actif, les opérations de montage échouent.

    Ce problème est résolu dans cette version. Pour supprimer la dépendance sur le protocole ICMP afin de rechercher des adresses IP accessibles, le correctif ajoute des API de socket pour garantir que les adresses IP sur un serveur NFS donné sont disponibles.

  • PR 3098760 : les hôtes ESXi se déconnectent de manière aléatoire du domaine Active Directory ou vCenter en raison de l'épuisement de la mémoire Likewise

    Des fuites de mémoire dans les opérations Active Directory et les bibliothèques associées, ou lorsque l'authentification par carte à puce est activée sur un hôte ESXi, peuvent entraîner l'épuisement de la mémoire Likewise.

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

  • PR 3118402 : la fonction de surveillance NTP renvoie un échec de synchronisation de l'heure intermittent dans le rapport de test des services de temps, même lorsque l'horloge système de l'hôte ESXi est correctement synchronisée

    L'infrastructure de surveillance des services de temps interroge périodiquement le démon NTP, ntpd, pour obtenir l'état de synchronisation de l'heure sur les hôtes ESXi. Des échecs de requête intermittents peuvent se produire en raison de délais d'expiration dans l'appel de socket pour lire ces informations d'état. Par conséquent, vous pouvez voir des alertes d'échec de synchronisation de l'heure dans les rapports de test NTP.

    Ce problème est résolu dans cette version. Le correctif s'assure que les requêtes de surveillance NTP n'échouent pas.

  • PR 3159168 : plusieurs messages « End path evaluation for device » s'affichent dans le fichier vmkernel.log

    Une sonde de périphérique périodique qui évalue l'état de tous les chemins d'accès à un périphérique peut créer plusieurs messages End path evaluation for device inutiles dans le fichier vmkernel.log sur une build de version.

    Ce problème est résolu dans cette version. Le correctif limite les messages End path evaluation for device aux builds de non-version, telles que les builds bêta. Vous devez activer le niveau de journalisation VERBOSE pour afficher ces journaux.

  • PR 3101512 : vous voyez un avertissement pour une perte de redondance de la liaison montante, même lorsque la liaison montante est active

    Si vous supprimez rapidement le câble réseau d'une carte réseau physique et que vous le réinsérez, l'agent hôte ESXi, hostd, déclenche un événement pour restaurer la redondance de la liaison montante. Pourtant, dans certains cas, bien que la liaison montante soit restaurée en une seconde, vous voyez toujours une alarme erronée qui indique une perte de redondance de la liaison montante.

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

  • PR 3161473 : les opérations avec des hôtes ESXi sans état peuvent ne pas choisir le disque distant prévu pour le cache système, ce qui entraîne des problèmes de correction ou de conformité

    Les opérations avec des hôtes ESXi sans état, telles que la migration du stockage, peuvent ne pas choisir le disque distant prévu pour le cache système. Par exemple, vous voulez conserver le nouveau LUN de démarrage en tant que LUN 0, mais vSphere Auto Deploy sélectionne LUN 1.

    Ce problème est résolu dans cette version. Le correctif offre un moyen cohérent de trier les disques distants et de toujours choisir le disque avec l'ID de LUN le plus faible. Pour vous assurer que vous activez le correctif, procédez comme suit :

    1. Sur la page Modifier le profil d'hôte de l'assistant Auto Deploy, sélectionnez Paramètres de configuration avancés > Configuration du cache SystemImage > Configuration du cache de l'image système

    2. Dans le menu déroulant Paramètres de profil du cache d'image système, sélectionnez Activer la mise en cache sans état sur l'hôte.

    3. Modifiez Arguments pour le premier disque en remplaçant remote par sortedremote et/ou remoteesx par sortedremoteesx.

ESXi-7.0U3o-22348816-no-tools

Nom du profil

ESXi-7.0U3o-22348816-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

28 septembre 2023

Niveau d'acceptation

PartnerSupported

Matériel concerné

S.O.

Logiciels concernés

S.O.

VIB concernés

  • VMware_bootbank_gc_7.0.3-0.105.22348816

  • VMware_bootbank_native-misc-drivers_7.0.3-0.105.22348816

  • VMware_bootbank_vsanhealth_7.0.3-0.105.22348816

  • VMware_bootbank_crx_7.0.3-0.105.22348816

  • VMware_bootbank_esx-xserver_7.0.3-0.105.22348816

  • VMware_bootbank_vdfs_7.0.3-0.105.22348816

  • VMware_bootbank_cpu-microcode_7.0.3-0.105.22348816

  • VMware_bootbank_esx-base_7.0.3-0.105.22348816

  • VMware_bootbank_vsan_7.0.3-0.105.22348816

  • VMware_bootbank_esxio-combiner_7.0.3-0.105.22348816

  • VMware_bootbank_esx-ui_2.11.2-21988676

  • VMware_bootbank_bmcal_7.0.3-0.105.22348816

  • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.105.22348816

  • VMware_bootbank_trx_7.0.3-0.105.22348816

  • VMware_bootbank_loadesx_7.0.3-0.105.22348816

  • VMware_bootbank_esx-update_7.0.3-0.105.22348816

  • VMW_bootbank_lsi-msgpt3_17.00.12.00-2vmw.703.0.105.22348816

  • VMware_bootbank_lsuv2-smartpqiv2-plugin_1.0.0-9vmw.703.0.105.22348816

  • VMW_bootbank_nvme-pcie_1.2.3.16-3vmw.703.0.105.22348816

  • VMW_bootbank_vmw-ahci_2.0.11-2vmw.703.0.105.22348816

  • VMW_bootbank_iavmd_2.7.0.1157-3vmw.703.0.105.22348816

PR résolus

3244098, 3216958, 3245763, 3242021, 3246132, 3253205, 3256804, 3239170, 3251981, 3215370, 3117615, 3248478, 3252676, 3235496, 3238026, 3236064, 3224739, 3224306, 3223755, 3216958, 3233958, 3185125, 3219264, 3221620, 3218835, 3185560, 3221099, 3211625, 3221860, 3228586, 3224604, 3223539, 3222601, 3217258, 3213041, 3216522, 3221591, 3216389, 3220004, 3217633, 3216548, 3216449, 3156666, 3181574, 3180746, 3155476, 3211807, 3154090, 3184008, 3183519, 3183519, 3209853, 3100552, 3187846, 3113263, 3176350, 3185827, 3095511, 3184425, 3186351, 3186367, 3154090, 3158524, 3181601, 3180391, 3180283, 3184608, 3181774, 3155476, 3163361, 3182978, 3184368, 3160456, 3164575, 3181901, 3184871, 3166818, 3157195, 3164355, 3163271, 3112194, 3161690, 3261925, 3178589, 3178721, 3162963, 3168950, 3159168, 3158491, 3158866, 3096769, 3165374, 3122037, 3098760, 3164439, 3161473, 3162790, 3100030, 3096974, 3161473, 3165651, 3083007, 3118240, 3151076, 3118402, 3160480, 3156627, 3158531, 3162499, 3158512, 3053430, 3153395, 3117615, 3099192, 3158508, 3115870, 3119834, 3158220, 3110401, 2625439, 3099357, 3152811, 3108979, 3120165, 3245953, 3178109, 3211395, 3164477, 3119959, 3164462, 3036883, 3112692, 3218578, 3224847

Numéros CVE associés

S/O

Ce correctif met à jour les problèmes suivants :

  • PR 3187846 : La définition de la résolution d'écran d'une machine virtuelle chiffrée hors tension ne fonctionne pas toujours lors de la modification manuelle du fichier VMX

    Si vous spécifiez manuellement la résolution d'écran d'une machine virtuelle chiffrée hors tension en modifiant le fichier VMX, il se peut que la modification ne prenne pas effet.

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

  • PR 3253205 : la passerelle IPv6 statique disparaît au bout de 18 heures

    Si vous configurez une adresse de passerelle IPv6 statique dans votre environnement vSphere, ces passerelles peuvent ne plus exister après un maximum de 18 heures en raison d'un délai d'expiration.

    Ce problème est résolu dans cette version. Le correctif supprime le délai d'expiration existant pour les passerelles statiques.

  • PR 3272532 : vous voyez la vitesse comme Semi-duplex après la modification de la vitesse de Auto à Intégral sur une vmnic

    Dans certains cas, les vérifications de longueur lors de l'analyse des TLV en duplex dans un environnement avec le protocole CDP (Cisco Discovery Protocol) activé peuvent échouer. Par conséquent, lorsque vous modifiez la vitesse d'Auto à Intégral sur une NIC physique sur des périphériques homologues, vous ne voyez pas la valeur de duplex réelle dans le TLV sous les informations du voisin, mais la valeur Semi-duplex par défaut.

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

  • PR 3251981 : un fichier NFSv4.1 peut sembler vide, même s'il contient des données

    Lorsque vous ouvrez un fichier NFSv4.1 existant avec un accès en écriture seule, si, pour une raison quelconque, le client NFS ouvre à nouveau le même fichier avec un accès en lecture seule, les opérations de lecture du client peuvent ne renvoyer aucune donnée bien que le fichier ne soit pas vide.

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

  • PR 3116601 : lorsque vous remplacez la passerelle par défaut de l'adaptateur VMkernel vSAN sur un hôte ESXi, l'agent vSphere HA sur l'hôte s'affiche comme étant inaccessible

    Dans certains cas, lorsque vous remplacez la passerelle par défaut pour l'adaptateur VMkernel vSAN sur un hôte ESXi, Fault Domain Manager (FDM), qui est l'agent que vSphere HA déploie sur les hôtes ESX, peut cesser de recevoir des pings ICMP (Internet Control Message Protocol). Par conséquent, FDM peut émettre de fausses alarmes de cluster indiquant que l'agent vSphere HA sur l'hôte ne peut pas accéder à certaines adresses réseau de gestion pour d'autres hôtes.

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

  • PR 3251801 : une opération vSphere vMotion à partir d'un hôte ESXi 6.7.x avec un CPU Intel Ice Lake échoue avec l'erreur msg.checkpoint.cpucheck.fail

    Les opérations vSphere vMotion à l'aide de vSphere Client ou de VMware Hybrid Cloud Extension (HCX) à partir d'un hôte avec un CPU Intel Ice Lake qui exécute ESXi 6.7.x échoue avec une erreur telle que msg.checkpoint.cpucheck.fail. Dans vSphere Client, vous voyez un message indiquant que cpuid.PSFD n'est pas pris en charge sur l'hôte cible. Dans HCX, vous voyez un rapport tel que A general system error occurred: vMotion failed:.

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

  • PR 3036883 : un chemin SAS peut être perdu lors de la mise à niveau de pilotes lsi_msgpt3

    La mise à niveau de pilotes lsi_msgpt3 de version 17.00.12.00-1 et versions antérieures peut entraîner l'arrêt des connexions de stockage et des machines virtuelles sur l'hôte ESXi en raison d'une perte de chemin SAS. Dans les journaux VMkernel, vous voyez des messages d'erreur tels que :

    2022-06-19T05:25:51.949Z cpu26:2097947)WARNING: NMP: nmpDeviceAttemptFailover:640: Retry world failover device "naa.6000d310045e2c000000000000000043" - issuing command 0x459acc1f5dc0

    2022-06-19T05:25:51.949Z cpu26:2097947)WARNING: vmw_psp_rr: psp_rrSelectPath:2177: Could not select path for device "naa.6000d310045e2c000000000000000043".

    2022-06-19T05:25:51.949Z cpu26:2097947)WARNING: NMP: nmpDeviceAttemptFailover:715: Retry world failover device "naa.6000d310045e2c000000000000000043" - failed to issue command due to Not found (APD), try again...

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, réanalysez votre stockage après la restauration sur le contrôleur de stockage pour récupérer les chemins d'accès et les connexions de stockage.

  • PR 3224739 : vous voyez des alarmes pour les messages Syslog abandonnés

    Si le débit réseau de votre système vSphere ne correspond pas à la vitesse à laquelle les messages de journal sont générés, certains messages de journal envoyés au serveur Syslog distant peuvent être abandonnés. Par conséquent, dans vSphere Client, vous voyez des erreurs d'hôte de type Triggered Alarm et vous voyez dans les journaux des avertissements tels que ALERT: vmsyslog logger xxxx:514 lost yyyy log messages.

    Ce problème est résolu dans cette version. Le correctif améliore les performances de journalisation réseau du service de journalisation pour réduire le nombre de ces messages de journal perdus.

  • PR 3247027 : si une panne se produit lors d'une migration vSphere vMotion de la machine virtuelle NVIDIA Virtual GPU (vGPU), l'hôte ESXi de destination peut échouer avec un écran de diagnostic violet

    Dans de très rares cas, si un type de panne se produit lors d'une migration vSphere vMotion d'une machine virtuelle vGPU, l'opération vMotion est marquée comme un échec lorsqu'une opération interne spécifique est en cours. Par conséquent, l'hôte ESXi de destination peut échouer avec un écran de diagnostic violet.

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

  • PR 3095511 : le service SFCB échoue par intermittence et génère des fichiers « sfcb-vmware_bas-zdump » sur plusieurs hôtes ESXi

    Dans de très rares cas, lorsque le service SFCB tente d'accéder à une variable non initialisée, le service peut échouer avec un fichier de vidage tel que sfcb-vmware_bas-zdump.000. Ce problème se produit, car l'accès à une variable non initialisée peut amener le processus SFCB à continuer de demander de la mémoire jusqu'à ce qu'il dépasse l'allocation de segment de mémoire.

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

  • PR 3218578 : vous voyez des descriptions de périphérique incorrectes pour certains adaptateurs RAID de démarrage Lenovo ThinkSystem

    Dans une interface client vSphere (telle que vSphere Client) ou lorsque vous exécutez des commandes telles que lspci et esxcfg-scsidevs -a depuis ESXi Shell, vous pouvez voir les noms de périphérique de certains adaptateurs SATA/NVMe de démarrage Lenovo sous la forme de noms génériques des puces de contrôleur qu'ils utilisent. Par exemple, Lenovo ThinkSystem M.2 avec kit d'activation de la mise en miroir s'affiche sous la forme Contrôleur 88SE9230 PCIe SATA 6 Go/s.

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

  • PR 3256804 : le serveur de fichiers perd la connectivité après le basculement lors de l'exécution du service de fichiers vSAN sur le réseau de superposition NSX

    Si le service de fichiers vSAN est en cours d'exécution sur un réseau de superposition NSX, le serveur de fichiers peut perdre la connectivité après le basculement d'une machine virtuelle d'agent vers une autre machine virtuelle d'agent. Le serveur de fichiers peut basculer lors de la reconfiguration d'un domaine de service de fichiers sans Active Directory (AD) vers un tel domaine de service avec AD, ou si vSAN détecte un comportement défectueux dans le serveur de fichiers, le partage de fichiers ou le serveur AD. Si la connectivité au serveur de fichiers est perdue après un basculement, les clients du service de fichiers ne peuvent pas accéder au partage de fichiers. L'avertissement de santé suivant peut être signalé :

    One or more DNS servers is not reachable.

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

  • PR 3217633 : le service de gestion vSAN sur l'hôte d'orchestration ne fonctionne pas correctement lors du redémarrage de vCenter

    Ce problème peut se produire sur les clusters vSAN sur lesquels vCenter est déployé. Si plusieurs opérations d'arrêt de cluster sont effectuées, le fichier/etc/vmware/vsan/vsanperf.conf sur l'hôte d'orchestration peut contenir deux versions de la machine virtuelle de gestion suivante : vc_vm_moIdvc_vm_moid Ces options de configuration sont en conflit les unes avec les autres et peuvent entraîner un dysfonctionnement du service de gestion vSAN.

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

  • PR 3224306 : lorsque vous modifiez le paramètre du Syslog ESXi syslog.global.logDir, si syslog.global.logDirUnique est actif, vous pouvez voir 2 niveaux de sous-répertoires <hostname> sous le chemin logdir

    Après la mise à niveau d'un hôte ESXi vers la version 7.0 Update 3c et versions ultérieures, si vous modifiez le paramètre Syslog syslog.global.logDir et que le paramètre syslog.global.logDirUnique est actif, vous pouvez voir 2 niveaux de sous-répertoires <hostname> sous le chemin d'accès logdir sur l'hôte. Le paramètre syslog.global.logDirUnique est utile si le même répertoire NFS est configuré en tant que Syslog.global.LogDir par plusieurs hôtes ESXi, car il crée un sous-répertoire avec le nom de l'hôte ESXi sous logdir.

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

  • PR 3223755 : le démon Syslog d'ESXi ne parvient pas à reprendre la transmission des journaux au serveur Syslog distant SSL configuré lorsqu'une perte de connectivité réseau est restaurée

    Si un serveur Syslog SSL distant perd temporairement la connectivité, le démon Syslog d'ESXi peut ne pas reprendre la transmission des journaux après la restauration de la connectivité et vous devez redémarrer le service pour réactiver les transmissions. Ce problème se produit en raison d'exceptions non gérées lorsque le démon Syslog d'ESXi tente de restaurer la connexion au serveur Syslog distant SSL.

    Ce problème est résolu dans cette version. Le correctif ajoute une capture générique pour toutes les exceptions non gérées.

  • PR 3185536 : erreur de correction de cluster vSAN après la mise à niveau de vCenter vers la version 7.0 Update 3

    Lorsque vous mettez à niveau vCenter de la version 6.5.x vers la version 7.0 Update 3 et que vous reconfigurez le cluster vSAN, une correction de cluster vSAN est déclenchée, mais échoue dans certains cas.

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

  • PR 3110401 : le paramètre Notification explicite de congestion (ECN, Explicit Congestion Notification) n'est pas persistant lors du redémarrage de l'hôte ESXi

    L'ECN, spécifiée dans RFC 3168, permet à un expéditeur TCP de réduire le taux de transmission pour éviter les abandons de paquets. Cette fonctionnalité est activée par défaut. Cependant, si vous modifiez le paramètre par défaut ou désactivez manuellement l'ECN, ces modifications apportées à la configuration ESXi peuvent ne pas persister après un redémarrage de l'hôte.

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

  • PR 3153395 : lors de l'actualisation, certaines règles de pare-feu dynamiques peuvent ne pas persister et entraîner l'échec du service cible iSCSI vSAN

    Si vous exécutez fréquemment la commande esxcli network firewall refresh, une condition de concurrence peut entraîner la suppression de certaines règles de pare-feu dynamiques lors de l'actualisation ou du chargement. Par conséquent, certains services tels que le démon cible vSAN iSCSI, qui fournit un stockage vSAN avec le protocole iSCSI, peuvent échouer.

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

  • PR 3096769 : vous voyez une latence élevée pour les opérations d'E/S de machine virtuelle dans un cluster vSAN dans lequel Unmap est activé

    Ce problème affecte les clusters vSAN dans lesquels Unmap est activé. Un problème lors de la gestion de l'opération Unmap dans LSOM crée un encombrement des journaux. L'encombrement des journaux peut entraîner une latence d'E/S de machine virtuelle élevée.

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

  • PR 3163361 : le paramètre Capacité de stockage des enregistrements d'audit n'est pas conservé lors des redémarrages de l'hôte ESXi

    Après un redémarrage de l'hôte ESXi, vous voyez le paramètre Capacité de stockage des enregistrements d'audit restauré à la valeur par défaut de 4 Mo, quelles que soient les modifications précédentes.

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

  • PR 3162496 : Si le protocole ICMPA (Internet Control Message Protocol) n'est pas actif, le redémarrage de l'hôte ESXi peut prendre beaucoup de temps après la mise à niveau vers vSphere 8.0 et versions ultérieures

    Si le protocole ICMPA n'est pas actif sur les serveurs NFS de votre environnement, après la mise à niveau de votre système vers vSphere 8.0 et versions ultérieures, le redémarrage de l'hôte ESXi peut prendre une heure, car les opérations de restauration des banques de données NFS échouent. NFS utilise l'utilitaire vmkping pour identifier les adresses IP accessibles des serveurs NFS avant d'exécuter une opération de montage et, lorsque le protocole ICMP n'est pas actif, les opérations de montage échouent.

    Ce problème est résolu dans cette version. Pour supprimer la dépendance sur le protocole ICMP afin de rechercher des adresses IP accessibles, le correctif ajoute des API de socket pour garantir que les adresses IP sur un serveur NFS donné sont disponibles.

  • PR 3220004 : les machines virtuelles Windows sur lesquelles la VBS est activée peuvent échouer avec un écran de diagnostic bleu lorsqu'un hôte ESXi subit une pression de mémoire

    Les machines virtuelles Windows sur lesquelles la sécurité basée sur la virtualisation (VBS) est activée peuvent échouer par intermittence avec un écran de diagnostic bleu lors d'opérations qui contiennent beaucoup de mémoire, telles que la suppression de snapshots ou la consolidation de disques. Le BSOD comprend la signature suivante :

    DRIVER_VERIFIER_DMA_VIOLATION (e6)

    An illegal DMA operation was attempted by a driver being verified.

    Arguments :

    Arg1: 0000000000000026, IOMMU detected DMA violation.

    Arg2: 0000000000000000, Device Object of faulting device.

    Arg3: xxxxxxxxxxxxxxxx, Faulting information (usually faulting physical address).

    Arg4: 0000000000000008, Fault type (hardware specific).

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

  • PR 3162905 : les hôtes ESXi peuvent se déconnecter de vCenter par intermittence en cas de panne de mémoire

    Dans de rares cas, si vCenter ne parvient pas à allouer ou à transférer des bitmaps actifs en raison d'une alerte de mémoire insuffisante pour une raison quelconque, le service hostd peut échouer à plusieurs reprises et vous ne pouvez pas reconnecter l'hôte à vCenter.

    Ce problème est résolu dans cette version. Le correctif s'assure que dans de tels cas, vous voyez une erreur plutôt que l'échec du service hostd.

  • PR 3108979 : le transfert des correctifs ESXi et des tâches de mise à niveau ESXi peut cesser de répondre indéfiniment en raison d'une limite de tampon de journal

    Si une chaîne ou un journal volumineux dépasse la limite de tampon de journal Python de 16 Ko, la journalisation cesse de répondre. Par conséquent, lorsque vous transférez des correctifs ESXi sur un hôte à l'aide de vSphere Client, le processus chargé de terminer la tâche de transfert sur ESXi peut cesser de répondre indéfiniment. La tâche expire et signale une erreur. Ce problème se produit également lorsque vous corrigez des hôtes ESXi à l'aide d'une ligne de base de correctifs.

    Ce problème est résolu dans cette version. Le correctif divise la chaîne d'entrée volumineuse en fragments plus petits pour la journalisation.

  • PR 3219264 : la vérification préalable vSAN du mode de maintenance ou de la désaffectation du disque ne répertorie pas les objets susceptibles de perdre l'accès

    Ce problème affecte les objets avec des composants se resynchronisant, lorsque certains composants résident sur un périphérique à supprimer ou à placer en mode de maintenance. Lorsque vous exécutez une vérification préalable avec l'option No-Action, la vérification préalable n'évalue pas correctement l'objet pour le signaler dans la liste inaccessibleObjects.

    Ce problème est résolu dans cette version. La vérification préalable inclut tous les objets affectés dans la liste inaccessibleObjects.

  • PR 3186545 : Les analyses de vulnérabilité peuvent signaler la méthode HTTP TRACE comme vulnérable sur les ports 9084 et 9087 de vCenter

    Certains outils tiers d'analyses de vulnérabilité peuvent signaler la méthode HTTP TRACE comme vulnérable sur les ports 9084 et 9087 de vCenter

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

  • PR 3221591 : L'initiateur ESXi NVMe/TCP ne parvient pas à récupérer les chemins après une récupération d'échec de la cible

    Lorsqu'une cible NVMe/TCP récupère d'un échec, ESXi ne peut pas récupérer le chemin.

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

  • PR 3186351 : vous voyez un indicateur de remplacement de la stratégie d'association de NIC, de sécurité ou de formation du trafic sur un groupe de ports activé de manière inattendue après un redémarrage de l'hôte ESXi

    Dans certains cas, une configuration de mise en réseau peut ne pas persister dans ESXi ConfigStore et vous voyez un indicateur de remplacement de la stratégie d'association de NIC, de sécurité ou de formation du trafic sur un groupe de ports activé de manière inattendue après un redémarrage de l'hôte ESXi.

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

  • PR 3162790 : le démon sfcb peut échouer avec un vidage de mémoire lors de l'installation d'un fournisseur CIM tiers

    Le démon sfcb peut tenter d'accéder à la mémoire déjà libérée lors de l'enregistrement d'un fournisseur CIM et échouer avec un vidage de mémoire lors de l'installation d'un fournisseur CIM tiers, tel que Dell OpenManage Server Administrator.

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

  • PR 3157195 : Les hôtes ESX peuvent échouer avec un écran de diagnostic violet et une erreur NMI IPI : Panic requested by another PCPU.

    Le cache du pool de ressources est un cache de niveau volume spécifique à VMFS qui stocke les clusters de ressources correspondant au volume VMFS. Lors de la recherche de clusters prioritaires, le workflow de vidage du cache effectue une itération dans une liste volumineuse de clusters de ressources mis en cache, ce qui peut entraîner le blocage des CPU physiques. De ce fait, les hôtes ESX peuvent échouer avec un écran de diagnostic violet. Dans le fichier logDump, vous voyez une erreur telle que :

    ^[[7m2022-10-22T07:56:47.322Z cpu13:2101160)WARNING: Heartbeat: 827: PCPU 0 didn't have a heartbeat for 7 seconds, timeout is 14, 1 IPIs sent; *may* be locked up.^[[0m^

    [[31;1m2022-10-22T07:56:47.322Z cpu0:2110633)ALERT: NMI: 710: NMI IPI: RIPOFF(base):RBP:CS

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

  • PR 3230493 : si une synchronisation delta s'exécute alors que le serveur vSphere Replication cible n'est pas actif, les machines virtuelles Windows peuvent cesser de répondre

    Si le serveur vSphere Replication cible n'est pas actif lors d'une synchronisation delta, le processus de synchronisation ne peut pas se terminer et les machines virtuelles cessent de répondre.

    Ce problème est résolu dans cette version. Le correctif s'assure qu'aucune tâche de synchronisation delta ne démarre lorsqu'un serveur vSphere Replication n'est pas actif.

  • PR 3122037 : La base de données ESXi ConfigStore se remplit et les écritures échouent

    Les données périmées liées aux périphériques de traitement par blocs peuvent ne pas être supprimées à temps de la base de données ESXi ConfigStore et entraîner une condition de manque d'espace. De ce fait, les opérations d'écriture dans ConfigStore commencent à échouer. Dans la trace de débogage, vous voyez des entrées de journaux telles que :

    2022-12-19T03:51:42.733Z cpu53:26745174)WARNING: VisorFSRam: 203: Cannot extend visorfs file /etc/vmware/configstore/current-store-1-journal because its ramdisk (configstore) is full.

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

  • PR 3246132 : vous voyez une dérive d'horloge système sur un hôte ESXi après l'échec d'une synchronisation avec le serveur NTP

    Si la connectivité entre le serveur NTP et un hôte ESXi est retardée pour une raison quelconque, l'horloge système sur l'hôte ESXi peut subir une dérive. Lorsque vous exécutez la commande vsishvsish -e get /system/ntpclock/clockData, vous pouvez voir une grande valeur négative pour le champ adjtime. Par exemple :

    NTP clock data {  
...  adjtime() (usec):-309237290312 <<<<<<  
...
}

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

  • PR 3185560 : les opérations vSphere vMotion pour les machines virtuelles comportant des fichiers d'échange sur une banque de données vSphere Virtual Volumes échouent par intermittence après une extension à chaud du disque de machine virtuelle

    Les opérations vSphere vMotion pour les machines virtuelles comportant des fichiers d'échange sur une banque de données vSphere Virtual Volumes peuvent échouer dans les circonstances suivantes :

    Une machine virtuelle qui s'exécute sur l'hôte ESXi A est migrée vers l'hôte ESXi B, puis le disque de machine virtuelle est étendu à chaud et la machine virtuelle est migrée de nouveau vers l'hôte ESXi A. Ce problème se produit en raison de statistiques périmées sur le volume virtuel d'échange.

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

  • PR 3236207 : vous ne pouvez pas démonter une banque de données NFS v3 d'un système vCenter, car la banque de données s'affiche comme étant inaccessible

    Lors du démontage d'une banque de données NFSv3 d'un système vCenter à l'aide de vSphere Client ou d'ESXCLI, vous pouvez voir la banque de données comme étant inaccessible ou obtenir une erreur Unable to Refresh. Ce problème se produit lorsqu'une actualisation du cache hostd se produit avant que NFS supprime les détails de montage de ConfigStore, ce qui crée une condition de concurrence rare.

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

  • PR 3236064 : les analyses de conformité ou de correction utilisant vSphere Lifecycle Manager peuvent prendre beaucoup de temps sur les hôtes ESXi disposant d'un grand nombre de banques de données

    Les analyses de conformité ou de correction à l'aide de vSphere Lifecycle Manager incluent une vérification préalable à la mise à niveau qui répertorie tous les volumes attachés à un hôte ESXi, leur espace libre, leurs versions et d'autres détails. Si de nombreuses banques de données sont attachées à un hôte, chacune disposant d'une grande capacité, la vérification préalable peut prendre beaucoup de temps. La durée est multipliée par le nombre de lignes de base attachées au cluster ou à l'hôte.

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, déconnectez les banques de données attachées lors de l'exécution des analyses de correction ou de conformité, puis reconnectez-les une fois les opérations terminées.

  • PR 3245763 : lors d'une opération vSphere vMotion, les hôtes de destination ESXi avec un pare-feu distribué (DFW) activé peuvent échouer avec un écran de diagnostic violet

    Si un DFW est activé sur l'hôte de destination d'une opération vSphere vMotion, une condition de concurrence rare peut entraîner l'échec de l'hôte avec un écran de diagnostic violet.

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

  • PR 3158866 : les machines virtuelles peuvent cesser de répondre lors de l'extension de volume VMFS en raison d'une vérification LVM (Logical Volume Manager)

    Si une opération d'extension de volume VMFS se produit lors d'une sonde LVM pour mettre à jour les attributs de volume, comme la taille de la partition VMFS qui prend en charge le volume VMFS, la taille actuelle du volume VMFS peut ne pas correspondre aux métadonnées LVM sur le disque. Par conséquent, LVM marque un tel volume comme hors ligne et les machines virtuelles sur ce volume cessent de répondre.

    Ce problème est résolu dans cette version. Le correctif améliore le contrôle d'entrée/sortie (IOCTL, Input Output Control) pour accélérer la mise à jour des attributs du périphérique et éviter de tels cas.

  • PR 3152717 : les workflows vSphere Auto Deploy peuvent échouer après une mise à niveau vers vCenter Server 7.0 Update 3j ou version ultérieure

    En raison d'un problème de mise en réseau dans les environnements de configuration de proxy inverse, les workflows vSphere Auto Deploy peuvent échouer après une mise à niveau vers vCenter Server 7.0 Update 3j ou version ultérieure. Dans la console de gestion ESXi et dans le/var/log/vmware/rbd/rbd-cgi.log file, vous voyez une erreur de client HTTP.

    Ce problème est résolu dans cette version. Le correctif s'assure que les workflows Auto Deploy s'exécutent correctement dans les environnements de configuration de proxy inverse.

  • PR 3185125 : la table SLIT virtuelle n'est pas renseignée pour le SE invité lors de l'utilisation de sched.nodeX.affinity

    Lorsque vous spécifiez l'affinité de nœud NUMA virtuel, la table vSLIT peut ne pas être renseignée et l'erreur suivante s'affiche dans vmware.log : vSLIT: NumaGetLatencyInfo failed with status: 195887107.

    Cela se produit lors de la définition de l'affinité de nœud comme suit :

    numa.slit.enable = "TRUE"

    sched.node0.affinity = 0

    sched.node1.affinity = 1

    ...sched.nodeN.affinity = N

    Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, spécifiez l'affinité VCPU aux CPU physiques sur les nœuds NUMA associés, au lieu de l'affinité de nœud.

    Par exemple :

    numa.slit.enable = "TRUE"

    sched.vcpu0.affinity = "0-7"

    sched.vcpu1.affinity = "0-7"

    ...sched.vcpuN.affinity = "Y-Z"

  • PR 3181774 : vous ne voyez pas d'erreur lorsque vous attachez un FCD avec CBT activé à une machine virtuelle sur laquelle le CBT est désactivé

    L'attachement d'un disque de première classe (FCD, First Class Disk) avec le suivi de modification des blocs (CBT, Changed Block Tracking) à une machine virtuelle sur laquelle le CBT est désactivé ne génère pas d'erreur détaillée, mais l'opération ne peut pas être appliquée. Dans la trace de débogage, vous pouvez voir un message d'erreur tel que InvalidState, qui est générique et ne fournit pas de détails sur le problème.

    Ce problème est résolu dans cette version. Le correctif ajoute le message d'erreur Cannot attach a CBT enabled fcd: {path} to CBT disabled VM. aux journaux du service hostd et ajoute un message d'état pour la tâche dans vSphere Client.

  • PR 3185827 : Vous voyez des fichiers d'interruption dans un répertoire SNMP sous /var/spool, même si SNMP n'est pas activé

    Après le démarrage du service hostd, par exemple après un redémarrage de l'hôte ESXi, le service peut créer un répertoire SNMP sous /var/spool et vous voyez de nombreux fichiers .trp s'accumuler dans ce répertoire.

    Ce problème est résolu dans cette version. Le correctif s'assure que le répertoire /var/spool/snmp existe uniquement lorsque SNMP est activé.

  • PR 3082867 : un hôte ESXi peut échouer avec un écran de diagnostic violet après la migration d'une machine virtuelle répliquée vers l'hôte

    Dans certains environnements, lorsqu'une machine virtuelle répliquée migre vers un hôte ESXi spécifique, lors d'une synchronisation complète, certaines commandes SCSI WRITE peuvent cibler des plages d'adresses au-delà de la fin du mappage de transfert. Par conséquent, l'hôte ESXi peut échouer avec un écran de diagnostic violet et une trace de débogage semblable à celle-ci s'affiche :

    #0 DLM_free (msp=0x43238f2c9cc0, mem=mem@entry=0x43238f6db860, allowTrim=allowTrim@entry=1 '\001') at bora/vmkernel/main/dlmalloc.c:4924

    #1 0x000041802a151e01 in Heap_Free (heap=0x43238f2c9000, mem=<optimized out>) at bora/vmkernel/main/heap.c:4217

    #2 0x000041802a3b0fa1 in BitVector_Free (heap=<optimized out>, bv=<optimized out>) at bora/vmkernel/util/bitvector.c:94

    #3 0x000041802b9f4f3f in HbrBitmapFree (bitmap=<optimized out>) at bora/modules/vmkernel/hbr_filter/hbr_bitmap.c:91

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

  • PR 3162499 : lors de l'insertion de services pour les machines virtuelles de charge de travail gérées par NSX, certaines machines virtuelles peuvent cesser de répondre par intermittence et le périphérique virtuel peut se réinitialiser

    Lors de l'insertion de services pour les machines virtuelles de charge de travail gérées par NSX, une liste de paquets peut être réinjectée de la chaîne d'entrée d'un port de commutateur vers un autre port de commutateur. Dans ce cas, le port de commutateur source ne correspond pas au portID réel de la chaîne d'entrée et le périphérique virtuel n'obtient pas l'état d'achèvement de la trame transmise. De ce fait, lorsque vous exécutez une tâche d'insertion de services, certaines machines virtuelles peuvent cesser de répondre par intermittence en raison de problèmes de connectivité réseau.

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

  • PR 3219441 : vous ne pouvez pas envoyer de clés à un SE invité à l'aide de la console de navigateur dans ESXi Host Client

    Dans ESXi Host Client, lorsque vous ouvrez la console de navigateur d'une machine virtuelle et que vous sélectionnez SE invité > Envoyer les clés, lorsque vous sélectionnez une entrée de clé (par exemple, Ctrl-Alt-Delete), la sélection n'est pas envoyée au système d'exploitation invité.

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

  • PR 3209853 : les machines virtuelles Windows peuvent échouer avec un écran de diagnostic bleu avec une signature 0x5c en raison de retards de plate-forme

    Les machines virtuelles Windows peuvent échouer avec un écran de diagnostic bleu et la signature suivante en raison d'une combinaison de facteurs impliquant le code de temporisateur Windows et des retards de plate-forme, tels que des retards de stockage ou de réseau :

    HAL_INITIALIZATION_FAILED (0x5c) (Cela indique que l'initialisation HAL a échoué.)

    Arguments :

    Arg1: 0000000000000115, HAL_TIMER_INITIALIZATION_FAILURE

    Arg2: fffff7ea800153e0, Timer address

    Arg3: 00000000000014da, Delta in QPC units (delta to program the timer with)

    Arg4: ffffffffc0000001, invalid status code (STATUS_UNSUCCESSFUL)

    Les vérifications effectuées par les temporisateurs HPET dans Windows peuvent échouer en raison de ces retards de plate-forme et provoquer ce problème.

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

  • PR 3178109 : la vérification de conformité de vSphere Lifecycle Manager échoue avec « Une erreur inconnue s'est produite lors de l'exécution de l'opération »

    L'image ESXi de base contient des composants de pilote qui peuvent être remplacés par des composants de pilote asynchrones de version supérieure fournis par un module complémentaire OEM. Si un tel composant est supprimé manuellement sur un hôte, la vérification de conformité de vSphere Lifecycle Manager peut échouer de manière inattendue. Dans vSphere Client, vous pouvez voir des erreurs telles que Host status is unknown et An unknown error occurred while performing the operation.

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

  • PR 3180634 : Les performances de certaines machines virtuelles imbriquées sur les CPU AMD peuvent se dégrader

    Les machines virtuelles imbriquées sur les CPU AMD disposant de systèmes d'exploitation tels que Windows avec sécurité basée sur la virtualisation (VBS) peuvent subir une dégradation des performances, des délais d'expiration ou une absence de réponse en raison d'un problème de virtualisation de l'indexation de virtualisation rapide (RVI) d'AMD, également appelée Tables de page imbriquées (NTP).

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

  • PR 3223539 : certaines vmnic peuvent ne pas être visibles après un redémarrage de l'hôte ESXi en raison d'un périphérique NVMe défectueux

    Si un périphérique NVMe échoue pendant la phase d'attachement, le pilote NVMe désactive le contrôleur NVMe et réinitialise les ressources de file d'attente matérielle. Lorsque vous tentez de rattacher le périphérique, une non-correspondance entre les pointeurs de file d'attente du matériel et du pilote peut entraîner une panne IOMMU sur le périphérique NVMe, ce qui entraîne une corruption de la mémoire et l'échec du service vmkdevmgr. Par conséquent, vous ne voyez pas certaines vmnic dans votre réseau.

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

  • PR 3218835 : lorsque vous désactivez ou interrompez vSphere Fault Tolerance, les machines virtuelles peuvent cesser de répondre pendant environ 10 secondes

    Lorsque vous désactivez ou interrompez vSphere FT, certaines machines virtuelles peuvent prendre environ 10 secondes pour libérer les ressources vSphere FT. Par conséquent, ces machines virtuelles cessent temporairement de répondre aux demandes réseau ou aux opérations de console.

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

  • PR 3181901 : L'hôte ESXi cesse de répondre et vous ne pouvez pas le mettre en mode de maintenance ou migrer des machines virtuelles à partir de cet hôte

    Les lectures asynchrones de métadonnées sur un volume VMFS attaché à un hôte ESXi peuvent entraîner une condition de concurrence avec d'autres threads sur l'hôte et empêcher l'hôte de répondre. De ce fait, vous ne pouvez pas mettre l'hôte en mode de maintenance ou migrer des machines virtuelles à partir de cet hôte.

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

  • PR 3156666 : les paquets d'une longueur inférieure à 60 octets peuvent être abandonnés

    Un hôte ESXi peut ajouter des octets non valides, autres que zéro, à des paquets de moins de 60 octets. Par conséquent, les paquets avec ces octets non valides sont abandonnés.

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

  • PR 3180283 : Lorsque vous migrez une machine virtuelle avec de la mémoire récemment ajoutée à chaud, un hôte ESXi peut échouer à plusieurs reprises avec un écran de diagnostic violet

    En raison d'une condition de concurrence lorsque le module d'enfichage à chaud de mémoire recalcule la disposition de mémoire NUMA d'une machine virtuelle sur un hôte de destination après la migration, un hôte ESXi peut échouer à plusieurs reprises avec un écran de diagnostic violet. Dans la trace de débogage, vous voyez des erreurs telles que :

    0x452900262cf0:[0x4200138fee8b]PanicvPanicInt@vmkernel#nover+0x327 stack: 0x452900262dc8, 0x4302f6c06508, 0x4200138fee8b, 0x420013df1300, 0x452900262cf0  0x452900262dc0:[0x4200138ff43d]Panic_WithBacktrace@vmkernel#nover+0x56 stack: 0x452900262e30, 0x452900262de0, 0x452900262e40, 0x452900262df0, 0x3e7514  0x452900262e30:[0x4200138fbb90]NMI_Interrupt@vmkernel#nover+0x561 stack: 0x0, 0xf48, 0x0, 0x0, 0x0  0x452900262f00:[0x420013953392]IDTNMIWork@vmkernel#nover+0x7f stack: 0x420049800000, 0x4200139546dd, 0x0, 0x452900262fd0, 0x0  0x452900262f20:[0x4200139546dc]Int2_NMI@vmkernel#nover+0x19 stack: 0x0, 0x42001394e068, 0xf50, 0xf50, 0x0  0x452900262f40:[0x42001394e067]gate_entry@vmkernel#nover+0x68 stack: 0x0, 0x43207bc02088, 0xd, 0x0, 0x43207bc02088  0x45397b61bd30:[0x420013be7514]NUMASched_PageNum2PhysicalDomain@vmkernel#nover+0x58 stack: 0x1, 0x420013be34c3, 0x45396f79f000, 0x1, 0x100005cf757  0x45397b61bd50:[0x420013be34c2]NUMASched_UpdateAllocStats@vmkernel#nover+0x4b stack: 0x100005cf757, 0x0, 0x0, 0x4200139b36d9, 0x0  0x45397b61bd80:[0x4200139b36d8]VmMem_NodeStatsSub@vmkernel#nover+0x59 stack: 0x39, 0x45396f79f000, 0xbce0dbf, 0x100005cf757, 0x0  0x45397b61bdc0:[0x4200139b4372]VmMem_FreePageNoBackmap@vmkernel#nover+0x8b stack: 0x465ec0001be0, 0xa, 0x465ec18748b0, 0x420014e7685f, 0x465ec14437d0

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

  • PR 3100552 : le démarrage d'ESXi expire après cinq minutes et l'hôte redémarre automatiquement

    Lors du démarrage ESXi initial, lorsque la barre de progression Chargement de VMware ESXi s'affiche, si le chargeur de démarrage met plus de cinq minutes à charger tous les modules de démarrage avant de passer à la phase de démarrage suivante, le microprogramme de l'hôte fait expirer le processus de démarrage et réinitialise le système.

    Ce problème est résolu dans cette version. Avec ESXi 7.0 Update 3o, le chargeur de démarrage ESXi réinitialise le délai d'expiration de cinq minutes après le chargement de chaque module de démarrage.

  • PR 3184368 : Le nom durable d'un LUN SCSI peut ne pas être défini

    La propriété de nom durable pour un périphérique compatible SCSI-3 provient des pages 80h et 83h des données de produit vitales (VPD) telles que définies par les normes T10 et SMI. Pour renseigner le nom durable, ESXi envoie d'abord une commande de requête pour obtenir une liste des pages VPD prises en charge par le périphérique. Ensuite, ESXi émet des commandes pour obtenir des données pour toutes les pages VPD prises en charge. En raison d'un problème avec la baie cible, le périphérique peut faire échouer une commande d'obtention des données de page VPD pour une page de la liste avec une erreur not supported. De ce fait, ESXi ne peut pas renseigner la propriété de nom durable pour le périphérique.

    Ce problème est résolu dans cette version. Le correctif ignore l'erreur sur la commande d'obtention des données de page VPD, à l'exception des pages 80h et 83h, si ces données ne sont pas requises pour la génération d'un nom durable.

  • PR 3184425 : l'analyse de port d'un VTEP (VXLAN Tunnel End Point) sur un hôte ESXi peut entraîner une perte de connectivité intermittente

    L'analyse de port d'un VTEP sur un hôte ESXi peut entraîner une perte de connectivité intermittente, mais uniquement dans les conditions suivantes :

    1. Votre environnement comporte de nombreux VTEP.

    2. Tous les VTEP se trouvent dans le même sous-réseau IP.

    3. Le commutateur en amont est Cisco ACI.

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

  • PR 3156627 : la modification du mode du disque virtuel sur une machine virtuelle en cours d'exécution peut entraîner l'échec de celle-ci

    Si vous utilisez VMware Host Client pour modifier le mode de disque d'une machine virtuelle en cours d'exécution, par exemple de Indépendant - Non persistant à Dépendant ou Indépendant - Persistant, l'opération échoue et peut entraîner l'échec de la machine virtuelle. Dans le fichier vmware.log, vous pouvez voir des erreurs telles que :

    msg.disk.notConfigured2] Failed to configure disk 'scsi0:4'. The virtual machine cannot be powered on with an unconfigured disk.

    [msg.checkpoint.continuesync.error] An operation required the virtual machine to quiesce and the virtual machine was unable to continue running.

    Ce problème est résolu dans cette version. Le correctif bloque la modification à l'aide de VMware Host Client du mode d'un disque Indépendant - Non persistant sur une machine virtuelle en cours d'exécution. vSphere Client bloque déjà ces opérations.

  • PR 3164477 : dans VMware Skyline Health Diagnostics, plusieurs avertissements s'affichent pour les pools de mémoire vSAN

    La logique d'estimation de la mémoire libre du segment de mémoire pour certains pools de mémoire vSAN peut tenir compte d'un segment de mémoire supérieur à la valeur réelle et déclencher des avertissements en cas de mémoire insuffisante. Par conséquent, vous voyez des avertissements de santé Memory pools (heap) pour de nombreux hôtes sous la section Disques physiques dans Skyline Health.

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

  • PR 3168950 : les hôtes ESXi échouent avec un écran de diagnostic violet lors de l'installation de VMware NSX-T Data Center en raison d'un espace de segment TCP/IP insuffisant

    VMware NSX-T Data Center dispose de plusieurs piles réseau et l'espace de segment TCP/IP par défaut peut ne pas être suffisant pour l'installation. Par conséquent, les hôtes ESXi peuvent échouer avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version. Le correctif augmente le paramètre TcpipHeapSize par défaut de 0 Mo à 8 Mo et la taille maximale de 32 Mo à 128 Mo. Dans vSphere Client, vous pouvez modifier la valeur TcpipHeapSize en accédant à Hôtes et clusters > Configurer > Système > Paramètres système avancés > TcpipHeadSize. Dans les systèmes vCenter avec VMware NSX-T Data Center, définissez la valeur sur 128 Mo.

  • PR 3096974 : une condition de concurrence rare dans les filtres d'E/S peut entraîner l'échec d'un hôte ESXi avec un écran de diagnostic violet

    Les hôtes ESXi dans lesquels les machines virtuelles utilisent des filtres d'E/S peuvent échouer de manière aléatoire avec un écran de diagnostics violet et une erreur telle que #DF Exception 8 IP 0x42002c54b19f SP 0x453a9e8c2000 en raison d'une condition de concurrence rare.

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

  • PR 3112194 : Spherelet peut ne pas démarrer sur un hôte ESXi en raison du paramètre execInstalledOnly

    Le paramètre execInstalledOnly est un paramètre d'exécution qui limite l'exécution des fichiers binaires tels que les applications et les modules VMkernel afin d'améliorer la sécurité et de se protéger contre les violations et les compromissions. Certaines vérifications de sécurité execInstalledOnly peuvent interférer avec Spherelet, l'agent ESXi UserWorld qui agit comme une extension du plan de contrôle Kubernetes, et peut l'empêcher de démarrer, même lorsque tous les fichiers sont installés.

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

  • PR 3115870 : L'installation de VIB VMware peut échouer lors d'installations simultanées de modules de fournisseur

    Lorsque vous installez des modules de mise à jour de plusieurs fournisseurs, tels que JetStream Software, Microsoft et VMware, plusieurs clients appellent les mêmes API PatchManager et peuvent entraîner une condition de concurrence. De ce fait, l'installation des modules d'installation de VMware (VIB) peut échouer. Dans les journaux, vous voyez une erreur telle que vim.fault.PlatformConfigFault, qui est une erreur générique indiquant qu'une erreur s'est produite concernant la configuration de l'hôte ESXi. Dans vSphere Client, vous voyez un message tel que An error occurred during host configuration.

    Ce problème est résolu dans cette version. Le correctif consiste à renvoyer un avertissement TaskInProgress au lieu de PlatformConfigFault, afin que vous soyez informé du problème réel et puissiez réessayer l'installation.

  • PR 3164439 : Certaines applications peuvent occuper trop de handles de fichiers ESXi et entraîner une détérioration des performances

    Dans de très rares cas, des applications telles que NVIDIA virtual GPU (vGPU) peuvent consommer tellement de handles de fichiers que ESXi ne parvient pas à traiter d'autres services ou machines virtuelles. De ce fait, vous pouvez voir le GPU disparaître sur certains nœuds ou signaler une mémoire GPU nulle, ou constater une dégradation des performances.

    Ce problème est résolu dans cette version. Le correctif réduit le nombre de handles de fichiers qu'une machine virtuelle vGPU peut consommer.

  • PR 3162963 : Si des opérations parallèles de développement de volume et d'actualisation de volume sur le même volume VMFS s'exécutent sur deux hôtes ESXi dans le même cluster, le volume VMFS peut se déconnecter

    Pendant qu'une opération de développement de volume VMFS est en cours sur un hôte ESXi dans un cluster vCenter, si, sur un autre hôte, un utilisateur ou vCenter lance une actualisation de la même capacité de volume VMFS, ce volume peut se déconnecter. Ce problème se produit en raison d'une éventuelle non-concordance entre la taille du périphérique, qui est inscrite sur le disque dans les métadonnées du volume lors d'une réanalyse du périphérique, et la valeur de la taille du périphérique dans la couche PSA (Pluggable Storage Architecture) sur l'hôte, qui peut ne pas être mise à jour si la réanalyse du périphérique n'est pas terminée.

    Ce problème est résolu dans cette version. Le correctif améliore la résilience du code du gestionnaire de volume pour forcer une actualisation consécutive des attributs du périphérique et une nouvelle comparaison des tailles du périphérique si vCenter signale une non-correspondance de la taille du périphérique.

  • PR 3161690 : l'utilisation du CPU des hôtes ESXi peut augmenter par intermittence dans les environnements qui utilisent un routeur Vigor

    En raison d'une condition de concurrence rare, lorsqu'une commande de mise hors tension de machine virtuelle est en conflit avec une fonction de rappel par un routeur Vigor, vous pouvez observer une augmentation de l'utilisation du CPU sur les hôtes ESXi (par exemple, après une mise à niveau).

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

  • PR 3165374 : les hôtes ESXi peuvent cesser de répondre et échouer avec un écran de diagnostic violet au cours de TIME_WAIT TCP

    Le temporisateur lent TCP peut bloquer le traitement d'entrée TCP alors qu'il couvre la liste des connexions dans TIME_WAIT qui ferment les connexions expirées en raison d'une contention sur le verrouillage pcbinfo TCP global. Par conséquent, VMkernel peut échouer avec un écran de diagnostic violet et l'erreur Spin count exceeded - possible deadlock lors du nettoyage des sockets TCP TIME_WAIT. La trace de débogage pointe vers des fonctions tcpip telles que tcp_slowtimo() ou tcp_twstart().

    Ce problème est résolu dans cette version. Le correctif ajoute un nouveau verrou global pour protéger la liste des connexions dans TIME_WAIT et pour acquérir le verrou tcpinfo TCP uniquement lors de la fermeture d'une connexion expirée.

  • PR 3166818 : si l'un des points de montage qui utilisent la même adresse IP de serveur NFS renvoie une erreur, VAAI-NAS peut marquer tous les points de montage comme non pris en charge

    Lorsque vous utilisez un plug-in de fournisseur VAAI-NAS, plusieurs systèmes de fichiers sur un hôte ESXi utilisent la même adresse IP de serveur NFS pour créer une banque de données. Pour certains fournisseurs NAS, si l'un des montages renvoie une erreur VIX_E_OBJECT_NOT_FOUND (25) lors de l'appel startSession, l'accélération matérielle de tous les systèmes de fichiers ayant la même adresse IP de serveur NFS peut ne plus être prise en charge. Ce problème se produit lorsqu'un hôte ESXi monte un répertoire sur un serveur NFS, mais que ce répertoire n'est pas disponible au moment de l'appel startSession (par exemple, parce qu'il a été déplacé de ce serveur NFS).

    Ce problème est résolu dans cette version. Le correctif s'assure que VAAI-NAS marque comme non pris en charge uniquement les montages qui signalent une erreur.

  • PR 3112692 : le pilote smartpqi ne peut pas obtenir l'emplacement des périphériques SSD SAS ThinkSystem PM1645a

    Dans de rares cas, le smartpqi plugin in LSU service peut obtenir une chaîne de numéro de série plus longue depuis la page VPD 0x80 que le numéro de série réel, et la recherche de périphériques dans le cache échoue. Par conséquent, lorsque vous exécutez la commande esxcli storage core device physical get -d <device_id> pour obtenir l'emplacement d'un périphérique, vous voyez une erreur telle que Unable to get location for device. Device is not found..

    Ce problème est résolu dans cette version. Le correctif s'assure que le smartpqi plugin in LSU service vérifie toujours la longueur correcte du numéro de série et trouve l'emplacement du périphérique.

  • PR 3100030 : un hôte ESXi échoue avec un écran de diagnostic violet indiquant une corruption du segment de mémoire VMFS

    Une condition de concurrence dans le cache de l'hôte d'une banque de données VMFS peut entraîner une corruption du segment de mémoire et l'hôte ESXi échoue avec un écran de diagnostic violet et un message tel que :

    PF Exception 14 in world xxxxx:res3HelperQu IP 0xxxxxxe2 addr 0xXXXXXXXXX

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

  • PR 3121216 : si le protocole ICMPA (Internet Control Message Protocol) n'est pas actif, le redémarrage de l'hôte ESXi peut prendre beaucoup de temps après une mise à niveau

    Si le protocole ICMPA n'est pas actif sur les serveurs NFS de votre environnement, après la mise à niveau de votre système, le redémarrage de l'hôte ESXi peut prendre une heure, car les opérations de restauration des banques de données NFS échouent. NFS utilise l'utilitaire vmkping pour identifier les adresses IP accessibles des serveurs NFS avant d'exécuter une opération de montage et, lorsque le protocole ICMP n'est pas actif, les opérations de montage échouent.

    Ce problème est résolu dans cette version. Pour supprimer la dépendance sur le protocole ICMP afin de rechercher des adresses IP accessibles, le correctif ajoute des API de socket pour garantir que les adresses IP sur un serveur NFS donné sont disponibles.

  • PR 3098760 : les hôtes ESXi se déconnectent de manière aléatoire du domaine Active Directory ou vCenter en raison de l'épuisement de la mémoire Likewise

    Des fuites de mémoire dans les opérations Active Directory et les bibliothèques associées, ou lorsque l'authentification par carte à puce est activée sur un hôte ESXi, peuvent entraîner l'épuisement de la mémoire Likewise.

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

  • PR 3118402 : la fonction de surveillance NTP renvoie un échec de synchronisation de l'heure intermittent dans le rapport de test des services de temps, même lorsque l'horloge système de l'hôte ESXi est correctement synchronisée

    L'infrastructure de surveillance des services de temps interroge périodiquement le démon NTP, ntpd, pour obtenir l'état de synchronisation de l'heure sur les hôtes ESXi. Des échecs de requête intermittents peuvent se produire en raison de délais d'expiration dans l'appel de socket pour lire ces informations d'état. Par conséquent, vous pouvez voir des alertes d'échec de synchronisation de l'heure dans les rapports de test NTP.

    Ce problème est résolu dans cette version. Le correctif s'assure que les requêtes de surveillance NTP n'échouent pas.

  • PR 3159168 : plusieurs messages « End path evaluation for device » s'affichent dans le fichier vmkernel.log

    Une sonde de périphérique périodique qui évalue l'état de tous les chemins d'accès à un périphérique peut créer plusieurs messages End path evaluation for device inutiles dans le fichier vmkernel.log sur une build de version.

    Ce problème est résolu dans cette version. Le correctif limite les messages End path evaluation for device aux builds de non-version, telles que les builds bêta. Vous devez activer le niveau de journalisation VERBOSE pour afficher ces journaux.

  • PR 3101512 : vous voyez un avertissement pour une perte de redondance de la liaison montante, même lorsque la liaison montante est active

    Si vous supprimez rapidement le câble réseau d'une carte réseau physique et que vous le réinsérez, l'agent hôte ESXi, hostd, déclenche un événement pour restaurer la redondance de la liaison montante. Pourtant, dans certains cas, bien que la liaison montante soit restaurée en une seconde, vous voyez toujours une alarme erronée qui indique une perte de redondance de la liaison montante.

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

  • PR 3161473 : les opérations avec des hôtes ESXi sans état peuvent ne pas choisir le disque distant prévu pour le cache système, ce qui entraîne des problèmes de correction ou de conformité

    Les opérations avec des hôtes ESXi sans état, telles que la migration du stockage, peuvent ne pas choisir le disque distant prévu pour le cache système. Par exemple, vous voulez conserver le nouveau LUN de démarrage en tant que LUN 0, mais vSphere Auto Deploy sélectionne LUN 1.

    Ce problème est résolu dans cette version. Le correctif offre un moyen cohérent de trier les disques distants et de toujours choisir le disque avec l'ID de LUN le plus faible. Pour vous assurer que vous activez le correctif, procédez comme suit :

    1. Sur la page Modifier le profil d'hôte de l'assistant Auto Deploy, sélectionnez Paramètres de configuration avancés > Configuration du cache SystemImage > Configuration du cache de l'image système

    2. Dans le menu déroulant Paramètres de profil du cache d'image système, sélectionnez Activer la mise en cache sans état sur l'hôte.

    3. Modifiez Arguments pour le premier disque en remplaçant remote par sortedremote et/ou remoteesx par sortedremoteesx.

ESXi-7.0U3so-22348808-standard

Nom du profil

ESXi-7.0U3so-22348808-standard

Build

Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.

Fournisseur

VMware, Inc.

Date de publication

28 septembre 2023

Niveau d'acceptation

PartnerSupported

Matériel concerné

S.O.

Logiciels concernés

S.O.

VIB concernés

  • VMware_bootbank_vsanhealth_7.0.3-0.100.22348808

  • VMware_bootbank_crx_7.0.3-0.100.22348808

  • VMware_bootbank_vdfs_7.0.3-0.100.22348808

  • VMware_bootbank_esxio-combiner_7.0.3-0.100.22348808

  • VMware_bootbank_native-misc-drivers_7.0.3-0.100.22348808

  • VMware_bootbank_esx-base_7.0.3-0.100.22348808

  • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.100.22348808

  • VMware_bootbank_cpu-microcode_7.0.3-0.100.22348808

  • VMware_bootbank_bmcal_7.0.3-0.100.22348808

  • VMware_bootbank_esx-ui_2.11.2-21988676

  • VMware_bootbank_gc_7.0.3-0.100.22348808

  • VMware_bootbank_trx_7.0.3-0.100.22348808

  • VMware_bootbank_vsan_7.0.3-0.100.22348808

  • VMware_bootbank_esx-xserver_7.0.3-0.100.22348808

  • VMware_bootbank_loadesx_7.0.3-0.100.22348808

  • VMware_bootbank_esx-update_7.0.3-0.100.22348808

  • VMware_locker_tools-light_12.2.6.22229486-22348808

PR résolus

3219441, 3239369, 3236018, 3232099, 3232034, 3222887, 3217141, 3213025, 3187868, 3186342, 3164962, 3089785, 3160789, 3098679, 3089785, 3256457, 3178522, 3178519

Numéros CVE associés

S/O

Ce correctif met à jour les problèmes suivants :

  • ESXi 7.0 Update 3o fournit les mises à jour de sécurité suivantes :

    • La bibliothèque cURL a été mise à jour vers la version 8.1.2.

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

    • La bibliothèque SQLite a été mise à jour vers la version 3.42.0.

    • Le module OpenSSL a été mis à jour vers la version 1.0.2zh.

  • Le VIB cpu-microcode inclut le microcode AMD suivant :

    Nom de code

    FMS

    Révision de MCU

    Date de MCU

    Noms de marque

    Bulldozer

    0x600f12 (15/01/2)

    0x0600063e

    07/02/2018

    Opteron série 6200/4200/3200

    Piledriver

    0x600f20 (15/02/0)

    0x06000852

    06/02/2018

    Opteron série 6300/4300/3300

    Zen-Naples

    0x800f12 (17/01/2)

    0x0800126e

    11/11/2021

    EPYC série 7001

    Zen2-Rome

    0x830f10 (31/17/0)

    0x0830107a

    17/05/2023

    EPYC série 7002/7Fx2/7Hx2

    Zen3-Milan-B1

    0xa00f11 (19/01/1)

    0x0a0011d1

    10/07/2023

    EPYC série 7003/7003X

    Zen3-Milan-B2

    0xa00f12 (19/01/2)

    0x0a001234

    10/07/2023

    EPYC série 7003/7003X

  • Les images ISO de VMware Tools suivantes sont intégrées à ESXi 7.0 Update 3o :

    • windows.iso : VMware Tools 12.2.6 prend en charge Windows 7 SP1 ou Windows Server 2008 R2 SP1 et versions ultérieures.

    • linux.iso: Image ISO de VMware Tools 10.3.25 pour le système d'exploitation Linux avec glibc 2.11 ou version ultérieure.

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

    • VMware Tools 11.0.6 :

      • windows.iso : pour Windows Vista (SP2) et Windows Server 2008 Service Pack 2 (SP2).

    • VMware Tools 10.0.12 :

      • winPreVista.iso : pour Windows 2000, Windows XP et Windows 2003.

      • linuxPreGLibc25.iso : prend en charge les systèmes d'exploitation invités Linux antérieurs à Red Hat Enterprise Linux (RHEL) 5, SUSE Linux Enterprise Server (SLES) 11, Ubuntu 7.04 et autres distributions avec glibc d'une version antérieure à la version 2.5.

    • solaris.iso: Image de VMware Tools 10.3.10 pour Solaris.

    • darwin.iso: Prend en charge Mac OS X 10.11 et versions ultérieures. VMware Tools 12.1.0 était la dernière version régulière pour macOS. Pour plus de détails, consultez l'article 88698 de la base de connaissances VMware.

    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 :

  • Le VIB cpu-microcode inclut le microcode Intel suivant :

    Nom de code

    FMS

    ID de PLT

    Révision de MCU

    Date de MCU

    Noms de marque

    Nehalem EP

    0x106a5 (06/1a/5)

    0x03

    0x1d

    11/05/2018

    Intel Xeon 35xx Series ; Intel Xeon 55xx Series

    Clarkdale

    0x20652 (06/25/2)

    0x12

    0x11

    08/05/2018

    Intel i3/i5 Clarkdale Series ; Intel Xeon 34xx Clarkdale Series

    Arrandale

    0x20655 (06/25/5)

    0x92

    0x7

    23/04/2018

    Processeur Intel Core i7-620LE

    Sandy Bridge DT

    0x206a7 (06/2a/7)

    0x12

    0x2f

    17/02/2019

    Intel Xeon E3-1100 Series ; Intel Xeon E3-1200 Series ; Intel i7-2655-LE Series ; Intel i3-2100 Series

    Westmere EP

    0x206c2 (06/2c/2)

    0x03

    0x1f

    08/05/2018

    Intel Xeon 56xx Series ; Intel Xeon 36xx Series

    Sandy Bridge EP

    0x206d6 (06/2d/6)

    0x6d

    0x621

    04/03/2020

    Intel Pentium 1400 Series ; Intel Xeon E5-1400 Series ; Intel Xeon E5-1600 Series ; Intel Xeon E5-2400 Series ; Intel Xeon E5-2600 Series ; Intel Xeon E5-4600 Series

    Sandy Bridge EP

    0x206d7 (06/2d/7)

    0x6d

    0x71a

    24/03/2020

    Intel Pentium 1400 Series ; Intel Xeon E5-1400 Series ; Intel Xeon E5-1600 Series ; Intel Xeon E5-2400 Series ; Intel Xeon E5-2600 Series ; Intel Xeon E5-4600 Series

    Nehalem EX

    0x206e6 (06/2e/6)

    0x04

    0xd

    15/05/2018

    Intel Xeon 65xx Series ; Intel Xeon 75xx Series

    Westmere EX

    0x206f2 (06/2f/2)

    0x05

    0x3b

    16/05/2018

    Intel Xeon E7-8800 Series ; Intel Xeon E7-4800 Series ; Intel Xeon E7-2800 Series

    Ivy Bridge DT

    0x306a9 (06/3a/9)

    0x12

    0x21

    13/02/2019

    Intel i3-3200 Series ; Intel i7-3500-LE/UE ; Intel i7-3600-QE ; Intel Xeon E3-1200-v2 Series ; Intel Xeon E3-1100-C-v2 Series ; Intel Pentium B925C

    Haswell DT

    0x306c3 (06/3c/3)

    0x32

    0x28

    12/11/2019

    Intel Xeon E3-1200-v3 Series ; Intel i7-4700-EQ Series ; Intel i5-4500-TE Series ; Intel i3-4300 Series

    Ivy Bridge EP

    0x306e4 (06/3e/4)

    0xed

    0x42e

    14/03/2019

    Intel Xeon E5-4600-v2 Series ; Intel Xeon E5-2600-v2 Series ; Intel Xeon E5-2400-v2 Series ; Intel Xeon E5-1600-v2 Series ; Intel Xeon E5-1400-v2 Series

    Ivy Bridge EX

    0x306e7 (06/3e/7)

    0xed

    0x715

    14/03/2019

    Intel Xeon E7-8800/4800/2800-v2 Series

    Haswell EP

    0x306f2 (06/3f/2)

    0x6f

    0x49

    11/08/2021

    Intel Xeon E5-4600-v3 Series ; Intel Xeon E5-2600-v3 Series ; Intel Xeon E5-2400-v3 Series ; Intel Xeon E5-1600-v3 Series ; Intel Xeon E5-1400-v3 Series

    Haswell EX

    0x306f4 (06/3f/4)

    0x80

    0x1a

    24/05/2021

    Intel Xeon E7-8800/4800-v3 Series

    Broadwell H

    0x40671 (06/47/1)

    0x22

    0x22

    12/11/2019

    Intel Core i7-5700EQ ; Intel Xeon E3-1200-v4 Series

    Avoton

    0x406d8 (06/4d/8)

    0x01

    0x12d

    16/09/2019

    Intel Atom C2300 Series ; Intel Atom C2500 Series ; Intel Atom C2700 Series

    Broadwell EP/EX

    0x406f1 (06/4f/1)

    0xef

    0xb000040

    19/05/2021

    Intel Xeon E7-8800/4800-v4 Series ; Intel Xeon E5-4600-v4 Series ; Intel Xeon E5-2600-v4 Series ; Intel Xeon E5-1600-v4 Series

    Skylake SP

    0x50654 (06/55/4)

    0xb7

    0x2007006

    6/03/2023

    Intel Xeon Platinum 8100 Series ; Intel Xeon Gold 6100/5100, Silver 4100, Bronze 3100 Series ; Intel Xeon D-2100 Series ; Intel Xeon D-1600 Series ; Intel Xeon W-3100 Series ; Intel Xeon W-2100 Series

    Cascade Lake B-0

    0x50656 (06/55/6)

    0xbf

    0x4003604

    17/03/2023

    Intel Xeon Platinum 9200/8200 Series ; Intel Xeon Gold 6200/5200 ; Intel Xeon Silver 4200/Bronze 3200 ; Intel Xeon W-3200

    Cascade Lake

    0x50657 (06/55/7)

    0xbf

    0x5003604

    17/03/2023

    Intel Xeon Platinum 9200/8200 Series ; Intel Xeon Gold 6200/5200 ; Intel Xeon Silver 4200/Bronze 3200 ; Intel Xeon W-3200

    Cooper Lake

    0x5065b (06/55/b)

    0xbf

    0x7002703

    21/03/2023

    Intel Xeon Platinum 8300 Series ; Intel Xeon Gold 6300/5300

    Broadwell DE

    0x50662 (06/56/2)

    0x10

    0x1c

    17/06/2019

    Intel Xeon D-1500 Series

    Broadwell DE

    0x50663 (06/56/3)

    0x10

    0x700001c

    12/06/2021

    Intel Xeon D-1500 Series

    Broadwell DE

    0x50664 (06/56/4)

    0x10

    0xf00001a

    12/06/2021

    Intel Xeon D-1500 Series

    Broadwell NS

    0x50665 (06/56/5)

    0x10

    0xe000014

    18/09/2021

    Intel Xeon D-1600 Series

    Skylake H/S

    0x506e3 (06/5e/3)

    0x36

    0xf0

    11/12/2021

    Intel Xeon E3-1500-v5 Series ; Intel Xeon E3-1200-v5 Series

    Denverton

    0x506f1 (06/5f/1)

    0x01

    0x38

    02/12/2021

    Intel Atom C3000 Series

    Ice Lake SP

    0x606a6 (06/6a/6)

    0x87

    0xd0003a5

    3/30/2023

    Intel Xeon Platinum 8300 Series ; Intel Xeon Gold 6300/5300 Series ; Intel Xeon Silver 4300 Series

    Ice Lake D

    0x606c1 (06/6c/1)

    0x10

    0x1000230

    27/01/2023

    Intel Xeon D-2700 Series ; Intel Xeon D-1700 Series

    Snow Ridge

    0x80665 (06/86/5)

    0x01

    0x4c000023

    22/02/2023

    Intel Atom P5000 Series

    Snow Ridge

    0x80667 (06/86/7)

    0x01

    0x4c000023

    22/02/2023

    Intel Atom P5000 Series

    Tiger Lake U

    0x806c1 (06/8c/1)

    0x80

    0xac

    27/02/2023

    Intel Core i3/i5/i7-1100 Series

    Actualisation de Tiger Lake U Refresh

    0x806c2 (06/8c/2)

    0xc2

    0x2c

    27/02/2023

    Intel Core i3/i5/i7-1100 Series

    Tiger Lake H

    0x806d1 (06/8d/1)

    0xc2

    0x46

    27/02/2023

    Intel Xeon W-11000E Series

    Sapphire Rapids SP HBM

    0x806f8 (06/8f/8)

    0x10

    0x2c0001d1

    14/02/2023

    Intel Xeon Max 9400 Series

    Sapphire Rapids SP

    0x806f8 (06/8f/8)

    0x87

    0x2b000461

    13/03/2023

    Intel Xeon Platinum 8400 Series ; Intel Xeon Gold 6400/5400 Series ; Intel Xeon Silver 4400 Series ; Intel Xeon Bronze 3400 Series

    Kaby Lake H/S/X

    0x906e9 (06/9e/9)

    0x2a

    0xf4

    23/02/2023

    Intel Xeon E3-1200-v6 Series ; Intel Xeon E3-1500-v6 Series

    Coffee Lake

    0x906ea (06/9e/a)

    0x22

    0xf4

    23/02/2023

    Intel Xeon E-2100 Series ; Intel Xeon E-2200 Series (4 ou 6 cœurs)

    Coffee Lake

    0x906eb (06/9e/b)

    0x02

    0xf4

    23/02/2023

    Intel Xeon E-2100 Series

    Coffee Lake

    0x906ec (06/9e/c)

    0x22

    0xf4

    23/02/2023

    Intel Xeon E-2100 Series

    Coffee Lake Refresh

    0x906ed (06/9e/d)

    0x22

    0xfa

    27/02/2023

    Intel Xeon E-2200 Series (8 cœurs)

    Rocket Lake S

    0xa0671 (06/a7/1)

    0x02

    0x59

    26/02/2023

    Intel Xeon E-2300 Series

ESXi-7.0U3so-22348808-no-tools

Nom du profil

ESXi-7.0U3so-22348808-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

28 septembre 2023

Niveau d'acceptation

PartnerSupported

Matériel concerné

S.O.

Logiciels concernés

S.O.

VIB concernés

  • VMware_bootbank_vsanhealth_7.0.3-0.100.22348808

  • VMware_bootbank_crx_7.0.3-0.100.22348808

  • VMware_bootbank_vdfs_7.0.3-0.100.22348808

  • VMware_bootbank_esxio-combiner_7.0.3-0.100.22348808

  • VMware_bootbank_native-misc-drivers_7.0.3-0.100.22348808

  • VMware_bootbank_esx-base_7.0.3-0.100.22348808

  • VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.3-0.100.22348808

  • VMware_bootbank_cpu-microcode_7.0.3-0.100.22348808

  • VMware_bootbank_bmcal_7.0.3-0.100.22348808

  • VMware_bootbank_esx-ui_2.11.2-21988676

  • VMware_bootbank_gc_7.0.3-0.100.22348808

  • VMware_bootbank_trx_7.0.3-0.100.22348808

  • VMware_bootbank_vsan_7.0.3-0.100.22348808

  • VMware_bootbank_esx-xserver_7.0.3-0.100.22348808

  • VMware_bootbank_loadesx_7.0.3-0.100.22348808

  • VMware_bootbank_esx-update_7.0.3-0.100.22348808

PR résolus

3219441, 3239369, 3236018, 3232099, 3232034, 3222887, 3217141, 3213025, 3187868, 3186342, 3164962, 3089785, 3160789, 3098679, 3089785, 3256457

Numéros CVE associés

S/O

Ce correctif met à jour les problèmes suivants :

  • ESXi 7.0 Update 3o fournit les mises à jour de sécurité suivantes :

    • La bibliothèque cURL a été mise à jour vers la version 8.1.2.

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

    • La bibliothèque SQLite a été mise à jour vers la version 3.42.0.

    • Le module OpenSSL a été mis à jour vers la version 1.0.2zh.

  • Le VIB cpu-microcode inclut le microcode AMD suivant :

    Nom de code

    FMS

    Révision de MCU

    Date de MCU

    Noms de marque

    Bulldozer

    0x600f12 (15/01/2)

    0x0600063e

    07/02/2018

    Opteron série 6200/4200/3200

    Piledriver

    0x600f20 (15/02/0)

    0x06000852

    06/02/2018

    Opteron série 6300/4300/3300

    Zen-Naples

    0x800f12 (17/01/2)

    0x0800126e

    11/11/2021

    EPYC série 7001

    Zen2-Rome

    0x830f10 (31/17/0)

    0x0830107a

    17/05/2023

    EPYC série 7002/7Fx2/7Hx2

    Zen3-Milan-B1

    0xa00f11 (19/01/1)

    0x0a0011d1

    10/07/2023

    EPYC série 7003/7003X

    Zen3-Milan-B2

    0xa00f12 (19/01/2)

    0x0a001234

    10/07/2023

    EPYC série 7003/7003X

  • Le VIB cpu-microcode inclut le microcode Intel suivant :

    Nom de code

    FMS

    ID de PLT

    Révision de MCU

    Date de MCU

    Noms de marque

    Nehalem EP

    0x106a5 (06/1a/5)

    0x03

    0x1d

    11/05/2018

    Intel Xeon 35xx Series ; Intel Xeon 55xx Series

    Clarkdale

    0x20652 (06/25/2)

    0x12

    0x11

    08/05/2018

    Intel i3/i5 Clarkdale Series ; Intel Xeon 34xx Clarkdale Series

    Arrandale

    0x20655 (06/25/5)

    0x92

    0x7

    23/04/2018

    Processeur Intel Core i7-620LE

    Sandy Bridge DT

    0x206a7 (06/2a/7)

    0x12

    0x2f

    17/02/2019

    Intel Xeon E3-1100 Series ; Intel Xeon E3-1200 Series ; Intel i7-2655-LE Series ; Intel i3-2100 Series

    Westmere EP

    0x206c2 (06/2c/2)

    0x03

    0x1f

    08/05/2018

    Intel Xeon 56xx Series ; Intel Xeon 36xx Series

    Sandy Bridge EP

    0x206d6 (06/2d/6)

    0x6d

    0x621

    04/03/2020

    Intel Pentium 1400 Series ; Intel Xeon E5-1400 Series ; Intel Xeon E5-1600 Series ; Intel Xeon E5-2400 Series ; Intel Xeon E5-2600 Series ; Intel Xeon E5-4600 Series

    Sandy Bridge EP

    0x206d7 (06/2d/7)

    0x6d

    0x71a

    24/03/2020

    Intel Pentium 1400 Series ; Intel Xeon E5-1400 Series ; Intel Xeon E5-1600 Series ; Intel Xeon E5-2400 Series ; Intel Xeon E5-2600 Series ; Intel Xeon E5-4600 Series

    Nehalem EX

    0x206e6 (06/2e/6)

    0x04

    0xd

    15/05/2018

    Intel Xeon 65xx Series ; Intel Xeon 75xx Series

    Westmere EX

    0x206f2 (06/2f/2)

    0x05

    0x3b

    16/05/2018

    Intel Xeon E7-8800 Series ; Intel Xeon E7-4800 Series ; Intel Xeon E7-2800 Series

    Ivy Bridge DT

    0x306a9 (06/3a/9)

    0x12

    0x21

    13/02/2019

    Intel i3-3200 Series ; Intel i7-3500-LE/UE ; Intel i7-3600-QE ; Intel Xeon E3-1200-v2 Series ; Intel Xeon E3-1100-C-v2 Series ; Intel Pentium B925C

    Haswell DT

    0x306c3 (06/3c/3)

    0x32

    0x28

    12/11/2019

    Intel Xeon E3-1200-v3 Series ; Intel i7-4700-EQ Series ; Intel i5-4500-TE Series ; Intel i3-4300 Series

    Ivy Bridge EP

    0x306e4 (06/3e/4)

    0xed

    0x42e

    14/03/2019

    Intel Xeon E5-4600-v2 Series ; Intel Xeon E5-2600-v2 Series ; Intel Xeon E5-2400-v2 Series ; Intel Xeon E5-1600-v2 Series ; Intel Xeon E5-1400-v2 Series

    Ivy Bridge EX

    0x306e7 (06/3e/7)

    0xed

    0x715

    14/03/2019

    Intel Xeon E7-8800/4800/2800-v2 Series

    Haswell EP

    0x306f2 (06/3f/2)

    0x6f

    0x49

    11/08/2021

    Intel Xeon E5-4600-v3 Series ; Intel Xeon E5-2600-v3 Series ; Intel Xeon E5-2400-v3 Series ; Intel Xeon E5-1600-v3 Series ; Intel Xeon E5-1400-v3 Series

    Haswell EX

    0x306f4 (06/3f/4)

    0x80

    0x1a

    24/05/2021

    Intel Xeon E7-8800/4800-v3 Series

    Broadwell H

    0x40671 (06/47/1)

    0x22

    0x22

    12/11/2019

    Intel Core i7-5700EQ ; Intel Xeon E3-1200-v4 Series

    Avoton

    0x406d8 (06/4d/8)

    0x01

    0x12d

    16/09/2019

    Intel Atom C2300 Series ; Intel Atom C2500 Series ; Intel Atom C2700 Series

    Broadwell EP/EX

    0x406f1 (06/4f/1)

    0xef

    0xb000040

    19/05/2021

    Intel Xeon E7-8800/4800-v4 Series ; Intel Xeon E5-4600-v4 Series ; Intel Xeon E5-2600-v4 Series ; Intel Xeon E5-1600-v4 Series

    Skylake SP

    0x50654 (06/55/4)

    0xb7

    0x2007006

    6/03/2023

    Intel Xeon Platinum 8100 Series ; Intel Xeon Gold 6100/5100, Silver 4100, Bronze 3100 Series ; Intel Xeon D-2100 Series ; Intel Xeon D-1600 Series ; Intel Xeon W-3100 Series ; Intel Xeon W-2100 Series

    Cascade Lake B-0

    0x50656 (06/55/6)

    0xbf

    0x4003604

    17/03/2023

    Intel Xeon Platinum 9200/8200 Series ; Intel Xeon Gold 6200/5200 ; Intel Xeon Silver 4200/Bronze 3200 ; Intel Xeon W-3200

    Cascade Lake

    0x50657 (06/55/7)

    0xbf

    0x5003604

    17/03/2023

    Intel Xeon Platinum 9200/8200 Series ; Intel Xeon Gold 6200/5200 ; Intel Xeon Silver 4200/Bronze 3200 ; Intel Xeon W-3200

    Cooper Lake

    0x5065b (06/55/b)

    0xbf

    0x7002703

    21/03/2023

    Intel Xeon Platinum 8300 Series ; Intel Xeon Gold 6300/5300

    Broadwell DE

    0x50662 (06/56/2)

    0x10

    0x1c

    17/06/2019

    Intel Xeon D-1500 Series

    Broadwell DE

    0x50663 (06/56/3)

    0x10

    0x700001c

    12/06/2021

    Intel Xeon D-1500 Series

    Broadwell DE

    0x50664 (06/56/4)

    0x10

    0xf00001a

    12/06/2021

    Intel Xeon D-1500 Series

    Broadwell NS

    0x50665 (06/56/5)

    0x10

    0xe000014

    18/09/2021

    Intel Xeon D-1600 Series

    Skylake H/S

    0x506e3 (06/5e/3)

    0x36

    0xf0

    11/12/2021

    Intel Xeon E3-1500-v5 Series ; Intel Xeon E3-1200-v5 Series

    Denverton

    0x506f1 (06/5f/1)

    0x01

    0x38

    02/12/2021

    Intel Atom C3000 Series

    Ice Lake SP

    0x606a6 (06/6a/6)

    0x87

    0xd0003a5

    3/30/2023

    Intel Xeon Platinum 8300 Series ; Intel Xeon Gold 6300/5300 Series ; Intel Xeon Silver 4300 Series

    Ice Lake D

    0x606c1 (06/6c/1)

    0x10

    0x1000230

    27/01/2023

    Intel Xeon D-2700 Series ; Intel Xeon D-1700 Series

    Snow Ridge

    0x80665 (06/86/5)

    0x01

    0x4c000023

    22/02/2023

    Intel Atom P5000 Series

    Snow Ridge

    0x80667 (06/86/7)

    0x01

    0x4c000023

    22/02/2023

    Intel Atom P5000 Series

    Tiger Lake U

    0x806c1 (06/8c/1)

    0x80

    0xac

    27/02/2023

    Intel Core i3/i5/i7-1100 Series

    Actualisation de Tiger Lake U Refresh

    0x806c2 (06/8c/2)

    0xc2

    0x2c

    27/02/2023

    Intel Core i3/i5/i7-1100 Series

    Tiger Lake H

    0x806d1 (06/8d/1)

    0xc2

    0x46

    27/02/2023

    Intel Xeon W-11000E Series

    Sapphire Rapids SP HBM

    0x806f8 (06/8f/8)

    0x10

    0x2c0001d1

    14/02/2023

    Intel Xeon Max 9400 Series

    Sapphire Rapids SP

    0x806f8 (06/8f/8)

    0x87

    0x2b000461

    13/03/2023

    Intel Xeon Platinum 8400 Series ; Intel Xeon Gold 6400/5400 Series ; Intel Xeon Silver 4400 Series ; Intel Xeon Bronze 3400 Series

    Kaby Lake H/S/X

    0x906e9 (06/9e/9)

    0x2a

    0xf4

    23/02/2023

    Intel Xeon E3-1200-v6 Series ; Intel Xeon E3-1500-v6 Series

    Coffee Lake

    0x906ea (06/9e/a)

    0x22

    0xf4

    23/02/2023

    Intel Xeon E-2100 Series ; Intel Xeon E-2200 Series (4 ou 6 cœurs)

    Coffee Lake

    0x906eb (06/9e/b)

    0x02

    0xf4

    23/02/2023

    Intel Xeon E-2100 Series

    Coffee Lake

    0x906ec (06/9e/c)

    0x22

    0xf4

    23/02/2023

    Intel Xeon E-2100 Series

    Coffee Lake Refresh

    0x906ed (06/9e/d)

    0x22

    0xfa

    27/02/2023

    Intel Xeon E-2200 Series (8 cœurs)

    Rocket Lake S

    0xa0671 (06/a7/1)

    0x02

    0x59

    26/02/2023

    Intel Xeon E-2300 Series

ESXi7.0U3o - 22348816

Nom

ESXi

Version

ESXi7.0U3o - 22348816

Date de publication

28 septembre 2023

Catégorie

Correctif de bogues

Composants concernés

  • Composant ESXi - ESXi principal

  • Installation/mise à niveau d'ESXi

  • Pilote AHCI natif VMware

  • Plug-in de gestion de LSU SMARTPQI

  • Pilote de contrôleur de mémoire non volatile

  • Pilote SAS MPT 12 Gbit/s natif Avago (LSI)

  • Pilote Intel NVME avec technologie VMD

PR résolus

3244098, 3216958, 3245763, 3242021, 3246132, 3253205, 3256804, 3239170, 3251981, 3215370, 3117615, 3248478, 3252676, 3235496, 3238026, 3236064, 3224739, 3224306, 3223755, 3216958, 3233958, 3185125, 3219264, 3221620, 3218835, 3185560, 3221099, 3211625, 3221860, 3228586, 3224604, 3223539, 3222601, 3217258, 3213041, 3216522, 3221591, 3216389, 3220004, 3217633, 3216548, 3216449, 3156666, 3181574, 3180746, 3155476, 3211807, 3154090, 3184008, 3183519, 3183519, 3209853, 3100552, 3187846, 3113263, 3176350, 3185827, 3095511, 3184425, 3186351, 3186367, 3154090, 3158524, 3181601, 3180391, 3180283, 3184608, 3181774, 3155476, 3163361, 3182978, 3184368, 3160456, 3164575, 3181901, 3184871, 3166818, 3157195, 3164355, 3163271, 3112194, 3161690, 3261925, 3178589, 3178721, 3162963, 3168950, 3159168, 3158491, 3158866, 3096769, 3165374, 3122037, 3098760, 3164439, 3161473, 3162790, 3100030, 3096974, 3161473, 3165651, 3083007, 3118240, 3151076, 3118402, 3160480, 3156627, 3158531, 3162499, 3158512, 3053430, 3153395, 3117615, 3099192, 3158508, 3115870, 3119834, 3158220, 3110401, 2625439, 3099357, 3152811, 3108979, 3120165, 3245953, 3178109, 3211395, 3164477, 3119959, 3164462, 3036883, 3112692, 3218578, 3224847

Numéros CVE associés

S/O

Ce correctif résout les problèmes répertoriés dans ESXi-7.0U3o-22348816-standard.

ESXi7.0U3so - 22348808

Nom

ESXi

Version

ESXi7.0U3so - 22348808

Date de publication

28 septembre 2023

Catégorie

Sécurité

Composants concernés

  • Composant ESXi - VIB ESXi principaux

  • Composant d'installation/mise à niveau d'ESXi

  • Composant ESXi Tools

PR résolus

3219441, 3239369, 3236018, 3232099, 3232034, 3222887, 3217141, 3213025, 3187868, 3186342, 3164962, 3089785, 3160789, 3098679, 3089785, 3256457, 3178522, 3178519

Numéros CVE associés

S/O

Ce correctif résout les problèmes répertoriés dans ESXi-7.0U3so-22348808-standard.

Problèmes connus

Problèmes de vSAN

  • PR 2962316 : le service de fichiers vSAN ne prend pas en charge les délégations NFSv4

    Le service de fichiers vSAN ne prend pas en charge les délégations NFSv4 dans cette version.

    Solution : aucune.

  • PR 3235496 : les applications sur un cluster vSAN cessent de répondre par intermittence

    Si l'option avancée preferHT est activée sur un serveur AMD dans un cluster vSAN, les CPU virtuels d'une machine virtuelle s'exécutent sur le même cache de dernier niveau. Lorsque les CPU virtuels sont tous très occupés et qu'un thread NVMe pour gérer les E/S s'exécute également sur le même cache de dernier niveau, le thread NVMe prend beaucoup de temps à se terminer, car il est en concurrence pour les ressources de CPU avec les machines virtuelles occupées. Par conséquent, la latence d'E/S est très élevée et peut entraîner une absence de réponse intermittente du stockage et des applications sur le cluster vSAN. Dans le backlog, vous voyez des erreurs telles que Lost access to volume <uuid> due to connectivity issues. Recovery attempt is in progress and outcome will be reported shortly.

    Solution : utilisez la commande esxcli system settings advanced set -o /Misc/vmknvmeCwYield -I 0 pour éviter toute concurrence entre la file d'attente d'achèvement NVMe et les CPU virtuels occupés.

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

Problèmes des services de cluster vSphere (vCLS)

  • Vous voyez des problèmes de compatibilité dans les nouvelles machines virtuelles vCLS déployées dans l'environnement vSphere 7.0 Update 3

    Le nom par défaut des nouvelles machines virtuelles vCLS déployées dans l'environnement vSphere 7.0 Update 3 utilise le modèle vCLS-UUID. Les machines virtuelles vCLS créées dans des versions antérieures de vCenter Server continuent d'utiliser le modèle vCLS (n). L'utilisation de parenthèses () n'étant pas prise en charge par de nombreuses solutions qui opèrent avec vSphere, vous pouvez rencontrer des problèmes de compatibilité.

    Solution : reconfigurez vCLS à l'aide du mode de retraitement après la mise à jour vers vSphere 7.0 Update 3.

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.

  • Des partitions VFAT endommagées d'un environnement vSphere 6.7 peuvent entraîner l'échec des mises à niveau vers ESXi 7.x

    En raison de partitions VFAT endommagées à partir d'un environnement vSphere 6.7, le repartitionnement des disques de démarrage d'un hôte ESXi peut échouer lors d'une mise à niveau vers ESXi 7.x. Par conséquent, vous pouvez voir les erreurs suivantes :

    Lors de la mise à niveau vers ESXi 7.0 Update 3l, l'opération échoue avec un écran de diagnostic violet et/ou une erreur telle que :

    • An error occurred while backing up VFAT partition files before re-partitioning: Failed to calculate size for temporary Ramdisk: <error> .

    • An error occurred while backing up VFAT partition files before re-partitioning: Failed to copy files to Ramdisk: <error>.

      Si vous utilisez un programme d'installation ISO, les erreurs s'affichent, mais pas l'écran de diagnostic violet.

    Lors de la mise à niveau vers une version d'ESXi 7.x antérieure à la version 7.0 Update 3l, vous pouvez voir :

    • Les journaux tels que ramdisk (root) is full dans le fichier vmkwarning.log.

    • Restauration inattendue vers ESXi 6.5 ou 6.7 lors du redémarrage.

    • Les partitions /bootbank, /altbootbank et ESX-OSData sont absentes.

    Solution : vous devez d'abord corriger les partitions endommagées avant de terminer la mise à niveau vers ESXi 7.x. Pour plus de détails, consultez l'article 91136 de la base de connaissances VMware.

  • 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. ​Please refer to the log file for more details.

    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.cfgFailed to load crypto64.efiFatal 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) 12021-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=DEBUG2021-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 extensions2021-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 :

    Cannot find VIB(s) ... in the given VIB collection.Ignoring missing reserved VIB(s) ..., they are removed from reserved VIB IDs.

    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 profile 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]
 The pending transaction requires 244 MB free space, however the maximum supported size is 239 MB.
 Please refer to the log file for more details.

    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 version ultérieure, puis mettre à jour vers 7.0 Update 1c. Vous pouvez également exécuter une mise à niveau à l'aide d'une image ISO et de vSphere Lifecycle Manager.

  • Vous ne pouvez pas migrer des clones liés dans des serveurs vCenter Server

    Si vous migrez un clone lié entre des systèmes vCenter Server, des opérations telles que la mise sous tension et la suppression peuvent échouer pour la machine virtuelle source avec une erreur Invalid virtual machine state.

    Solution : Conservez les clones liés sur la même instance de vCenter Server que la machine virtuelle source. Vous pouvez également promouvoir le clone lié au rang de clone complet avant la migration.

  • La migration entre des serveurs vCenter Server de machines virtuelles disposant de nombreux disques virtuels et niveaux de snapshot vers une banque de données sur un stockage NVMe over TCP peut échouer

    La migration entre des serveurs vCenter Server de machines virtuelles ayant plus de 180 disques virtuels et 32 niveaux de snapshot vers une banque de données sur un stockage NVMe over TCP peut échouer. L'hôte ESXi échoue de manière préventive avec une erreur telle que The migration has exceeded the maximum switchover time of 100 second(s).

    Solution : aucune.

  • Une machine virtuelle sur laquelle des compteurs de surveillance des performances virtuels (VPMC) sont activés peut ne pas parvenir à migrer entre des hôtes ESXi

    Si vous tentez de migrer une machine virtuelle sur laquelle VPMC est activé à l'aide de vSphere vMotion, l'opération peut échouer si l'hôte cible utilise certains des compteurs pour calculer les statistiques de mémoire ou de performances. L'opération échoue avec une erreur telle que A performance counter used by the guest is not available on the host CPU.

    Solution : mettez hors tension la machine virtuelle et utilisez la migration à froid. Pour plus d'informations, reportez-vous à l'article 81191 de la base de connaissances VMware.

  • Si une opération d'installation, de mise à niveau ou de suppression d'un VIB en direct précède immédiatement une mise à niveau interactive ou basée sur un script vers ESXi 7.0 Update 3 à l'aide de l'image ISO du programme d'installation, la mise à niveau échoue

    Lorsqu'une opération d'installation, de mise à niveau ou de suppression d'un VIB précède immédiatement une mise à niveau interactive ou basée sur un script vers ESXi 7.0 Update 3 à l'aide de l'image ISO du programme d'installation, ConfigStore peut ne pas conserver certaines configurations de la mise à niveau. Par conséquent, les hôtes ESXi deviennent inaccessibles après l'opération de mise à niveau, bien que la mise à niveau semble avoir réussi. Pour éviter ce problème, le programme d'installation d'ESXi 7.0 Update 3 ajoute une vérification temporaire pour bloquer ces scénarios. Dans la console du programme d'installation d'ESXi, le message d'erreur suivant s'affiche : Live VIB installation, upgrade or removal may cause subsequent ESXi upgrade to fail when using the ISO installer

    Solution : Utilisez une autre méthode de mise à niveau pour éviter le problème, comme l'utilisation d'ESXCLI ou 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 propriété vlanid dans les scripts d'installation personnalisés peut ne pas fonctionner

    Si vous utilisez un script d'installation personnalisé qui définit la propriété vlanid pour spécifier un VLAN souhaité, cette propriété peut ne pas prendre effet sur les hôtes ESXi récemment installés. Ce problème se produit uniquement lorsqu'une carte réseau physique est déjà connectée à DHCP au démarrage de l'installation. La propriété vlanid fonctionne correctement lorsque vous utilisez une carte réseau récemment connectée.

    Solution : définissez manuellement le VLAN à partir de l'interface utilisateur de la console directe après le démarrage de l'hôte ESXi. Vous pouvez également désactiver la carte réseau physique, puis démarrer l'hôte.

  • Sur les serveurs HPE avec démarrage du module de plate-forme sécurisée (TPM), l'attestation à distance échoue

    Certains serveurs HPE ne disposent pas d'un espace de journal des événements suffisant pour terminer correctement l'attestation à distance du TPM. Par conséquent, VMkernel démarre, mais l'attestation à distance échoue, car le journal est tronqué.

    Solution : aucune.

  • 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 IP already exists in the network. 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 modulemax_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 VDS, 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 <span>vCenter Server</span> é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 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 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.

  • La restauration du commutateur vSphere Distributed Switch (VDS) convergé vers NSX-T VDS n'est pas prise en charge dans vSphere 7.0 Update 3

    La restauration d'un VDS convergé qui prend en charge le trafic vSphere 7 et le trafic NSX-T 3 sur le même VDS vers un trafic N-VDS pour NSX-T n'est pas prise en charge dans vSphere 7.0 Update 3.

    Solution : aucune.

  • Si vous ne définissez pas le paramètre du module de pilote réseau nmlx5, la connectivité réseau ou les hôtes ESXi peuvent échouer

    Si vous ne définissez pas le paramètre de module supported_num_ports pour le pilote nmlx5_core sur un hôte ESXi ayant plusieurs adaptateurs réseau des versions Mellanox ConnectX-4, Mellanox ConnectX-5 et Mellanox ConnectX-6, le pilote peut ne pas allouer suffisamment de mémoire pour faire fonctionner tous les ports de NIC de l'hôte. Par conséquent, vous pouvez subir une perte de réseau ou une panne de l'hôte ESXi avec un écran de diagnostic violet, ou les deux.

    Solution : dans le pilote réseau nmlx5_core, définissez la valeur du paramètre du module supported_num_ports sur le nombre total de ports d'adaptateur réseau Mellanox ConnectX-4, Mellanox ConnectX-5 et Mellanox ConnectX-6 sur l'hôte ESXi.

  • 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 vSphere Distributed Switch (VDS), 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 VDS, 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 VDS.

  • É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.

  • 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: Failed to reserve device. Function not implemented

    Exemple :

    # voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>
Running VMFS Checker version 2.1 in check mode
Initializing LVM metadata, Basic Checks will be done

Checking for filesystem activity
Performing filesystem liveness check..|Scanning for VMFS-6 host activity (4096 bytes/HB, 1024 HBs).
ERROR: Failed to reserve device. Function not implemented
Aborting VMFS volume check
VOMA failed to check device : General Error

    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'VM reconfigure API peuvent échouer avec le message d'erreur suivant :

    Cannot decrypt disk because key or password is incorrect.

    Solution : utilisez l'attachDisk API plutôt que l'VM reconfigure API 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 APD (All Paths Down) 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 :

    The object or item referred to could not be found.

    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 The operation is not allowed in the current state.

    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

  • É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.

  • Les opérations de snapshot de machine virtuelle échouent dans les banques de données vSphere Virtual Volumes sur Purity version 5.3.10

    Les opérations de snapshot de machine virtuelle échouent dans les banques de données vSphere Virtual Volumes sur Purity version 5.3.10 avec une erreur telle que An error occurred while saving the snapshot: The VVol target encountered a vendor specific error. Le problème est spécifique de Purity version 5.3.10.

    Solution : effectuez une mise à niveau vers Purity version 6.1.7 ou suivez les recommandations du fournisseur.

  • 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 precustomization 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 postcustomization s'exécute ensuite. Si vous activez Cloud-Init dans le système d'exploitation invité d'une machine virtuelle, la section postcustomization 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 Failed waiting for data. Error 195887167. Connection closed by remote host, possibly due to timeout.

    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

  • 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 : Applying HA VIBs on the cluster encountered a failure.

    • La correction de vSphere HA échoue : A general system error occurred: Failed to get Effective Component map.

    • La désactivation de vSphere HA échoue : échec de la tâche de suppression de la solution. A general system error occurred: Cannot find hardware support package from depot or hardware support manager.

    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 : iofilter XXX already exists. 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 : Applying HA VIBs on the cluster encountered a failure.

    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 : Setting desired image spec for cluster failed.

    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: Unable to access the virtual machine configuration: Unable to access file[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 : Unable to access the virtual machine configuration: Unable to access file[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 in world 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 : Timeout! Failed to complete in 72000 seconds

    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 : Failed to retrieve appliance storage list

    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.

    Enabled SSL protocols Le paramètre de configuration n'est pas configuré 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 : No valid coredump partition found.

    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 vSphere Storage vMotion de machines virtuelles vers une banque de données vSAN 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 telle que An error occurred while saving the snapshot: A digest operation has failed 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.

  • Si vous mettez à niveau les hôtes ESXi vers la version 7.0 Update 3, mais que votre vCenter Server est d'une version antérieure, l'attestation TPM (Trusted Platform Module) des hôtes ESXi échoue

    Si vous mettez à niveau les hôtes ESXi vers la version 7.0 Update 3, mais que votre vCenter Server est d'une version antérieure et que vous activez le module TPM, les hôtes ESXi ne parviennent pas à transmettre l'attestation. Dans vSphere Client, vous voyez l'avertissement Alarme d'attestation TPM de l'hôte. L'algorithme ECDSA (Elliptic Curve Digital Signature Algorithm) introduit dans ESXi 7.0 Update 3 entraîne ce problème lorsque la version du système vCenter Server n'est pas la version 7.0 Update 3.

    Solution : mettez à niveau votre instance de vCenter Server vers la version 7.0 Update 3 ou reconnaissez l'alarme.

  • Vous voyez des avertissements sur l'écran du chargeur de démarrage concernant les balises d'actifs TPM

    Si un hôte ESXi sur lequel TPM est activé n'a pas de balise d'actif définie, vous pouvez voir des messages d'avertissement inactifs dans l'écran du chargeur de démarrage tels que :

    Failed to determine TPM asset tag size: Buffer too smallFailed to measure asset tag into TPM: Buffer too small

    Solution : ignorez les avertissements ou définissez une balise d'actif à l'aide de la commande $ esxcli hardware tpm tag set -d

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

  • Si un hôte ESXi échoue avec un écran de diagnostic violet, le service netdump peut cesser de fonctionner

    Dans de rares cas, si un hôte ESXi échoue avec un écran de diagnostic violet, le service netdump peut échouer avec une erreur telle que NetDump FAILED: Couldn't attach to dump server at IP x.x.x.x.

    Solution : configurez le vidage de mémoire VMkernel pour utiliser le stockage local.

  • Vous voyez fréquemment des vidages de mémoire VMware Fault Domain Manager (FDM) sur plusieurs hôtes ESXi

    Dans certains environnements, le nombre de banques de données peut dépasser la limite de descripteur de fichier FDM. Par conséquent, vous voyez des vidages de mémoire fréquents sur plusieurs hôtes ESXi indiquant un échec de FDM.

    Solution : augmentez la limite du descripteur de fichier FDM à 2 048. Vous pouvez utiliser le paramètre das.config.fdm.maxFds à partir des options avancées de vSphere HA dans vSphere Client. Pour plus d'informations, consultez Définir les options avancées.

  • Les machines virtuelles sur un cluster vSAN ayant une instance activée de NSX-T et un commutateur vSphere Distributed Switch (CVDS) convergé dans une zone de transport VLAN ne peuvent pas être mises sous tension après une mise hors tension

    Si le disque d'un site secondaire est saturé à 95 % et que les machines virtuelles sont mises hors tension avant la simulation d'une panne de site secondaire, certaines machines virtuelles ne parviennent pas à se mettre sous tension lors de la récupération. Par conséquent, les machines virtuelles cessent de répondre. Ce problème se produit même si la récupération de site inclut l'ajout de disques, d'hôtes ESXi ou de capacité de CPU.

    Solution : sélectionnez les machines virtuelles qui ne se mettent pas sous tension et modifiez le réseau en réseau de machines virtuelles dans Modifier les paramètres, dans le menu contextuel VM.

  • Les hôtes ESXi peuvent échouer avec un écran de diagnostic violet avec une erreur Assert at bora/modules/vmkernel/vmfs/fs6Journal.c:835

    Dans de rares cas, par exemple lors de l'exécution de tests SESparse, le nombre de verrous par transaction dans une banque de données VMFS peut dépasser la limite de 50 pour le paramètre J6_MAX_TXN_LOCKACTIONS. Par conséquent, les hôtes ESXi peuvent échouer avec un écran de diagnostic violet avec l'erreur Assert at bora/modules/vmkernel/vmfs/fs6Journal.c:835.

    Solution : aucune.

  • Si vous modifiez le paramètre netq_rss_ens du pilote nmlx5_core, les hôtes ESXi peuvent échouer avec un écran de diagnostic violet

    Si vous tentez d'activer le paramètre netq_rss_ens lors de la configuration d'un chemin de données amélioré sur le pilote nmlx5_core, les hôtes ESXi peuvent échouer avec un écran de diagnostic violet. Le paramètre netq_rss_ens , qui active NetQ RSS, est désactivé par défaut avec une valeur de 0.

    Solution : conservez la valeur par défaut pour le paramètre du module netq_rss_ens dans le pilote nmlx5_core .

  • 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 mise à niveau vers ESXi 7.0 Update 3 peut échouer en raison du changement de nom du pilote réseau i40enu de la boîte de réception

    à partir de vSphere 7.0 Update 3, le nom du pilote réseau i40enu de la boîte de réception pour ESXi redevient i40en. Le pilote i40en a été renommé i40enu dans vSphere 7.0 Update 2, mais le changement de nom a eu un impact sur certains chemins de mise à niveau. Par exemple, la mise à niveau cumulée des hôtes ESXi que vous gérez avec des lignes de base et des groupes de lignes de base de la version 7.0 Update 2 ou 7.0 Update 2a vers la version 7.0 Update 3 échoue. Dans la plupart des cas, le pilote i40enu est mis à niveau vers ESXi 7.0 Update 3 sans aucune étape supplémentaire. Cependant, si la mise à niveau du pilote échoue, vous ne pouvez pas mettre à jour les hôtes ESXi que vous gérez avec des lignes de base et des groupes de lignes de base. Vous ne pouvez pas non plus utiliser l'amorçage de l'hôte ou une image unique de vSphere Lifecycle Manager pour gérer les hôtes ESXi. Si vous avez déjà apporté des modifications liées au pilote et aux périphériques i40enu dans votre système, avant de procéder à la mise à niveau vers ESXi 7.0 Update 3, vous devez désinstaller le VIB ou le composant i40enu sur ESXi, ou d'abord mettre à niveau ESXi vers ESXi 7.0 Update 2c.

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

  • L'accès SSH échoue après la mise à niveau vers ESXi 7.0 Update 3d

    Après la mise à niveau vers ESXi 7.0 Update 3d, l'accès SSH peut échouer dans certaines conditions en raison d'une mise à jour d'OpenSSH vers la version 8.8.

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

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

    Un périphérique de modem USB peut réclamer simultanément plusieurs interfaces par VMkernel et bloquer le relais de périphérique vers des machines virtuelles.

    Solution : vous devez appliquer la configuration avancée USB.quirks sur l'hôte ESXi pour ignorer l'interface NET de VMkernel et autoriser le modem USB à passer le relais vers les machines virtuelles. Vous pouvez appliquer la configuration de 3 manières différentes :

    1. Accédez à ESXi Shell et exécutez la commande suivante : esxcli system settings advanced set -o /USB/quirks -s 0xvvvv:0xpppp:0:0xffff:UQ_NET_IGNORE | |- Device Product ID |------- Device Vendor ID

      Par exemple, pour Gemalto M2M GmbH Zoom 4625 Modem(vid:pid/1e2d:005b), vous pouvez avoir la commande :

      esxcli system settings advanced set -o /USB/quirks -s 0x1e2d:0x005b:0:0xffff:UQ_NET_IGNORE

      Redémarrez l'hôte ESXi.

    2. Définissez la configuration avancée à partir de vSphere Client ou de vSphere Web Client et redémarrez l'hôte ESXi.

    3. Utilisez un profil d'hôte pour appliquer la configuration avancée.

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

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

Problèmes de vSphere Client

  • Le fabricant du BIOS s'affiche comme « -- » dans vSphere Client

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

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

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