| 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
- Versions antérieures d'ESXi 7.0
- Correctifs contenus dans cette version
- Remarques relatives à la prise en charge du produit
- Problèmes résolus
- Problèmes connus
Nouveautés
- 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
- Dell Inc.
- 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.confet dans les fichiers/etc/vmsyslog.conf.d/*.confré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 :
- VMware ESXi 7.0, version de correctif ESXi 7.0 Update 1d
- VMware ESXi 7.0, version de correctif ESXi 7.0 Update 1c
- VMware ESXi 7.0, version de correctif ESXi 7.0 Update 1b
- VMware ESXi 7.0, version de correctif ESXi 7.0 Update 1a
- VMware ESXi 7.0, version de correctif ESXi 7.0 Update 1
- VMware ESXi 7.0, Patch Release ESXi 7.0b
Pour plus d'informations sur l'internationalisation, la compatibilité et les composants open source, consultez les Notes de mise à jour de VMware vSphere 7.0.
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
ESXietesx-updatesont 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/apiet 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
- Problèmes de stockage
- Problèmes liés à Auto Deploy
- Problèmes de mise en réseau
- Problèmes divers
- Problèmes de mise à niveau
- 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 SeriesLynnfield 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 SeriesArrandale 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 SeriesWestmere EP 0x206c2 0x03 0x0000001f 08/05/2018 Intel Xeon série 56xx
Intel Xeon 36xx SeriesSandy 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 SeriesSandy 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 SeriesNehalem EX 0x206e6 0x04 0x0000000d 15/05/2018 Intel Xeon 65xx Series ;
Intel Xeon 75xx SeriesWestmere EX 0x206f2 0x05 0x0000003b 16/05/2018 Intel Xeon E7-8800 Series ;
Intel Xeon E7-4800 Series ;
Intel Xeon E7-2800 SeriesIvy 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 B925CHaswell 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 SeriesIvy 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 SeriesIvy 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 SeriesHaswell 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 SeriesAvoton 0x406d8 0x01 0x0000012d 16/09/2019 Intel Atom C2300 Series ;
Intel Atom C2500 Series ;
Intel Atom C2700 SeriesBroadwell 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 SeriesSkylake 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 SeriesCascade 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-3200Cascade 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-3200Cooper Lake 0x5065b 0xbf 0x0700001f 17/09/2020 Intel Xeon Platinum 8300 Series ;
Intel Xeon Gold 6300/5300Broadwell 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 SeriesDenverton 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 SeriesCoffee 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)
- 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 SCSI3similaires 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.
- 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.cfgn'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.
- 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.
- 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.
- 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ôtes'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
- Problèmes de sécurité
- Problèmes divers
- Problèmes de stockage
- Problèmes de gestion des machines virtuelles
- Problèmes de vSAN
- Problèmes d'installation, de mise à niveau et de migration
- Problèmes connus des versions antérieures
- 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
i40ende la boîte de réception a été remplacé pari40enu. Par conséquent, si vous tentez d'installer un pilote asynchrone de partenairei40en, le VIBi40enest ignoré ou restauré vers le pilote de la boîte de réception VMwarei40enu.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.17630552du composanti40enpar la versionIntel-i40en_1.10.9.0-1OEM.700.1.0.15525992ou ultérieure du composanti40en. 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 nicspour récupérer les données ConfigStore afin de vérifier si/esx/network/nics/net_queue/load_balancer/enablefonctionne 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
- 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 commandechkconfig 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 commandlineDans 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.
- 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 0x1cSolution : aucune.
- 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 »etL'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:4Solution : 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.
- É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.
- 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
ClomMaxCrawlCycleMinutespour 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'optionClomMaxCrawlCycleMinutes.
- 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
loadESXCheckCompatindique 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 systemSolution : 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 updateouesxcli software profile installpeuvent é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 updateouesxcli software vib install.Solution : vous pouvez effectuer la mise à niveau en deux étapes, à l'aide de la commande
esxcli software profile updatepour 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.
