ESXi 7.0 Update 2 | 9 mars 2021 | Build ISO 17630552

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

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

  • vSphere Fault Tolerance prend en charge le chiffrement des machines virtuelles vSphere : À partir de vSphere 7.0 Update 2, vSphere FT prend en charge le chiffrement des machines virtuelles. Le chiffrement dans l’invité et le chiffrement basé sur la baie ne dépendent pas du chiffrement des machines virtuelles ou n’interfèrent pas avec celui-ci, mais l’utilisation de plusieurs couches de chiffrement utilise des ressources de calcul supplémentaires, ce qui peut avoir une incidence sur les performances de la machine virtuelle. L'impact varie selon le matériel, la quantité et le type d'E/S. Par conséquent, VMware ne peut pas le quantifier, mais l'impact global sur les performances est négligeable pour la plupart des charges de travail. L'efficacité et la compatibilité des fonctionnalités de stockage principal telles que la déduplication, la compression et la réplication peuvent également être affectées par le chiffrement des machines virtuelles et vous devez prévoir des compromis de stockage. Pour plus d'informations, reportez-vous aux sections Chiffrement des machines virtuelles et Meilleures pratiques de chiffrement des machines virtuelles.
     
  • ESXi 7.0 Update 2 prend en charge vSphere Quick Boot sur les serveurs suivants :
    • Dell Inc.
      • PowerEdge M830
      • PowerEdge R830
    • HPE
      • ProLiant XL675d Gen10 Plus
    • Lenovo 
      • ThinkSystem SR 635
      • ThinkSystem SR 655
         
  • Certains fichiers de configuration ESXi passent en lecture seule : À partir d'ESXi 7.0 Update 2, la configuration précédemment stockée dans les fichiers /etc/keymap, /etc/vmware/welcome, /etc/sfcb/sfcb.cfg, /etc/vmware/snmp.xml, /etc/vmware/logfilters, /etc/vmsyslog.conf et dans les fichiers /etc/vmsyslog.conf.d/*.conf réside désormais dans la base de données ConfigStore. Cette configuration peut uniquement être modifiée à l'aide de commandes ESXCLI et non en modifiant des fichiers. Pour plus d'informations, reportez-vous aux articles 82637 et 82638 de la base de connaissances VMware.
     
  • Statistiques VMware vSphere Virtual Volumes pour un meilleur débogage : ESXi 7.0 Update 2 vous permet de suivre les statistiques de performances de vSphere Virtual Volumes afin d'identifier rapidement les problèmes tels que la latence dans les réponses du fournisseur VASA tiers. À l'aide d'un ensemble de commandes, vous pouvez obtenir des statistiques pour tous les fournisseurs VASA de votre système, pour un espace de noms ou une entité spécifié dans l'espace de noms donné, ou pour l'espace de noms complet lorsque vous activez le suivi des statistiques pour celui-ci. Pour plus d'informations, reportez-vous à la section Collecte des informations statistiques relatives aux VVols.
     
  • Prise en charge de l'аrchitecture NVIDIA Ampere : vSphere 7.0 Update 2 prend désormais en charge l'architecture NVIDIA Ampere qui permet d'effectuer une formation AI/ML de haut niveau et de traiter des charges de travail d'inférence ML à l'aide de la capacité accélérée du GPU A100. En outre, vSphere 7.0 Update 2 améliore le partage et l'utilisation du GPU via la prise en charge de la technologie MIG (Multi-Instance GPU, GPU à plusieurs instances). vSphere 7.0 Update 2 offre également des performances améliorées pour la communication périphérique à périphérique basée sur la fonctionnalité NVIDIA GPUDirect existante, en activant les services ATS (Address Translation Services, services de conversion d'adresses) et les services ACS (Access Control Services, services de contrôle d'accès) sur la couche de bus PCIe dans le noyau ESXi.
     
  • Prise en charge des NIC Mellanox ConnectX-6 200G: ESXi 7.0 Update 2 prend en charge les NIC 200G des gammes Mellanox Technologies MT28908 Family (ConnectX-6) et Mellanox Technologies MT2892 Family (ConnectX-6 Dx).
     
  • Améliorations des performances pour les CPU AMD Zen : avec ESXi 7.0 Update 2, l'accroissement des performances du CPU AMD Zen grâce aux optimisations prêtes à l'emploi peut atteindre 30 % dans différentes évaluations. Le planificateur ESXi mis à jour tire pleinement parti de l'architecture NUMA d'AMD pour effectuer les placements les plus appropriés pour les machines virtuelles et les conteneurs. Les optimisations du CPU AMD Zen permettent un plus grand nombre de déploiements de machines virtuelles ou de conteneurs avec de meilleures performances.
     
  • Réduction de la latence des calculs et des E/S, et de la gigue pour les charges de travail sensibles à la latence : Les charges de travail sensibles à la latence, telles que dans les applications financières et de télécommunications, peuvent obtenir des avantages significatifs en termes de performances des optimisations de latence d'E/S et de gigue dans ESXi 7.0 Update 2. Les optimisations réduisent les interférences et les sources de gigue pour fournir un environnement d'exécution cohérent. Avec ESXi 7.0 Update 2 vous constaterez également des vitesses plus élevées de livraison des interruptions pour les périphériques de relais.
     
  • Espaces confidentiels vSphere sur un cluster superviseur dans vSphere with Tanzu : à partir de vSphere 7.0 Update 2, il est possible d'exécuter des espaces confidentiels vSphere grâce auxquels la mémoire du système d'exploitation invité demeure chiffrée et protégée contre les accès à partir de l'hyperviseur sur un cluster superviseur dans vSphere with Tanzu. Vous pouvez configurer des espaces confidentiels vSphere en ajoutant Secure Encrypted Virtualization-Encrypted State (SEV-ES) comme amélioration supplémentaire de la sécurité. Pour plus d'informations, reportez-vous à la section Déployer un espace confidentiel vSphere.
     
  • Mises à niveau rapides de vSphere Lifecycle Manager : à partir de vSphere 7.0 Update 2, vous pouvez réduire considérablement le temps de mise à niveau et d'arrêt du système, et réduire le temps de démarrage du système, en suspendant les machines virtuelles dans la mémoire et en utilisant la fonctionnalité Quick Boot. Vous pouvez configurer vSphere Lifecycle Manager pour qu'il suspende des machines virtuelles dans la mémoire au lieu de les faire migrer, de les mettre hors tension ou de les suspendre dans le disque lorsque vous mettez à jour un hôte ESXi. Pour plus d'informations, reportez-vous à la section Configuration de vSphere Lifecycle Manager pour les mises à niveau rapides.
     
  • Trafic du journal de tolérance de panne chiffré : à partir de vSphere 7.0 Update 2, vous pouvez chiffrer le trafic du journal de tolérance de panne chiffré pour améliorer la sécurité. vSphere Fault Tolerance effectue des vérifications fréquentes entre les machines virtuelles principales et secondaires pour permettre une reprise rapide à partir du dernier point de contrôle réussi. Le point de contrôle contient l'état de la machine virtuelle qui a été modifié depuis le point de contrôle précédent. Le chiffrement du trafic du journal empêche les accès malveillants et les attaques réseau.

Versions antérieures d'ESXi 7.0

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

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

Correctifs contenus dans cette version

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

Détails de la build

Nom de fichier de téléchargement : VMware-ESXi-7.0U2-17630552-depot
Build : 17630552
Taille du téléchargement : 390,9 Mo
md5sum : 4eae7823678cc7c57785e4539fe89d81
sha1checksum : 7c6b70a0190bd78bcf118f856cf9c60b4ad7d4b5
Redémarrage de l'hôte requis : Oui
Migration ou arrêt de la machine virtuelle requis : Oui

IMPORTANT :

  • Dans le plug-in Lifecycle Manager de vSphere Client, la date de publication de l'image de base, des profils et des composants d'ESXi 7.0.2 est le 17/02/2021. Cette situation est normale. Pour garantir que vous pouvez utiliser des filtres corrects par date de publication, seule la date de publication du bulletin de cumul est 2021-03-09.
     
  • À 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é
ESXi70U2-17630552 Amélioration Important

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.0.2-17630552-standard
ESXi-7.0.2-17630552-no-tools

Image ESXi

Nom et version Date de publication Catégorie Détail
ESXi_7.0.2-0.0.17630552 03/09/2021 Général Image correction de bogue

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

Téléchargement et installation de correctifs

Dans vSphere 7.x, le plug-in Update Manager, utilisé pour l'administration de vSphere Update Manager, est remplacé par le plug-in Lifecycle Manager. Les opérations d'administration pour vSphere Update Manager sont toujours disponibles sous le plug-in Lifecycle Manager, avec de nouvelles capacités pour vSphere Lifecycle Manager.
La manière habituelle d'appliquer des correctifs aux hôtes ESXi 7.x consiste à utiliser vSphere Lifecycle Manager. Pour plus d'informations, consultez À propos de vSphere Lifecycle Manager et Lignes de base et images de vSphere Lifecycle Manager.
Vous pouvez également mettre à jour des hôtes ESXi sans utiliser le plug-in Lifecycle Manager et utiliser un profil d'image à la place. Pour ce faire, vous devez télécharger manuellement le fichier ZIP du bundle hors ligne du correctif sur la page Téléchargement de VMware ou sur la page Correctifs de produits, puis utilisez la commande esxcli software profile update.
Pour plus d'informations, consultez Mise à niveau des hôtes à l'aide des commandes ESXCLI et le guide Mise à niveau de VMware ESXi.

Remarques relatives à la prise en charge du produit

  • Modification du nom du pilote réseau i40en de la boîte de réception : à partir de vSphere 7.0 Update 2, le nom du pilote réseau i40en de la boîte de réception pour ESXi a été remplacé par i40enu.
  • Suppression de SHA1 de Secure Shell (SSH) : dans vSphere 7.0 Update 2, l'algorithme de hachage de chiffrement SHA-1 est supprimé de la configuration SSHD par défaut.
  • Obsolescence des instances de REST API de vSphere 6.0 à 6.7 : VMware déconseille les instances de REST API de vSphere 6.0 à 6.7 fournies sous /rest, appelées anciennes instances de REST API. Avec vSphere 7.0 Update 2, les instances de REST API sont fournies sous /api et appelées nouvelles instances de REST API. Pour plus d'informations, reportez-vous à l'article de blog vSphere 7 Update 2 - REST API Modernization et à l'article de la base de connaissances vSphere 83022.
  • Désapprobation future de SHA-1 : l'algorithme de hachage de chiffrement SHA-1 sera déconseillé dans une future version de vSphere. SHA-1 et l'algorithme MD5 déjà déconseillé ont des faiblesses connues et ont fait l'objet d'attaques pratiques.
  • Formats standard des fichiers journaux et transmissions Syslog : dans une future version majeure d'ESXi, VMware prévoit de normaliser les formats de tous les fichiers journaux ESXi et transmissions Syslog. Cette normalisation affecte les métadonnées associées à chaque ligne de fichier journal ou de transmission Syslog. Par exemple, l'horodatage, l'identifiant de source programmatique, la gravité du message et les données d'identifiant de l'opération. Pour plus d'informations, visitez le site https://core.vmware.com/esxi-log-message-formats. 

Problèmes résolus

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

Mises à jour du microcode Intel
  • ESXi 7.0 Update 2 inclut les mises à jour du microcode Intel suivantes :
    Nom de code FMS ID de PLT Révision de MCU Date de MCU Noms de marque
    Nehalem EP 0x106a5 0x03 0x0000001d 11/05/2018 Intel Xeon 35xx Series ;
    Intel Xeon 55xx Series
    Lynnfield 0x106e5 0x13 0x0000000a 08/05/2018 Intel Xeon 34xx Lynnfield Series
    Clarkdale 0x20652 0x12 0x00000011 08/05/2018 Intel i3/i5 Clarkdale Series
    Intel Xeon 34xx Clarkdale Series
    Arrandale 0x20655 0x92 0x00000007 23/04/2018 Processeur Intel Core i7-620LE
    Sandy Bridge DT 0x206a7 0x12 0x0000002f 17/02/2019 Intel Xeon E3-1100 Series ;
    Intel Xeon E3-1200 Series ;
    Intel i7-2655-LE Series
    Intel i3-2100 Series
    Westmere EP 0x206c2 0x03 0x0000001f 08/05/2018 Intel Xeon série 56xx
    Intel Xeon 36xx Series
    Sandy Bridge EP 0x206d6 0x6d 0x00000621 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 0x6d 0x0000071a 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 0x04 0x0000000d 15/05/2018 Intel Xeon 65xx Series ;
    Intel Xeon 75xx Series
    Westmere EX 0x206f2 0x05 0x0000003b 16/05/2018 Intel Xeon E7-8800 Series ;
    Intel Xeon E7-4800 Series ;
    Intel Xeon E7-2800 Series
    Ivy Bridge DT 0x306a9 0x12 0x00000021 13/02/2019 Intel i3-3200 Series ;
    Intel i7-3500-LE/UE
    Intel i7-3600-QE
    Intel Xeon E3-1200-v2 Series;
    Intel Xeon E3-1100-C-v2 Series
    Intel Pentium B925C
    Haswell DT 0x306c3 0x32 0x00000028 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 0xed 0x0000042e 14/03/2019 Intel Xeon E5-4600-v2 Series ;
    Intel Xeon E5-2600-v2 Series ;
    Intel Xeon E5-2400-v2 Series ;
    Intel Xeon E5-1600-v2 Series ;
    Intel Xeon E5-1400-v2 Series
    Ivy Bridge EX 0x306e7 0xed 0x00000715 14/03/2019 Intel Xeon E7-8800/4800/2800-v2 Series
    Haswell EP 0x306f2 0x6f 0x00000044 27/05/2020 Intel Xeon E5-4600-v3 Series ;
    Intel Xeon E5-2600-v3 Series ;
    Intel Xeon E5-2400-v3 Series ;
    Intel Xeon E5-1600-v3 Series ;
    Intel Xeon E5-1400-v3 Series
    Haswell EX 0x306f4 0x80 0x00000016 17/06/2019 Intel Xeon E7-8800/4800-v3 Series
    Broadwell H 0x40671 0x22 0x00000022 12/11/2019 Intel Core i7-5700EQ
    Intel Xeon E3-1200-v4 Series
    Avoton 0x406d8 0x01 0x0000012d 16/09/2019 Intel Atom C2300 Series ;
    Intel Atom C2500 Series ;
    Intel Atom C2700 Series
    Broadwell EP/EX 0x406f1 0xef 0x0b000038 18/06/2019 Intel Xeon E7-8800/4800-v4 Series ;
    Intel Xeon E5-4600-v4 Series ;
    Intel Xeon E5-2600-v4 Series ;
    Intel Xeon E5-1600-v4 Series
    Skylake SP 0x50654 0xb7 0x02006a08 16/06/2020 Intel Xeon Platinum 8100 Series ;
    Intel Xeon Gold 6100/5100, Silver 4100, Bronze 3100 Series
    Intel Xeon D-2100 Series ;
    Intel Xeon D-1600 Series ;
    Intel Xeon W-3100 Series ;
    Intel Xeon W-2100 Series
    Cascade Lake B-0 0x50656 0xbf 0x04003003 18/06/2020 Intel Xeon Platinum 9200/8200 Series ;
    Intel Xeon Gold 6200/5200 ;
    Intel Xeon Silver 4200/Bronze 3200 ;
    Intel Xeon W-3200
    Cascade Lake 0x50657 0xbf 0x05003003 18/06/2020 Intel Xeon Platinum 9200/8200 Series ;
    Intel Xeon Gold 6200/5200 ;
    Intel Xeon Silver 4200/Bronze 3200 ;
    Intel Xeon W-3200
    Cooper Lake 0x5065b 0xbf 0x0700001f 17/09/2020 Intel Xeon Platinum 8300 Series ;
    Intel Xeon Gold 6300/5300
    Broadwell DE 0x50662 0x10 0x0000001c 17/06/2019 Intel Xeon D-1500 Series
    Broadwell DE 0x50663 0x10 0x07000019 17/06/2019 Intel Xeon D-1500 Series
    Broadwell DE 0x50664 0x10 0x0f000017 17/06/2019 Intel Xeon D-1500 Series
    Broadwell NS 0x50665 0x10 0x0e00000f 17/06/2019 Intel Xeon D-1600 Series
    Skylake H/S 0x506e3 0x36 0x000000e2 14/07/2020 Intel Xeon E3-1500-v5 Series ;
    Intel Xeon E3-1200-v5 Series
    Denverton 0x506f1 0x01 0x00000032 07/03/2020 Intel Atom C3000 Series
    Snow Ridge 0x80665 0x01 0x0b000007 25/02/2020 Intel Atom P5000 Series
    Kaby Lake H/S/X 0x906e9 0x2a 0x000000de 26/05/2020 Intel Xeon E3-1200-v6 Series ;
    Intel Xeon E3-1500-v6 Series
    Coffee Lake 0x906ea 0x22 0x000000de 25/05/2020 Intel Xeon E-2100 Series ;
    Intel Xeon E-2200 Series (4 ou 6 cœurs)
    Coffee Lake 0x906eb 0x02 0x000000de 25/05/2020 Intel Xeon E-2100 Series
    Coffee Lake 0x906ec 0x22 0x000000de 03/06/2020 Intel Xeon E-2100 Series
    Coffee Lake Refresh 0x906ed 0x22 0x000000de 24/05/2020 Intel Xeon E-2200 Series (8 cœurs)
Problèmes de stockage
  • Après une restauration suite à une condition APD ou PDL, la banque de données VMFS avec prise en charge activée de disques virtuels en cluster reste inaccessible

    Vous pouvez rencontrer ce problème uniquement sur les banques de données sur lesquelles la prise en charge des disques virtuels en cluster est activée. Lorsque la banque de données récupère suite à une condition Tous chemins hors service (All Path Down, APD) ou Perte permanente de périphérique (Permanent Device Loss, PDL), elle reste inaccessible. Le journal VMkernel peut afficher plusieurs messages de conflit de réservation SCSI3 similaires aux suivants :

    2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: Reservation conflict retries 544 for command 0x45ba814b8340 (op: 0x89) to device "naa.624a9370b97601e346f64ba900024d53"

    Ce problème peut se produire, car l'hôte ESXi participant au cluster perd les réservations SCSI pour la banque de données et ne peut pas toujours les acquérir de nouveau automatiquement après la restauration de la banque de données.

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

Problèmes liés à Auto Deploy
  • PR 2710383 : si vous déployez un hôte ESXi à l'aide de l'installation avec état de vSphere Auto Deploy, les configurations ESXi migrées vers la base de données ConfigStore sont perdues lors de la mise à niveau

    Si vous déployez un hôte ESXi à l'aide de la fonctionnalité d'installation avec état Auto Deploy, une option indiquant le démarrage de l'installation avec état dans le fichier boot.cfg n'est pas supprimée et entre en conflit avec l'état persistant de la base de données ConfigStore. Par conséquent, les configurations ESXi migrées vers la base de données ConfigStore sont perdues lors de la mise à niveau vers ESXi 7.x.

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

Problèmes de mise en réseau
  • PR 2696435 : vous ne pouvez pas utiliser le balisage d'invité virtuel (VGT) par défaut dans un environnement SR-IOV

    Avec le pilote i40enu dans ESXi 7.0 Update 2, il n'est plus possible d'utiliser le VGT par défaut pour éviter les fonctions virtuelles (VF) SR-IOV non approuvées pour transmettre ou recevoir des paquets marqués d'un ID de VLAN différent du VLAN du port. 
    Vous devez définir toutes les machines virtuelles en mode approuvé à l'aide du paramètre de module suivant :
    esxcli system module parameters set -a -m i40enu -p "trust_all_vfs=1,1,1,...

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

Problèmes divers
  • NOUVEAU : si le processus Xorg ne parvient pas à redémarrer alors qu'un hôte ESXi quitte le mode de maintenance, le service hostd peut cesser de répondre

    Si le processus Xorg ne parvient pas à redémarrer alors qu'un hôte ESXi quitte le mode de maintenance, le service hostd peut cesser de répondre, car il ne peut pas terminer l'opération de sortie.

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

Problèmes de mise à niveau
  • NOUVEAU : si un système vCenter Server est à la version 7.0, les mises à niveau des hôtes ESXi vers une version ultérieure à l'aide de vSphere Lifecycle Manager et d'une image ISO échouent

    Si vous utilisez une image ISO pour mettre à niveau les hôtes ESXi vers une version ultérieure à la version 7.0 à l'aide de vSphere Lifecycle Manager et que le système vCenter Server est toujours à la version 7.0, la mise à niveau échoue. Dans vSphere Client, l'erreur La mise à niveau n'est pas prise en charge pour l'hôte s'affiche.

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

Problèmes connus

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

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

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

    Solution : pour terminer la mise à niveau vers ESXi 7.0 Update 2, vous devez créer une image personnalisée remplaçant la version 1.8.1.136-1vmw.702.0.0.17630552 du composant i40en par la version Intel-i40en_1.10.9.0-1OEM.700.1.0.15525992 ou ultérieure du composant i40en. Pour plus d'informations, reportez-vous à la section Personnalisation des installations avec vSphere ESXi Image Builder.

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

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

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

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

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

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

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

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

    Solution : aucune.

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

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

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

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

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

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

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

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

Problèmes 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.

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

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

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

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

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

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

    Solution : aucune.

Problèmes de stockage
  • NOUVEAU : si vous utilisez un périphérique USB comme périphérique de démarrage, les hôtes ESXi peuvent cesser de répondre, et vous verrez apparaître des alertes indiquant que l'hôte ne répond pas et que la banque de démarrage est introuvable

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

    Solution : aucune.

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

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

    Solution : effectuez des opérations de connexion à chaud sur un emplacement uniquement une fois l'opération de connexion à chaud précédente sur l'emplacement terminée. Par exemple, si vous souhaitez exécuter une suppression à chaud après une opération d'ajout à chaud, attendez que les HBA soient créés et que les LUN soient découverts. Une autre solution consiste à effectuer un ajout à chaud après une opération de suppression à chaud et à attendre que tous les LUN et HBA soient supprimés.

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.

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

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

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

Problèmes d'installation, de mise à niveau et de migration
  • Le démarrage UEFI des hôtes ESXi peut s'arrêter avec une erreur lors d'une mise à jour vers ESXi 7.0 Update 2 à partir d'une version antérieure d'ESXi 7.0

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

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

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

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

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

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

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

    Solution : aucune.

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

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

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

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

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

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

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

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

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

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

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

Problèmes connus des versions antérieures

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

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