Notes de mise à jour de VMware ESXi 6.7 Update 1

ESXi 6.7 Update 1 | 16 octobre 2018 | Build ISO 10302608 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 6.7
• Notes d'installation de cette version
• Correctifs contenus dans cette version
• Problèmes résolus
• Problèmes connus

Nouveautés

• ESXi 6.7 Update 1 comprend un plug-in LSU Microsemi Smart PQI (smartpqi) afin de prendre en charge les opérations de gestion des disques attachés sur le contrôleur HPE ProLiant Gen10 Smart Array.
• ESXi 6.7 Update 1 prend en charge Quick Boot pour les pilotes Intel i40en et ixgben Enhanced Network Stack (ENS), et permet d'étendre la prise en charge des serveurs HPE ProLiant et Synergie. Pour plus d'informations, reportez-vous à l'article 52477 de la base de connaissances VMware.
• ESXi 6.7 Update 1 permet un contrôle préalable lors de la mise à niveau des hôtes ESXi en utilisant les commandes de profil logiciel de l'ensemble de commandes ESXCLI afin de garantir la compatibilité de la mise à niveau.
• ESXi 6.7 Update 1 prend en charge le pilote nfnic pour Cisco UCS Fibre Channel over Ethernet (FCoE).
• ESXi 6.7 Update 1 prend en charge Namespace Globally Unique Identifier (NGUID) dans le pilote NVMe. 
• ESXi 6.7 Update 1 vous permet d'exécuter les commandes ESXCLI de stockage suivantes pour activer le voyant d'état sur des disques SSD basés sur VMD Intel sans télécharger Intel CLI :
  • esxcli storage core device set -l locator -d
  • esxcli storage core device set -l error -d
  • esxcli storage core device set -l off -d 
• ESXi 6.7 Update 1 comprend des API afin d'éviter que l'hôte ESXi redémarre lors de la configuration de ProductLocker et pour activer la gestion de la configuration de VMware Tools par le rôle CloudAdmin dans le SDDC cloud sans avoir besoin d'accéder aux profils d'hôte.
• ESXi 6.7 Update 1 comprend l'option de configuration avancée EnablePSPLatencyPolicy pour réclamer des périphériques avec une règle de sélection de chemin d'accès Round Robin basée sur la latence. L'option de configuration EnablePSPLatencyPolicy n'affecte pas le périphérique existant ni les règles de réclamation spécifiques du fournisseur. Vous pouvez également activer la journalisation pour afficher la configuration de chemins d'accès lorsque vous utilisez l'option EnablePSPLatencyPolicy.
• Avec ESXi 6.7 Update 1, vous pouvez utiliser vSphere vMotion pour migrer des machines virtuelles configurées avec des types de GPU virtuels NVIDIA vers d'autres hôtes avec des GPU NVIDIA Tesla compatibles. Pour plus d'informations sur les versions de NVIDIA prises en charge, consultez le Guide de compatibilité VMware.
• Avec ESXi 6.7 Update 1, Update Manager Download Service (UMDS) ne nécessite pas de base de données et la procédure d'installation est simplifiée. Pour plus d'informations, consultez le Guide d'installation et d'administration de vSphere Update Manager.

Pour plus d'informations sur les problèmes liés à VMware vSAN, consultez les Notes de mise à jour de VMware vSAN 6.7 Update 1.

Versions antérieures d'ESXi 6.7

Les fonctions et problèmes connus d'ESXi sont décrits dans les notes de mise à jour de chaque version. Notes de mise à jour des versions antérieures à ESXi 6.7 :

• Notes de mise à jour de VMware vSphere 6.7

Pour les remarques relatives à l'internationalisation, la compatibilité, l'installation et les mises à niveau, ainsi que les composants open source et l'assistance produit, consultez les Notes de mise à jour de VMware vSphere 6.7.

Notes d'installation de cette version

Modifications de l'intégration de VMware Tools dans ESXi 6.7 Update 1

Dans ESXi 6.7 Update 1, un sous-ensemble d'images ISO de VMware Tools 10.3.2 est intégré à l'hôte ESXi 6.7 Update 1.

Les images ISO de VMware Tools 10.3.2 suivantes sont intégrées à ESXi :

• windows.iso : Image de VMware Tools pour Windows Vista ou version ultérieure
• linux.iso : Image de VMware Tools pour le système d'exploitation Linux avec glibc version 2.5 ou version ultérieure

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

• solaris.iso : Image de VMware Tools pour Solaris
• freebsd.iso : image de VMware Tools pour FreeBSD
• darwin.iso : Image de VMware Tools pour OSX

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

• Notes de mise à jour de VMware Tools 10.3.2
• Mise à jour vers VMware Tools 10 - À lire
• VMware Tools pour les hôtes provisionnés avec Auto Deploy
• Mise à jour de VMware Tools

Correctifs contenus dans cette version

Cette version contient tous les bulletins d'ESXi qui ont été publiés avant la date de publication de ce produit.

Détails de la build

Nom de fichier de téléchargement :	update-from-esxi6.7-6.7_update01.zip
Build :	10302608 10176879 (sécurité uniquement)
Taille du téléchargement :	450,5 Mo
md5sum:	0ae2ab210d1ece9b3e22b5db2fa3a08e
sha1checksum:	b11a856121d2498453cef7447294b461f62745a3
Redémarrage de l'hôte requis :	Oui
Migration ou arrêt de la machine virtuelle requis :	Oui

Bulletins

Cette version contient des bulletins généraux et de sécurité uniquement. Les bulletins de sécurité s'appliquent aux nouveaux correctifs de sécurité uniquement. Les nouveaux correctifs de bogues ne sont pas inclus, mais les correctifs de bogues des versions antérieures des correctifs et des mises à jour sont inclus.
Si l'installation de tous les nouveaux correctifs de sécurité et de bogues est requise, vous devez appliquer tous les bulletins présents dans cette version. Dans certains cas, le bulletin général remplacera le bulletin de sécurité uniquement. Cela n'est pas un problème, car le bulletin général contient les nouveaux correctifs de sécurité et de bogues.
Les bulletins de sécurité sont identifiables par leur ID de bulletin qui se termine par « SG ». Pour obtenir des informations sur la classification des correctifs et des mises à jour, consultez l'article KB 2014447.
Pour plus d'informations sur les bulletins individuels, consultez la page My VMware et la section Problèmes résolus.

ID de bulletin	Catégorie	Gravité
ESXi670-201810201-UG	Correctif de bogues	Critique
ESXi670-201810202-UG	Correctif de bogues	Important
ESXi670-201810203-UG	Correctif de bogues	Important
ESXi670-201810204-UG	Correctif de bogues	Critique
ESXi670-201810205-UG	Correctif de bogues	Modéré
ESXi670-201810206-UG	Correctif de bogues	Critique
ESXi670-201810207-UG	Amélioration	Important
ESXi670-201810208-UG	Amélioration	Important
ESXi670-201810209-UG	Correctif de bogues	Important
ESXi670-201810210-UG	Correctif de bogues	Important
ESXi670-201810211-UG	Amélioration	Important
ESXi670-201810212-UG	Correctif de bogues	Important
ESXi670-201810213-UG	Correctif de bogues	Critique
ESXi670-201810214-UG	Correctif de bogues	Critique
ESXi670-201810215-UG	Correctif de bogues	Important
ESXi670-201810216-UG	Correctif de bogues	Important
ESXi670-201810217-UG	Correctif de bogues	Important
ESXi670-201810218-UG	Correctif de bogues	Important
ESXi670-201810219-UG	Correctif de bogues	Modéré
ESXi670-201810220-UG	Correctif de bogues	Important
ESXi670-201810221-UG	Correctif de bogues	Important
ESXi670-201810222-UG	Correctif de bogues	Important
ESXi670-201810223-UG	Correctif de bogues	Important
ESXi670-201810224-UG	Correctif de bogues	Important
ESXi670-201810225-UG	Correctif de bogues	Important
ESXi670-201810226-UG	Correctif de bogues	Important
ESXi670-201810227-UG	Correctif de bogues	Important
ESXi670-201810228-UG	Correctif de bogues	Important
ESXi670-201810229-UG	Correctif de bogues	Important
ESXi670-201810230-UG	Correctif de bogues	Important
ESXi670-201810231-UG	Correctif de bogues	Important
ESXi670-201810232-UG	Correctif de bogues	Important
ESXi670-201810233-UG	Correctif de bogues	Important
ESXi670-201810234-UG	Correctif de bogues	Important
ESXi670-201810101-SG	Sécurité	Important
ESXi670-201810102-SG	Sécurité	Modéré
ESXi670-201810103-SG	Sécurité	Important

IMPORTANT : Pour les clusters qui utilisent VMware vSAN, vous devez tout d'abord mettre à niveau le système vCenter Server. La mise à niveau d'ESXi uniquement n'est pas prise en charge.
Avant d’effectuer une mise à niveau, vérifiez toujours dans la Matrice d'interopérabilité des produits VMware les chemins de mise à niveau compatibles des versions antérieures d'ESXi et de vCenter Server vers la version actuelle. 

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-6.7.0-20181002001-standard

ESXi-6.7.0-20181002001-no-tools

ESXi-6.7.0-20181001001s-standard

ESXi-6.7.0-20181001001s-no-tools

Problèmes résolus

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

• ESXi670-201810201-UG
• ESXi670-201810202-UG
• ESXi670-201810203-UG
• ESXi670-201810204-UG
• ESXi670-201810205-UG
• ESXi670-201810206-UG
• ESXi670-201810207-UG
• ESXi670-201810208-UG
• ESXi670-201810209-UG
• ESXi670-201810210-UG
• ESXi670-201810211-UG
• ESXi670-201810212-UG
• ESXi670-201810213-UG
• ESXi670-201810214-UG
• ESXi670-201810215-UG
• ESXi670-201810216-UG
• ESXi670-201810217-UG
• ESXi670-201810218-UG
• ESXi670-201810219-UG
• ESXi670-201810220-UG
• ESXi670-201810221-UG
• ESXi670-201810222-UG
• ESXi670-201810223-UG
• ESXi670-201810224-UG
• ESXi670-201810225-UG
• ESXi670-201810226-UG
• ESXi670-201810227-UG
• ESXi670-201810228-UG
• ESXi670-201810229-UG
• ESXi670-201810230-UG
• ESXi670-201810231-UG
• ESXi670-201810232-UG
• ESXi670-201810233-UG
• ESXi670-201810234-UG
• ESXi670-201810101-SG
• ESXi670-201810102-SG
• ESXi670-201810103-SG
• ESXi-6.7.0-20181002001-standard
• ESXi-6.7.0-20181002001-no-tools
• ESXi-6.7.0-20181001001s-standard
• ESXi-6.7.0-20181001001s-no-tools

ESXi670-201810201-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Critique
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMware_bootbank_esx-base_6.7.0-1.28.10302608 VMware_bootbank_vsan_6.7.0-1.28.10290435 VMware_bootbank_vsanhealth_6.7.0-1.28.10290721 VMware_bootbank_esx-update_6.7.0-1.28.10302608
PR résolus	1220910, 2036262, 2036302, 2039186, 2046226, 2057603, 2058908, 2066026, 2071482, 2072977, 2078138, 2078782, 2078844, 2079807, 2080427, 2082405, 2083581, 2084722, 2085117, 2086803, 2086807, 2089047, 2096126, 2096312, 2096947, 2096948, 2097791, 2098170, 2098868, 2103579, 2103981, 2106747, 2107087, 2107333, 2110971, 2118588, 2119610, 2119663, 2120346, 2126919, 2128933, 2129130, 2129181, 2131393, 2131407, 2133153, 2133588, 2136004, 2137261, 2139127, 2145089, 2146206, 2146535, 2149518, 2152380, 2154913, 2156841, 2157501, 2157817, 2163734, 2165281, 2165537, 2165567, 2166114, 2167098, 2167878, 2173810, 2186253, 2187008
Numéros CVE	S.O.

Ce correctif met à jour les VIB esx-base, esx-update, vsan et vsanhealth pour résoudre les problèmes suivants :

• PR 2084722 : Si vous supprimez le dossier de bundle de support d'une machine virtuelle d'un hôte ESXi, le service hostd peut échouer

  Si vous supprimez manuellement le dossier de bundle de support d'une machine virtuelle téléchargé dans le répertoire /scratch/downloads d'un hôte ESXi, le service hostd peut échouer. Cet échec se produit lorsque hostd tente automatiquement de supprimer les dossiers dans le répertoire /scratch/downloads une heure après la création des fichiers.

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

• PR 2083581 : Vous ne pourrez peut-être pas utiliser un lecteur de carte à puce comme périphérique de relais à l'aide de la fonctionnalité Support vMotion lorsqu'un périphérique est connecté

  Si vous modifiez le fichier de configuration d'un hôte ESXi pour activer un lecteur de carte à puce comme périphérique de relais, vous ne pourrez peut-être pas utiliser le lecteur si vous avez également activé la fonctionnalité Support vMotion alors qu'un périphérique est connecté.

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

• PR 2058908 : Les journaux de VMkernel dans un environnement VMware vSAN peuvent être saturés par le message Unable to register file system

  Dans les environnements vSAN, les journaux de VMkernel qui enregistrent les activités relatives aux machines virtuelles et à ESXi peuvent être saturés par le message Unable to register file system.

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

• PR 2106747 : vSphere Web Client peut afficher une allocation de stockage incorrecte après une augmentation de la taille de disque d'une machine virtuelle

  Si vous utilisez vSphere Web Client pour augmenter la taille de disque d'une machine virtuelle, vSphere Web Client peut ne pas refléter entièrement la nouvelle configuration et afficher la même allocation de stockage pour la machine virtuelle.

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

• PR 2089047 : L'utilisation de l'option d'extension de variable Windows dans les Services de déploiement Windows (WDS) sur les machines virtuelles avec le microprogramme EFI peut ralentir le démarrage avec PXE

  Si vous tentez de démarrer avec PXE une machine virtuelle qui utilise un microprogramme EFI, avec un adaptateur réseau vmxnet3 et WDS, et que vous n'avez pas désactivé l'option d'extension de variable Windows dans WDS, la machine virtuelle peut démarrer très lentement.

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

• PR 2103579 : Les périphériques Apple avec une version d'iOS ultérieure à iOS 11 ne peuvent pas se connecter aux machines virtuelles avec une version d'OS X ultérieure à OS X 10.12

  En raison de problèmes avec les dispositifs USB d'Apple, les périphériques avec une version d'iOS ultérieure à iOS 11 ne peuvent pas se connecter aux machines virtuelles avec une version d'OS X ultérieure à OS X 10.12.

  Ce problème est résolu dans cette version. Pour activer la connexion dans les versions antérieures d'ESXi, ajoutez usb.quirks.darwinVendor45 = TRUE comme nouvelle option au fichier de configuration .vmx. 

• PR 2096126 : L'application d'un profil d'hôte avec Stateful Install activé sur un hôte ESXi 6.7 à l'aide de vSphere Auto Deploy peut échouer

  Si vous activez la fonctionnalité Stateful Install sur un profil d'hôte et que la carte réseau VMkernel est connectée à un commutateur virtuel distribué, l'application du profil d'hôte sur un autre hôte ESXi 6.7 à l'aide de vSphere Auto Deploy peut échouer pendant un démarrage à l'aide de PXE. L'hôte reste en mode de maintenance. 

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

• PR 2072977 : La consolidation du disque de machine virtuelle peut échouer si la machine virtuelle a des snapshots pris avec Content Based Read Cache (CBRC) activé, puis que la fonctionnalité est désactivée

  Si une machine virtuelle a des snapshots pris à l'aide de CBRC, puis que CBRC est désactivé, les opérations de consolidation de disque peuvent échouer avec une erreur Un paramètre spécifié n'est pas correct : spec.deviceChange.device en raison d'un fichier de synthèse supprimé une fois CBRC désactivé. Une alerte La consolidation des disques de machine virtuelle est nécessaire. s'affiche jusqu'à ce que le problème soit résolu. Ce correctif empêche le problème, mais il continue d'exister pour les machines virtuelles qui ont des snapshots pris avec la fonctionnalité CBRC activée, puis désactivée ultérieurement.

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

• PR 2107087 : Un hôte ESXi peut échouer avec un écran de diagnostic violet

  Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'un problème d'allocation de mémoire. 

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

• PR 2066026 : L'utilitaire esxtop peut signaler des statistiques incorrectes pour DAVG/cmd et KAVG/cmd sur les LUN pris en charge par VAAI

  En raison d'une erreur de calcul dans le noyau VMkernel, l'utilitaire esxtop signale des statistiques incorrectes pour la latence moyenne de périphérique par commande (DAVG/cmd) et la latence moyenne d'ESXi VMkernel par commande (KAVG/cmd) sur les LUN avec VMware vSphere Storage APIs - Array Integration (VAAI).

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

• PR 2036262 : Des règles de réclamation doivent être ajoutées manuellement à ESXi pour les modèles de baie de stockage DELL MD suivants : MD32xx, MD32xxi, MD36xxi, MD36xxf, MD34xx, MD38xxf et MD38xxi

  Ce correctif définit Storage Array Type Plug-in (SATP) sur VMW_SATP_ALUA, la règle de sélection de chemin d'accès (PSP, Path Selection Policy) sur VMW_PSP_RR et les options de réclamation sur tpgs_on comme valeurs par défaut pour les modèles de baies de stockage DELL MD suivants : MD32xx, MD32xxi, MD36xxi, MD36xxf, MD34xx, MD38xxf et MD38xxi. 

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

• PR 2082405 : Une machine virtuelle ne peut pas se connecter à un groupe de ports distribué après une migration à froid ou un basculement VMware vSphere High Availability

  Après une migration à froid ou un basculement vSphere High Availability, une machine virtuelle peut ne pas se connecter à un groupe de ports distribués, car le port a été supprimé avant de mettre la machine virtuelle sous tension.

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

• PR 2078782 : Les commandes d'E/S peuvent échouer avec l'erreur CHAMP NON VALIDE DANS CDB

  Les hôtes ESXi peuvent ne pas refléter le paramètre LONGUEUR DE TRANSFERT MAXIMALE signalé par le périphérique SCSI dans la page VPD des limites de bloc. Par conséquent, les commandes d'E/S émises avec une taille de transfert supérieure à la limite peuvent échouer avec une entrée de journal semblable à celles-ci :

  2017-01-24T12:09:40.065Z cpu6:1002438588)ScsiDeviceIO: SCSICompleteDeviceCommand:3033: Cmd(0x45a6816299c0) 0x2a, CmdSN 0x19d13f from world 1001390153 to dev "naa.514f0c5d38200035" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.

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

• PR 2107333 : des règles de réclamation doivent être ajoutées manuellement à ESXi pour les baies de stockage HITACHI OPEN-V

  Ce correctif définit Storage Array Type Plug-in (SATP) sur VMW_SATP_ALUA, la règle de sélection de chemin d'accès (PSP, Path Selection Policy) sur VMW_PSP_RR et les options de réclamation sur tpgs_on comme valeurs par défaut pour les baies de stockage de type HITACHI OPEN-v avec prise en charge du protocole ALUA (Asymmetric Logical Unit Access).

  Ce correctif définit également Storage Array Type Plug-in (SATP) sur VMW_SATP_DEFAULT_AA, la règle de sélection de chemin d'accès (PSP) sur VMW_PSP_RR et les options de réclamation sur tpgs_off comme valeurs par défaut pour les baies de stockage de type HITACHI OPEN-v sans prise en charge du protocole ALUA.

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

• PR 2078138 : le processus de sauvegarde d'une machine virtuelle avec un système d'exploitation invité Windows Server peut échouer, car le disque de snapshot mis au repos ne peut pas être ajouté à chaud sur une machine virtuelle de proxy qui est activée pour CBRC

  Si la machine virtuelle cible et la machine virtuelle du proxy sont activées pour CBRC, le disque de snapshot mis au repos ne peut pas être ajouté à chaud sur la machine virtuelle du proxy, car le résumé du disque de snapshot dans la machine virtuelle cible est désactivé pendant la création du snapshot. Par conséquent, le processus de sauvegarde de la machine virtuelle échoue.

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

• PR 2098868 : Les appels à l'objet géré HostImageConfigManager peuvent entraîner l'augmentation de l'activité du journal dans le fichier syslog.log

  Le fichier syslog.log peut être rempli à plusieurs reprises par des messages relatifs aux appels à l'objet géré HostImageConfigManager.

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

• PR 2096312 : pendant l'extension de la partition du vidage mémoire d'un hôte ESXi, des rapports vCenter Server peuvent avertir qu'aucune cible de vidage mémoire n'est configurée

  Pendant l'extension de la partition du vidage mémoire d'un hôte ESXi, des rapports vCenter Server peuvent avertir qu'aucune cible de vidage mémoire n'est configurée, car avant d'augmenter la taille de la partition, la partition du vidage mémoire existante est temporairement désactivée.

  Ce problème est résolu dans cette version. Pour vCenter Server 6.7.0, corrigez ce problème en exécutant la ligne de code suivante :
  # /bin/esxcfg-dumppart -C -D active --stdout 2> /dev/null

• PR 2057603 : Un hôte ESXi peut échouer avec un écran de diagnostic violet lors de l'arrêt ou de la mise hors tension des machines virtuelles si vous utilisez EMC RecoverPoint

  En raison d'une condition de concurrence dans VSCSI, si vous utilisez EMC RecoverPoint, un hôte ESXi peut échouer avec un écran de diagnostic violet pendant l'arrêt ou la mise hors tension d'une machine virtuelle.

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

• PR 2039186 : Les métadonnées de VMware vSphere Virtual Volumes peuvent ne pas être mises à jour avec les machines virtuelles associées et rendre impossible l'identification des conteneurs de disque virtuel

  Les vSphere Virtual Volumes avec la clé de métadonnées VMW_VVolType définie sur Autre et la clé de métadonnées VMW_VVolTypeHint définie sur Sidecar peuvent ne pas pouvoir utiliser la clé de métadonnées VMW_VmID sur les machines virtuelles associées et ne peuvent pas être suivies au moyen des ID.

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

• PR 2036302 : Les baies SolidFire peuvent ne pas enregistrer des performances optimales sans une nouvelle configuration des règles de réclamation SATP

  Ce correctif définit les règles de réclamation Storage Array Type Plugin (SATP) pour les baies de stockage Solidfire SSD SAN sur VMW_SATP_DEFAULT_AA et la règle de sélection de chemin d'accès (PSP, Path Selection Policy) sur VMW_PSP_RR avec 10 opérations d'E/S par seconde par défaut pour obtenir des performances optimales.

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

• PR 2112769 : Après le redémarrage rapide d'un système avec un contrôleur LSI ou le rechargement d'un pilote LSI, des banques de données peuvent devenir inaccessibles ou cesser de répondre

  Un redémarrage rapide d'un système avec un contrôleur LSI ou un rechargement d'un pilote LSI, tel que lsi_mr3, peut placer les disques derrière le contrôleur LSI dans un état hors ligne. Le microprogramme du contrôleur LSI envoie une commande SCSI STOP UNIT au cours du déchargement, mais une commande SCSI START UNIT correspondante peut ne pas être émise durant le rechargement. Si les disques sont mis hors ligne, toutes les banques de données hébergées sur ces disques cessent de répondre ou deviennent inaccessibles.

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

• PR 2119610 : La migration d'une machine virtuelle avec un commutateur de périphérique de système de fichiers (FDS) sur une banque de données vSphere Virtual Volumes à l'aide de VMware vSphere vMotion peut entraîner plusieurs problèmes

  Si vous utilisez vSphere vMotion pour migrer une machine virtuelle avec des filtres de périphérique de fichier à partir d'une banque de données vSphere Virtual Volumes vers un autre hôte, et que Changed Block Tracking (CBT), VMware vSphere Flash Read Cache (VFRC) ou les filtres d'E/S sont activés sur la machine virtuelle, la migration peut entraîner des problèmes avec l'une des fonctionnalités. Pendant la migration, les filtres de périphérique de fichier peuvent ne pas être correctement transférés sur l'hôte. Par conséquent, vous pouvez observer des sauvegardes incrémentielles corrompues dans CBT, une dégradation des performances de VFRC et des filtres d'E/S de cache, une réplication corrompue des filtres d'E/S et un disque endommagé, lorsque les filtres d'E/S de cache sont configurés en mode d'écriture. Des problèmes peuvent également se produire avec le chiffrement de machine virtuelle.

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

• PR 2128933 : Les E/S envoyées vers un snapshot VMFSsparse peuvent échouer sans erreur

  Si une machine virtuelle se trouve sur un snapshot VMFSsparse, les E/S émises vers la machine virtuelle peuvent être traitées uniquement partiellement au niveau de VMFSsparse, mais les couches supérieures, telles que les filtres d'E/S, peuvent supposer que le transfert a réussi. Cela peut entraîner l'incohérence des données. Ce correctif définit un état d'erreur transitoire pour référence à partir de couches supérieures si une E/S est effectuée.

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

• PR 2046226 : Des commandes SCSI INQUIRY sur des LUN Raw Device Mapping (RDM) peuvent renvoyer des données à partir du cache au lieu d'interroger le LUN

  Des données SCSI INQUIRY sont mises en cache au niveau de la couche Architecture de stockage enfichable (PSA, Pluggable Storage Architecture) pour les LUN RDM et la réponse pour les commandes SCSI INQUIRY suivantes peut être renvoyée à partir du cache au lieu d'interroger le LUN. Pour éviter l'extraction des données SCSI INQUIRY mises en cache, outre la modification du fichier .vmx d'une machine virtuelle avec RDM, ESXi 6.7 Update 1 vous permet d'ignorer SCSI INQUIRY également à l'aide de la commande ESXCLI

  esxcli storage core device inquirycache set --device <id périphérique> --ignore true.

  Avec l'option ESXCLI, un redémarrage de la machine virtuelle n'est pas nécessaire.

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

• PR 2133588 : Des règles de réclamation doivent être ajoutées manuellement à l'instance d'ESXi pour les baies de stockage Tegile IntelliFlash

  Ce correctif définit Storage Array Type Plugin (SATP) sur VMW_SATP_ALUA, la règle de sélection de chemin d'accès (PSP) sur VMW_PSP_RR et les options de réclamation sur tpgs_on en tant que valeurs par défaut pour les baies de stockage Tegile IntelliFlash avec prise en charge du protocole ALUA (Asymmetric Logical Unit Access). Le correctif définit également Storage Array Type Plugin (SATP) sur VMW_SATP_DEFAULT_AA, la règle de sélection de chemin d'accès (PSP) sur VMW_PSP_RR et les options de réclamation sur tpgs_off comme valeurs par défaut pour les baies de stockage Tegile IntelliFlash sans prise en charge du protocole ALUA.

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

• PR 2129181 : Si l'état des chemins d'accès à un LUN est modifié au cours du démarrage d'un hôte ESXi, le démarrage peut prendre plus de temps

  Pendant un démarrage d'ESXi, si les commandes émises via la détection de périphériques initiale échouent avec ASYMMETRIC ACCESS STATE CHANGE UA, le basculement de chemin d'accès peut prendre plus de temps, car les commandes sont bloquées dans l'hôte ESXi. Cela peut ralentir le démarrage d'ESXi.
  Des entrées de journal semblables à celles-ci peuvent s'afficher :
  2018-05-14T01:26:28.464Z cpu1:2097770)NMP: nmp_ThrottleLogForDevice:3689: Cmd 0x1a (0x459a40bfbec0, 0) to dev "eui.0011223344550003" on path "vmhba64:C0:T0:L3" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x6 0x2a 0x6. Act:FAILOVER 2018-05-14T01:27:08.453Z cpu5:2097412)ScsiDeviceIO: 3029: Cmd(0x459a40bfbec0) 0x1a, CmdSN 0x29 from world 0 to dev "eui.0011223344550003" failed H:0x5 D:0x0 P:0x0 Invalid sense data: 0x0 0x0 0x0. 2018-05-14T01:27:48.911Z cpu4:2097181)ScsiDeviceIO: 3029: Cmd(0x459a40bfd540) 0x25, CmdSN 0x2c from world 0 to dev "eui.0011223344550003" failed H:0x5 D:0x0 P:0x0 Invalid sense data: 0x0 0x0 0x0. 2018-05-14T01:28:28.457Z cpu1:2097178)ScsiDeviceIO: 3029: Cmd(0x459a40bfbec0) 0x9e, CmdSN 0x2d from world 0 to dev "eui.0011223344550003" failed H:0x5 D:0x0 P:0x0 Invalid sense data: 0x0 0x0 0x0. 2018-05-14T01:28:28.910Z cpu2:2097368)WARNING: ScsiDevice: 7641: GetDeviceAttributes during periodic probe'eui.0011223344550003': failed with I/O error

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

• PR 2119663 : Une banque de données VMFS6 peut signaler un message d'espace insuffisant incorrect

  Une banque de données VMFS6 peut signaler par erreur un manque d'espace, en raison d'entrées de cache obsolètes. Les rapports d'allocation d'espace sont corrigés avec les mises à jour automatiques des entrées du cache, mais ce correctif empêche l'erreur même avant une mise à jour.

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

• PR 2129130 : Des serveurs NTP supprimés à l'aide de vSphere Web Client peuvent rester dans le fichier de configuration NTP

  Si vous supprimez un serveur NTP de votre configuration à l'aide de vSphere Web Client, les paramètres du serveur peuvent rester dans le fichier /etc/ntp.conf.

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

• PR 2078844 : Des machines virtuelles peuvent cesser de répondre pendant la migration si vous sélectionnez les microprocesseurs Intel Merom ou Penryn dans le menu déroulant Mode EVC de VMware

  Si vous sélectionnez les microprocesseurs Intel Merom ou Penryn dans le menu déroulant Mode EVC de VMware avant la migration de machines virtuelles d'un hôte ESXi 6.0 vers un hôte ESXi 6.5 ou un hôte ESXi 6.7, les machines virtuelles peuvent cesser de répondre.

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

• PR 2080427 : Les événements VOB (VMkernel Observations) peuvent générer des avertissements relatifs aux performances des périphériques inutiles

  Les deux événements VOB suivants peuvent être générés en raison des variations de la latence d'E/S dans une baie de stockage, mais ils ne signalent pas un réel problème dans des machines virtuelles :

  • 1. Les performances du périphérique naa.xxx se sont détériorées. La latence d'E/S est passée d'une valeur moyenne de 4 114 microsecondes à 84 518 microsecondes.
  • 2. Les performances du périphérique naa.xxx se sont améliorées. La latence d'E/S est passée de 346 115 microsecondes à 67 046 microsecondes.

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

• PR 2137261 : L'exportation d'une machine virtuelle volumineuse à l'aide de VMware Host Client peut échouer

  L'exportation d'une machine virtuelle volumineuse à l'aide de VMware Host Client peut échouer ou se terminer avec des fichiers VMDK incomplets, car le bail émis par la méthode ExportVm peut expirer avant la fin du transfert de fichier.

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

• PR 2149518 : Le processus hostd peut échouer par intermittence en raison d'un nombre élevé de tâches de mise en réseau

  Un nombre élevé de tâches de mise en réseau, en particulier plusieurs appels à QueryNetworkHint(), peut dépasser la limite de mémoire du processus hostd et le faire échouer par intermittence.

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

• PR 2146535 : Les journaux de codes d'événements du microprogramme peuvent saturer le fichier vmkernel.log

  Les lecteurs qui ne prennent pas en charge la page VPD des limites de bloc 0xb0 peuvent générer des journaux de code d'événement qui saturent le fichier vmkernel.log.

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

• PR 2071482 : L'intégration de Dell OpenManage pour VMware vCenter (OMIVV) peut échouer à identifier certains serveurs modulaires Dell depuis le contrôleur d'accès à distance Dell intégré (iDRAC)

  OMIVV s'appuie sur des informations de la propriété iDRAC hardware.systemInfo.otherIdentifyingInfo.ServiceTag pour extraire le paramètre SerialNumber permettant d'identifier certains serveurs modulaires Dell. Une incompatibilité dans la propriété serviceTag peut empêcher cette intégration.

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

• PR 2145089 : vSphere Virtual Volumes peut cesser de répondre si une API pour le fournisseur VASA (Storage Awareness) perd les informations de liaison provenant de la base de données

  vSphere Virtual Volumes peut cesser de répondre en raison d'une boucle infinie qui charge les CPU à 100 %, si un fournisseur VASA perd les informations de liaison provenant de la base de données. Hostd peut également cesser de répondre. Un message d'erreur irrécupérable peut s'afficher.

  Ce problème est résolu dans cette version. Ce correctif empêche les boucles infinies en cas d'échecs de liaison de base de données.

• PR 2146206 : Les métadonnées de vSphere Virtual Volumes peuvent ne pas être disponibles pour le logiciel du fournisseur de baie de stockage

  Les métadonnées de vSphere Virtual Volumes peuvent être disponibles uniquement lorsqu'une machine virtuelle commence à s'exécuter. Par conséquent, le logiciel du fournisseur de baie de stockage peut échouer à appliquer des stratégies qui affectent la disposition optimale de volumes lors de l'utilisation régulière et après un basculement.

  Ce problème est résolu dans cette version. Ce correctif met à disposition les métadonnées de vSphere Virtual Volumes lorsque vSphere Virtual Volumes est configuré, mais pas lorsqu'une machine virtuelle commence à s'exécuter.

• PR 2096947 : Les appels de l'API getTaskUpdate API aux ID de tâches supprimés peuvent entraîner un débordement du journal et une consommation de bande passante de l'API supérieure

  Si vous utilisez un fournisseur VASA, plusieurs appels de getTaskUpdate à des tâches annulées ou supprimées peuvent être visibles. Par conséquent, vous pouvez observer une consommation de bande passante VASA supérieure et un débordement du journal.

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

• PR 2156841 : Des machines virtuelles utilisant EFI et exécutant Windows Server 2016 sur des processeurs AMD peuvent cesser de répondre lors du redémarrage

  Des machines virtuelles avec une version matérielle 10 ou ultérieure, utilisant EFI et exécutant Windows Server 2016 sur des processeurs AMD, peuvent cesser de répondre lors du redémarrage. Ce problème ne se produit pas si une machine virtuelle utilise le BIOS, ou si la version matérielle est 11 ou ultérieure, ou si le système d'exploitation invité n'est pas Windows, ou encore si les processeurs sont Intel.

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

• PR 2163734 : L'activation de NetFlow peut entraîner un temps de réponse élevé du réseau

  Si vous activez l'outil d'analyse réseau NetFlow pour échantillonner chaque paquet sur un groupe de ports vSphere Distributed Switch, en définissant le taux d'échantillonnage sur 0, la latence du réseau peut atteindre 1 000 ms au cas où les flux dépassent 1 million.

  Ce problème est résolu dans cette version. Vous pouvez optimiser davantage les performances de NetFlow en définissant le paramètre ipfixHashTableSize IPFIX sur -p "ipfixHashTableSize=65536" -m ipfix à l'aide de l'interface de ligne de commande. Pour terminer la tâche, redémarrez l'hôte ESXi.

• PR 2136004 : En raison de tickets obsolètes se trouvant dans des disques de RAM, certains hôtes ESXi peuvent cesser de répondre

  Les tickets obsolètes, qui ne sont pas supprimés avant que hostd génère un nouveau ticket, peuvent épuiser les inodes des disques de RAM. Par conséquent, certains hôtes ESXi peuvent cesser de répondre.

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

• PR 2152380 : L'utilitaire de ligne de commande esxtop peut ne pas afficher correctement la profondeur de file d'attente des périphériques

  L'utilitaire de ligne de commande esxtop peut ne pas afficher une valeur à jour de la profondeur de file d'attente des périphériques si la profondeur de file d'attente du chemin du périphérique correspondant change.

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

• PR 2133153 : La réinitialisation de la fonctionnalité de couleur verte peut ne pas fonctionner comme prévu pour les alarmes de santé du matériel

  La réinitialisation manuelle des alarmes de santé du matériel pour revenir à un état normal, en sélectionnant Réinitialiser sur vert après avoir cliqué avec le bouton droit sur le panneau encadré Alarmes peut ne pas fonctionner comme prévu. Les alarmes peuvent réapparaître après 90 secondes.

  Ce problème est résolu dans cette version. Avec ce correctif, vous pouvez personnaliser la durée pendant laquelle le système génère une nouvelle alarme si le problème n'est pas résolu. À l'aide de l'option avancée esxcli system settings advanced list -o /UserVars/HardwareHeathSyncTime, vous pouvez désactiver l'intervalle de synchronisation ou le définir sur votre heure préférée.

• PR 2131393 : Des capteurs de présence dans l'onglet État du matériel peuvent afficher l'état Inconnu

  Auparavant, si un composant, comme un processeur ou un ventilateur était manquant dans un système vCenter Server, les capteurs de présence affichaient l'état Inconnu. Cependant, les capteurs de présence n'ont pas d'état de santé qui leur est associé.

  Ce problème est résolu dans cette version. Ce correctif filtre les composants avec l'état Inconnu.

• PR 2154913 : VMware Tools peut afficher un état incorrect si vous configurez le répertoire /productLocker sur une banque de données VMFS partagée

  Si vous configurez le répertoire /productLocker sur une banque de données VMFS partagée, lorsque vous migrez une machine virtuelle à l'aide de vSphere vMotion, VMware Tools dans la machine virtuelle peut afficher un état incorrect non pris en charge.

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

• PR 2137041 : Une migration vSphere vMotion chiffrée peut échouer en raison d'un espace de segment de migration insuffisant

  Pour des machines virtuelles volumineuses, une migration vSphere vMotion chiffrée peut échouer en raison d'un espace de segment de migration insuffisant.

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

• PR 2165537 : Des machines virtuelles de proxy de sauvegarde peuvent passer à l'état non valide lors de la sauvegarde

  Une machine virtuelle qui effectue des centaines d'opérations d'ajout ou de suppression de disques à chaud sans être mise hors tension ou migrée peut être arrêtée et devenir non valide. Cela affecte les solutions de sauvegarde, et la machine virtuelle de proxy de sauvegarde peut être arrêtée en raison de ce problème.

  Un contenu similaire au suivant peut s'afficher dans le journal hostd :

  2018-06-08T10:33:14.150Z info hostd[15A03B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datatore/path/to/proxyVM/proxyVM.vmx opID=5953cf5e-3-a90a user=vpxuser:ADMIN\admin] State Transition (VM_STATE_ON -> VM_STATE_RECONFIGURING) ...
2018-06-08T10:33:14.167Z error hostd[15640B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datastore/path/to/proxyVM/proxyVM.vmx opID=5953cf5e-3-a90a user=vpxuser:ADMIN\admin] Could not apply pre-reconfigure domain changes: Failed to add file policies to domain :171: world ID :0:Cannot allocate memory ...
2018-06-08T10:33:14.826Z info hostd[15640B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datastore/path/to/proxyVM/proxyVM.vmx opID=5953cf5e-3-a90a user=vpxuser:ADMIN\admin] State Transition (VM_STATE_RECONFIGURING -> VM_STATE_ON) ...
2018-06-08T10:35:53.120Z error hostd[15A44B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datastore/path/to/proxyVM/proxyVM.vmx] Expected permission (3) for /vmfs/volumes/path/to/backupVM not found in domain 171

  Un contenu similaire au suivant peut s'afficher dans le journal vmkernel :

  2018-06-08T05:40:53.264Z cpu49:68763 opID=4c6a367c)World: 12235: VC opID 5953cf5e-3-a90a maps to vmkernel opID 4c6a367c
2018-06-08T05:40:53.264Z cpu49:68763 opID=4c6a367c)WARNING: Heap: 3534: Heap domainHeap-54 already at its maximum size. Cannot expand.

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

• PR 2157501 : De fausses alarmes de santé du matériel peuvent apparaître en raison de capteurs IPMI (Intelligent Platform Management Interface) désactivés ou à l'arrêt

  Des capteurs IPMI désactivés ou qui ne signalent aucune donnée peuvent générer de fausses alarmes de santé du matériel.

  Ce problème est résolu dans cette version. Ce correctif permet de filtrer ce type d'alarmes.

• PR 2167878 : Un hôte ESXi peut échouer avec un écran de diagnostic violet si vous activez IPFIX dans un trafic intense continu

  Lorsque vous activez IPFIX et que le trafic est intense avec différents flux, le signal de pulsation du système peut échouer à exclure le CPU d'IPFIX pendant un long moment et déclencher un écran de diagnostic violet.

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

• PR 2165567 : Les performances des opérations de vSphere vMotion longue distance à latence élevée peuvent se dégrader en raison de la limite de taille maximale de mémoire tampon du socket

  Des performances médiocres des opérations de vSphere vMotion longue distance peuvent être observées à une latence élevée, telle que 100 ms et plus, avec des liaisons réseau haute vitesse, telles que 10 GbE, en raison de la limite de mémoire tampon du socket codé en dur de 16 Mo.

  Ce problème est résolu dans cette version. Avec ce correctif, vous pouvez configurer le paramètre de taille maximale de mémoire tampon du socket SB_MAX_ADJ.

• PR 2139127 : Un hôte ESXi peut échouer avec un écran de diagnostic violet lors de la mise hors tension

  Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une condition de concurrence dans une requête par le protocole MLD (Multicast Listener Discovery) version 1 dans les environnements IPv6. Un message d'erreur semblable à celui-ci peut s'afficher :

  #PF Exception 14 in world 2098376:vmk0-rx-0 IP 0x41802e62abc1 addr 0x40
...
0x451a1b81b9d0:[0x41802e62abc1]mld_set_version@(tcpip4)#+0x161 stack: 0x430e0593c9e8
0x451a1b81ba20:[0x41802e62bb57]mld_input@(tcpip4)#+0x7fc stack: 0x30
0x451a1b81bb20:[0x41802e60d7f8]icmp6_input@(tcpip4)#+0xbe1 stack: 0x30
0x451a1b81bcf0:[0x41802e621d3b]ip6_input@(tcpip4)#+0x770 stack: 0x451a00000000

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

• PR 2082940 : Un hôte ESXi peut cesser de répondre lorsqu'un utilisateur crée et ajoute une carte vmknic dans la pile réseau vSphereProvisioning et l'utilise pour le trafic NFC

  Lorsqu'un utilisateur crée et ajoute une carte réseau VMkernel dans la pile réseau vSphereProvisioning pour l'utiliser pour le trafic NFC, le démon qui gère les connexions NFC peut ne pas parvenir à nettoyer les anciennes connexions. Cela entraîne l'épuisement de la limite autorisée de processus. Par conséquent, l'hôte cesse de répondre et ne parvient pas à créer des processus pour les connexions SSH entrantes.

  Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, vous devez redémarrer le démon NFCD.

• PR 2157817 : Il se peut que vous ne puissiez pas créer des volumes de fichiers Flash virtuel (VFFS) à l'aide d'une licence vSphere standard

  Une tentative pour créer des volumes VFFS en utilisant une licence vSphere standard peut échouer avec l'erreur Licence non disponible pour effectuer l'opération, car la fonctionnalité vSphere Flash Read Cache n'est pas couverte par cette édition. Ce problème est dû au fait que le système utilise des autorisations VMware vSphere Flash Read Cache pour vérifier si le provisionnement de VFFS est autorisé.

  Ce problème est résolu dans cette version. Étant donné que VFFS peut être utilisé en dehors de la fonctionnalité Flash Read Cache, la vérification est supprimée.

• PR 1220910 : Des verrous de multi-écriture ne peuvent pas être définis pour plus de 8 hôtes ESXi dans un environnement partagé

  Dans un environnement partagé tel que les disques de mappage de périphérique brut (RDM), vous ne pouvez pas utiliser de verrous de multi-écriture pour des machines virtuelles sur plus de 8 hôtes ESXi. Si vous migrez une machine virtuelle sur un neuvième hôte, il peut échouer à se mettre sous tension avec le message d'erreur Impossible d'ouvrir xxxx.vmdk ou l'un des snapshots dont il dépend. (Trop d'utilisateurs). Ce correctif rend l'option de configuration avancée /VMFS3/GBLAllowMW visible. Vous pouvez activer ou désactiver manuellement les verrous de multi-écriture pour plus de 8 hôtes en utilisant la fonction de verrouillage basée sur la génération.

  Ce problème est résolu dans cette version. Pour plus de détails, consultez l'article 1034165 de la base de connaissances VMware. 

• PR 2187719 : Les fournisseurs CIM tiers installés dans un hôte ESXi peuvent ne pas fonctionner correctement avec leurs applications externes

  Des fournisseurs CIM tiers, par HPE et Stratus par exemple, peuvent démarrer normalement, mais peuvent manquer de certaines fonctionnalités attendues lors de l'utilisation d'applications externes.

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

• PR 2096948 : Un hôte ESXi peut cesser de répondre si le signal de pulsation de banque de données s'arrête prématurément lors de la fermeture de VMware vSphere VMFS

  Un hôte ESXi peut cesser de répondre si le signal de pulsation de banque de données s'arrête prématurément lors de la fermeture de VMFS. Par conséquent, le gestionnaire d'affinité ne peut pas quitter normalement.

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

• PR 2166824 : Des systèmes de surveillance SNMP peuvent signaler des statistiques de mémoire incorrectes sur des hôtes ESXi

  Des systèmes de surveillance SNMP peuvent signaler des statistiques de mémoire sur les hôtes ESXi différentes des valeurs que les commandes free, top ou vmstat signalent.

  Ce problème est résolu dans cette version. Le correctif aligne la formule que des agents SNMP utilisent avec les autres outils de commande de ligne de commande.

• PR 2165281 : si la cible connectée à un hôte ESXi prend en charge le protocole ALUA implicite uniquement et possède seulement des chemins d'accès inactifs, l'hôte peut échouer avec un écran de diagnostic violet au moment de la détection du périphérique

  Si la cible connectée à un hôte ESXi prend en charge le protocole ALUA implicite uniquement et possède seulement des chemins d'accès inactifs, l'hôte peut échouer avec un écran de diagnostic violet au moment de la détection du périphérique en raison d'une condition de concurrence. Une trace de débogage similaire à la suivante peut apparaître :

  SCSIGetMultipleDeviceCommands (vmkDevice=0x0, result=0x451a0fc1be98, maxCommands=1, pluginDone=<optimized out>) at bora/vmkernel/storage/device/scsi_device_io.c:2476
0x00004180171688bc in vmk_ScsiGetNextDeviceCommand (vmkDevice=0x0) at bora/vmkernel/storage/device/scsi_device_io.c:2735
0x0000418017d8026c in nmp_DeviceStartLoop (device=device@entry=0x43048fc37350) at bora/modules/vmkernel/nmp/nmp_core.c:732
0x0000418017d8045d in nmpDeviceStartFromTimer (data=..., data@entry=...) at bora/modules/vmkernel/nmp/nmp_core.c:807

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

• PR 2166114 : Des E/S peuvent échouer sur certains chemins d'accès d'un périphérique en raison d'une erreur de commutateur défaillant

  Des E/S peuvent échouer avec une erreur FCP_DATA_CNT_MISMATCH, qui se traduit en HOST_ERROR dans l'hôte ESXi et qui indique des erreurs de lien ou des commutateurs défectueux sur certains chemins d'accès du périphérique.

  Ce problème est résolu dans cette version. Le correctif ajoute une option de configuration
  PSPDeactivateFlakyPath sur PSP_RR pour désactiver les chemins d'accès si des E/S échouent en continu avec HOST_ERROR et pour permettre aux
  chemins d'accès actifs de gérer les opérations. La configuration est activée par défaut avec l'option à désactiver, si elle n'est pas nécessaire.

• PR 2167098 : L'option Tous chemins hors service (All Paths Down, APD) n'est pas déclenchée pour les LUN derrière la cible IBM SAN Volume Controller (SVC), même si aucun chemin ne peut servir les E/S

  Dans une configuration d'ESXi avec plusieurs chemins d'accès aux LUN derrière des cibles SVC IBM, en cas de perte de connexion sur des chemins d'accès actifs et si, en même temps, les autres chemins d'accès connectés ne permettent pas de servir les E/S, l'hôte ESXi peut ne pas détecter cette condition comme APD, même si aucun chemin d'accès n'est disponible pour servir des E/S. Par conséquent, les E/S vers le périphérique ne sont pas en échec rapide.

  Ce problème est résolu dans cette version. Ce correctif est désactivé par défaut. Pour activer le correctif, définissez l'option de configuration ESXi /Scsi/ExtendAPDCondition sur esxcfg-advcfg -s 1 /Scsi/ExtendAPDCondition.

• PR 2120346 : Problème de performances réseau avec serveurs NUMA lents pour les périphériques utilisant VMware NetQueue

  Un ralentissement des performances du réseau des serveurs NUMA peut se produire pour les périphériques qui utilisent VMware NetQueue, en raison d'un seuil d'épinglage. Il survient lorsque les files d'attente Rx sont épinglées à un nœud NUMA en modifiant la valeur par défaut de la configuration avancée NetNetqNumaIOCpuPinThreshold.

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

• Après l'exécution de la commande de restauration du groupe de disques ESXCLI, le message d'erreur suivant peut s'afficher : Throttled : BlkAttr not ready for disk

  vSAN crée des composants de l'attribut blk après avoir créé un groupe de disques. Si le composant de l'attribut blk est absent de l'API qui prend en charge la commande diskgroup rebuild, le message d'avertissement suivant peut s'afficher dans le journal vmkernel : Throttled: BlkAttr not ready for disk.

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

• PR 2204439 : Les E/S lourdes émises vers des machines virtuelles snapshot en format SEsparse peuvent entraîner la corruption du système de fichiers du système d'exploitation invité

  Les E/S lourdes émises vers des machines virtuelles snapshot en format SEsparse peuvent entraîner la corruption du système de fichiers du système d'exploitation invité, ou la corruption de données dans les applications.

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

• PR 1996879 : Impossible d'effectuer certaines opérations liées à l'hôte, telles que placer des hôtes en mode de maintenance

  Dans les versions précédentes, vSAN Observer s'exécutait dans le groupe d'initialisation. Ce groupe peut occuper une autre mémoire de groupe et conserver la mémoire requise pour d'autres opérations liées à l'hôte. Pour résoudre le problème, vous pouvez exécuter vSAN Observer sous son propre groupe de ressources.

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

• PR 2000367 : L’examen de santé n'est pas disponible : Tous les hôtes se trouvent dans le même sous-réseau de réseau

  Dans vSphere 6.7 Update 1, certains clusters étendus vSAN peuvent contenir des hôtes dans différents réseaux L3. Par conséquent, l’examen de santé suivant n'est plus valide et a été supprimé : Tous les hôtes se trouvent dans le même sous-réseau de réseau.

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

• PR 2144043 : L’API renvoie l'exception SystemError lors de l'appel de l’API querySyncingVsanObjects sur vmodl VsanSystemEx  

  Vous pouvez obtenir l’exception SystemError lors de l'appel de l’API querySyncingVsanObjects sur vmodl VsanSystemEx,  en raison de la sollicitation de la mémoire causée par un grand nombre d’objets de synchronisation. Un message d'erreur peut s’afficher dans le volet Tâches récentes de vSphere Client.

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

• PR 2074369 : vSAN n’indique pas qu’un disque est dégradé même après un échec des E/S signalé sur le disque

  Dans certains cas, vSAN met du temps à signaler qu’un disque est dégradé, bien que les échecs des E/S soient signalés par le disque et que vSAN ait arrêté de traiter d’autres E/S à partir de ce disque.

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

ESXi670-201810202-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_vmw-ahci_1.2.3-1vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB vmw-ahci.

ESXi670-201810203-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_vmkusb_0.1-1vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB vmkusb.

ESXi670-201810204-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Critique
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_lpfc_11.4.33.3-11vmw.670.1.28.10302608
PR résolus	2095671, 2095681
Numéros CVE	S.O.

Ce correctif met à jour le VIB lpfc afin de résoudre le problème suivant :

• PR 2095671 : Des hôtes ESXi peuvent cesser de répondre ou échouer avec un écran de diagnostic violet si vous annulez le mappage de LUN depuis un système de stockage EMC VPLEX

  Si vous annulez le mappage de LUN depuis un système de stockage EMC VPLEX, les hôtes ESXi peuvent cesser de répondre ou échouer avec un écran de diagnostic violet. Des entrées de journal semblables à celles-ci peuvent s'afficher :
  2018-01-26T18:53:28.002Z cpu6:33514)WARNING: iodm: vmk_IodmEvent:192: vmhba1: FRAME DROP event has been observed 400 times in the last one minute.
2018-01-26T18:53:37.271Z cpu24:33058)WARNING: Unable to deliver event to user-space.

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

• PR 2095681 : des hôtes ESXi peuvent se déconnecter d'un système de stockage EMC VPLEX en raison d'une charge d'E/S importante

  Le pilote HBA d'un hôte ESXi peut se déconnecter à partir d'un système de stockage EMC VPLEX lorsque la charge d'E/S est importante et ne pas se reconnecter lorsque des chemins d'accès d'E/S sont disponibles.

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

ESXi670-201810205-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Modéré
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 inclus	VMware_bootbank_lsu-hp-hpsa-plugin_2.0.0-16vmw.670.1.28.10302608
PR résolus	2124061
Numéros CVE	S.O.

Ce correctif met à jour le VIB lsu-hp-hpsa-plugin afin de résoudre le problème suivant :

• PR 2124061 : VMware vSAN avec les contrôleurs HPE ProLiant Gen9 Smart Array peut ne pas allumer les voyants du localisateur sur le bon disque

  Dans un cluster vSAN avec les contrôleurs HPE ProLiant Gen9 Smart Array, tels que P440 et P840, les voyants du localisateur peuvent ne pas être allumés sur le bon périphérique en panne.

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

ESXi670-201810206-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Critique
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_brcmfcoe_11.4.1078.5-11vmw.670.1.28.10302608
PR résolus	2095671, 2095681
Numéros CVE	S.O.

Ce correctif met à jour le VIB brcmfcoe afin de résoudre le problème suivant :

• PR 2095671 : Des hôtes ESXi peuvent cesser de répondre ou échouer avec un écran de diagnostic violet si vous annulez le mappage de LUN depuis un système de stockage EMC VPLEX

  Si vous annulez le mappage de LUN depuis un système de stockage EMC VPLEX, les hôtes ESXi peuvent cesser de répondre ou échouer avec un écran de diagnostic violet. Des entrées de journal semblables à celles-ci peuvent s'afficher :
  2018-01-26T18:53:28.002Z cpu6:33514)WARNING: iodm: vmk_IodmEvent:192: vmhba1: FRAME DROP event has been observed 400 times in the last one minute.
2018-01-26T18:53:37.271Z cpu24:33058)WARNING: Unable to deliver event to user-space.

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

• PR 2095681 : des hôtes ESXi peuvent se déconnecter d'un système de stockage EMC VPLEX en raison d'une charge d'E/S importante

  Le pilote HBA d'un hôte ESXi peut se déconnecter à partir d'un système de stockage EMC VPLEX lorsque la charge d'E/S est importante et ne pas se reconnecter lorsque des chemins d'accès d'E/S sont disponibles.

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

ESXi670-201810207-UG

Catégorie des correctifs	Amélioration
Gravité des correctifs	Important
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 inclus	VMware_bootbank_lsu-smartpqi-plugin_1.0.0-3vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB lsu-hp-hpsa-plugin.

• ESXi 6.7 Update 1 active un plug-in LSU Microsemi Smart PQI (smartpqi) afin de prendre en charge les opérations de gestion des disques attachés sur le contrôleur HPE ProLiant Gen10 Smart Array.

ESXi670-201810208-UG

Catégorie des correctifs	Amélioration
Gravité des correctifs	Important
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 inclus	VMware_bootbank_lsu-intel-vmd-plugin_1.0.0-2vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB lsu-intel-vmd-plugin.

• ESXi 6.7 Update 1 vous permet d'exécuter les commandes ESXCLI de stockage suivantes pour activer le voyant d'état sur des disques SSD basés sur VMD Intel sans télécharger Intel CLI :

  • esxcli storage core device set -l locator -d
  • esxcli storage core device set -l error -d
  • esxcli storage core device set -l off -d. 

ESXi670-201810209-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMware_bootbank_cpu-microcode_6.7.0-1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB cpu-microcode.

ESXi670-201810210-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_elxnet_11.4.1095.0-5vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB elxnet.

ESXi670-201810211-UG

Catégorie des correctifs	Amélioration
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_nfnic_4.0.0.14-0vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB nfnic.

• ESXi 6.7 Update 1 permet la prise en charge du pilote nfnic pour Cisco UCS Fibre Channel over Ethernet (FCoE).

ESXi670-201810212-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Non
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_ne1000_0.8.4-1vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB ne1000.

ESXi670-201810213-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Critique
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_nvme_1.2.2.17-1vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB nvme.

• ESXi 6.7 Update 1 ajoute la prise en charge de NGUID dans le pilote NVMe.

ESXi670-201810214-UG

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 inclus	VMware_bootbank_lsu-lsi-lsi-mr3-plugin_1.0.0-13vmw.670.1.28.10302608
PR résolus	2112193
Numéros CVE	S.O.

Ce correctif met à jour le VIB lsu-lsi-lsi-mr3-plugin afin de résoudre le problème suivant :

• PR 2112193 : Un hôte ESXi et hostd peuvent cesser de répondre lors de l'utilisation du pilote lsi_mr3

  Un hôte ESXi et hostd peuvent cesser de répondre en raison d'un épuisement de mémoire causé par le plug-in de fonctionnement du disque lsi_mr3.

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

ESXi670-201810215-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Non
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_smartpqi_1.0.1.553-12vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB smartpqi.

ESXi670-201810216-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_nvmxnet3_2.0.0.29-1vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB nvmxnet3.

ESXi670-201810217-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_i40en_1.3.1-22vmw.670.1.28.10302608
PR résolus	2153838
Numéros CVE	S.O.

Ce correctif met à jour le VIB i40en.

• PR 2153838 : Wake-on-LAN (WOL) peut ne pas fonctionner pour les cartes réseau de la série Intel X722 dans les réseaux IPv6

  Le pilote Intel i40en natif dans ESXi peut ne pas fonctionner avec des cartes réseau de la série X722 dans des réseaux IPv6 et le service Wake-on-LAN peut échouer.

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

ESXi670-201810218-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_ipmi-ipmi-devintf_39.1-5vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB ipmi-ipmi-devintf.

ESXi670-201810219-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_ixgben_1.4.1-16vmw.670.1.28.10302608
PR résolus	2142221
Numéros CVE	S.O.

Ce correctif met à jour le VIB ixgben.

• PR 2142221 : Le message d'alerte d'inactivité suivant peut apparaître : Le périphérique 10fb ne prend pas en charge l'auto-négociation de contrôle de flux

  Des messages de journaux colorés Le périphérique 10fb ne prend pas en charge l'auto-négociation de contrôle de flux peuvent s'afficher en tant qu'alertes, mais il s'agit d'un message journal courant qui reflète l'état de la prise en charge du contrôle de flux de certaines cartes réseau. Sur certaines images OEM, ce journal peut s'afficher fréquemment, mais il n'indique aucun problème avec l'hôte ESXi.

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

ESXi670-201810220-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_qedentv_2.0.6.4-10vmw.670.1.28.10302608
PR résolus	2106647
Numéros CVE	S.O.

Ce correctif met à jour le VIB qedentv afin de résoudre le problème suivant :

• PR 2106647 : Des adaptateurs Ethernet QLogic FastLinQ QL41xxx peuvent ne pas créer de fonctions virtuelles une fois que l'interface unique de virtualisation d'E/S racine (SR-IOV) est activée

  Certains adaptateurs QLogic FastLinQ QL41xxx peuvent ne pas créer de fonctions virtuelles une fois que SR-IOV est activé sur l'adaptateur et que l'hôte est redémarré.

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

ESXi670-201810221-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_nenic_1.0.21.0-1vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB nenic.

ESXi670-201810222-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_bnxtroce_20.6.101.0-20vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB bnxtroce.

ESXi670-201810223-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB ipmi-ipmi-msghandler.

ESXi670-201810224-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_ipmi-ipmi-si-drv_39.1-5vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB ipmi-ipmi-si-drv.

ESXi670-201810225-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_iser_1.0.0.0-1vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB iser.

ESXi670-201810226-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_vmkfcoe_1.0.0.1-1vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB vmkfcoe.

ESXi670-201810227-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_lsi-mr3_7.702.13.00-5vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB lsi-mr3.

ESXi670-201810228-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_lsi-msgpt35_03.00.01.00-12vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB lsi-msgpt35.

ESXi670-201810229-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Non
Migration ou arrêt de la machine virtuelle requis	Non
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMware_bootbank_vmware-esx-esxcli-nvme-plugin_1.2.0.34-1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB vmware-esx-esxcli-nvme-plugin.

ESXi670-201810230-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_ntg3_4.1.3.2-1vmw.670.1.28.10302608
PR résolus	2156445
Numéros CVE	S.O.

Ce correctif met à jour le VIB ntg3.

• PR 2156445 : En raison de paquets surdimensionnés, des cartes réseau peuvent utiliser le pilote ntg3 pour cesser temporairement l'envoi de paquets

  Dans de rares occasions, les cartes réseau utilisant le pilote ntg3, telles que les cartes Broadcom BCM5719 et 5720 GbE, peuvent cesser temporairement l'envoi de paquets après un échec de la tentative d'envoyer un paquet dépassant la taille limite. Le pilote ntg3, version 4.1.3.2 résout ce problème.

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

ESXi670-201810231-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_nhpsa_2.0.22-3vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB nhpsa.

ESXi670-201810232-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_lsi-msgpt3_16.00.01.00-3vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB lsi-msgpt3.

ESXi670-201810233-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_lsi-msgpt2_20.00.04.00-5vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB lsi-msgpt2.

ESXi670-201810234-UG

Catégorie des correctifs	Correctif de bogues
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMW_bootbank_mtip32xx-native_3.9.8-1vmw.670.1.28.10302608
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB mtip32xx-native.

ESXi670-201810101-SG

Catégorie des correctifs	Sécurité
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Oui
Migration ou arrêt de la machine virtuelle requis	Oui
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMware_bootbank_vsanhealth_6.7.0-0.28.10176879 VMware_bootbank_vsan_6.7.0-0.28.10176879 VMware_bootbank_esx-base_6.7.0-0.28.10176879
PR résolus	2093391, 2099951, 2093433, 2098003, 2155702
Numéros CVE	CVE-2018-6974

Ce correctif met à jour les VIB esx-base, vsan et vsanhealth pour résoudre les problèmes suivants :

• Mise à jour de la bibliothèque libxml2

  La bibliothèque ESXi userworld libxml2 est mise à jour vers la version 2.9.7.

• Mise à jour du démon Network Time Protocol (NTP)

  Le démon NTP est mis à jour vers la version ntp-4.2.8p11.

• Mise à jour de la base de données SQLite

  La base de données SQLite est mise à jour vers la version 3.23.1.

• Mise à jour de la bibliothèque libcurl

  La bibliothèque ESXi userworld libcurl a été mise à jour vers libcurl-7.59.0.

• Mise à jour d'OpenSSH

  OpenSSH est mis à jour vers la version 7.7p1.

• Mise à jour de la bibliothèque OpenSSL

  La bibliothèque ESXi userworld OpenSSL est mise à jour vers la version openssl-1.0.2o.

• Mise à jour de la bibliothèque Python

  La bibliothèque tierce Python est mise à jour vers la version 3.5.5.

• ESXi contient une vulnérabilité de lecture hors limites dans le périphérique SVGA qui peut autoriser un invité à exécuter du code sur l'hôte. Le projet Common Vulnerabilities and Exposures (cve.mitre.org) a attribué l'identifiant CVE-2018-6974 à ce problème.

ESXi670-201810102-SG

Catégorie des correctifs	Sécurité
Gravité des correctifs	Modéré
Redémarrage de l'hôte requis	Non
Migration ou arrêt de la machine virtuelle requis	Non
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMware_locker_tools-light_10.3.2.9925305-10176879
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB tools-light.

• L'image ISO de Windows préalable à Vista pour VMware Tools n'est plus fournie avec ESXi. L'image ISO de Windows préalable à Vista est disponible au téléchargement pour les utilisateurs qui en ont besoin. Pour obtenir des informations sur le téléchargement, consultez la page Téléchargement de produits.

ESXi670-201810103-SG

Catégorie des correctifs	Sécurité
Gravité des correctifs	Important
Redémarrage de l'hôte requis	Non
Migration ou arrêt de la machine virtuelle requis	Non
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB inclus	VMware_bootbank_esx-ui_1.30.0-9946814
PR résolus	S.O.
Numéros CVE	S.O.

Ce correctif met à jour le VIB esx-ui.

ESXi-6.7.0-20181002001-standard

Nom du profil	ESXi-6.7.0-20181002001-standard
Build	Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.
Fournisseur	VMware, Inc.
Date de publication	16 octobre 2018
Niveau d'acceptation	PartnerSupported
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB concernés	VMW_bootbank_brcmfcoe_11.4.1078.5-11vmw.670.1.28.10302608 VMW_bootbank_nenic_1.0.21.0-1vmw.670.1.28.10302608 VMW_bootbank_vmw-ahci_1.2.3-1vmw.670.1.28.10302608 VMware_bootbank_esx-base_6.7.0-1.28.10302608 VMware_bootbank_vsan_6.7.0-1.28.10290435 VMware_bootbank_vsanhealth_6.7.0-1.28.10290721 VMware_bootbank_esx-update_6.7.0-1.28.10302608 VMware_bootbank_lsu-intel-vmd-plugin_1.0.0-2vmw.670.1.28.10302608 VMW_bootbank_lsi-msgpt3_16.00.01.00-3vmw.670.1.28.10302608 VMW_bootbank_smartpqi_1.0.1.553-12vmw.670.1.28.10302608 VMware_bootbank_vmware-esx-esxcli-nvme-plugin_1.2.0.34-1.28.10302608 VMW_bootbank_nvme_1.2.2.17-1vmw.670.1.28.10302608 VMW_bootbank_bnxtroce_20.6.101.0-20vmw.670.1.28.10302608 VMW_bootbank_vmkusb_0.1-1vmw.670.1.28.10302608 VMware_bootbank_lsu-hp-hpsa-plugin_2.0.0-16vmw.670.1.28.10302608 VMW_bootbank_ne1000_0.8.4-1vmw.670.1.28.10302608 VMware_bootbank_lsu-lsi-lsi-mr3-plugin_1.0.0-13vmw.670.1.28.10302608 VMW_bootbank_i40en_1.3.1-22vmw.670.1.28.10302608 VMW_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.670.1.28.10302608 VMware_bootbank_lsu-smartpqi-plugin_1.0.0-3vmw.670.1.28.10302608 VMW_bootbank_nenic_1.0.21.0-1vmw.670.1.28.10302608 VMW_bootbank_lsi-msgpt2_20.00.04.00-5vmw.670.1.28.10302608 VMware_bootbank_vmware-esx-esxcli-nvme-plugin_1.2.0.34-1.28.10302608 VMW_bootbank_ipmi-ipmi-devintf_39.1-5vmw.670.1.28.10302608 VMware_bootbank_vsanhealth_6.7.0-1.28.10290721 VMW_bootbank_nhpsa_2.0.22-3vmw.670.1.28.10302608 VMware_bootbank_cpu-microcode_6.7.0-1.28.10302608 VMW_bootbank_lsi-msgpt3_16.00.01.00-3vmw.670.1.28.10302608 VMW_bootbank_bnxtroce_20.6.101.0-20vmw.670.1.28.10302608 VMW_bootbank_mtip32xx-native_3.9.8-1vmw.670.1.28.10302608 VMware_bootbank_lsu-lsi-lsi-mr3-plugin_1.0.0-13vmw.670.1.28.10302608 VMW_bootbank_nhpsa_2.0.22-3vmw.670.1.28.10302608 VMW_bootbank_lsi-msgpt2_20.00.04.00-5vmw.670.1.28.10302608 VMW_bootbank_vmkfcoe_1.0.0.1-1vmw.670.1.28.10302608 VMW_bootbank_nfnic_4.0.0.14-0vmw.670.1.28.10302608 VMW_bootbank_mtip32xx-native_3.9.8-1vmw.670.1.28.10302608 VMware_bootbank_lsu-smartpqi-plugin_1.0.0-3vmw.670.1.28.10302608 VMW_bootbank_lsi-mr3_7.702.13.00-5vmw.670.1.28.10302608 VMW_bootbank_iser_1.0.0.0-1vmw.670.1.28.10302608 VMW_bootbank_nvmxnet3_2.0.0.29-1vmw.670.1.28.10302608 VMW_bootbank_lsi-msgpt35_03.00.01.00-12vmw.670.1.28.10302608 VMW_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.670.1.28.10302608 VMW_bootbank_elxnet_11.4.1095.0-5vmw.670.1.28.10302608 VMW_bootbank_ixgben_1.4.1-16vmw.670.1.28.10302608 VMW_bootbank_ntg3_4.1.3.2-1vmw.670.1.28.10302608 VMW_bootbank_ipmi-ipmi-si-drv_39.1-5vmw.670.1.28.10302608 VMW_bootbank_qedentv_2.0.6.4-10vmw.670.1.28.10302608 VMW_bootbank_i40en_1.3.1-22vmw.670.1.28.10302608 VMW_bootbank_ipmi-ipmi-devintf_39.1-5vmw.670.1.28.10302608 VMware_bootbank_cpu-microcode_6.7.0-1.28.10302608 VMW_bootbank_lpfc_11.4.33.3-11vmw.670.1.28.10302608
PR résolus	1220910 , 2036262 , 2036302 , 2039186 , 2046226 , 2057603 , 2058908 , 2066026 , 2071482 , 2072977 , 2078138 , 2078782 , 2078844 , 2079807 , 2080427 , 2082405 , 2083581 , 2084722 , 2085117 , 2086803 , 2086807 , 2089047 , 2096126 , 2096312 , 2096947 , 2096948 , 2097791 , 2098170 , 2098868 , 2103579 , 2103981 , 2106747 , 2107087 , 2107333 , 2110971 , 2118588 , 2119610 , 2119663 , 2120346 , 2126919 , 2128933 , 2129130 , 2129181 , 2131393 , 2131407 , 2133153 , 2133588 , 2136004 , 2137261 , 2139127 , 2145089 , 2146206 , 2146535 , 2149518 , 2152380 , 2154913 , 2156841 , 2157501 , 2157817 , 2163734 , 2165281 , 2165537 , 2165567 , 2166114 , 2167098 , 2167878 , 2173810 , 2186253 , 2187008 , 2204439 , 2095671 , 2095681 , 2124061 , 2095671 , 2095681 , 2093493 , 2103337 , 2112361 , 2099772 , 2137374 , 2112193 , 2153838 , 2142221 , 2106647 , 2137374 , 2156445
Numéros CVE associés	S/O

•  Ce correctif met à jour les problèmes suivants :

  • Si vous supprimez manuellement le dossier de bundle de support d'une machine virtuelle téléchargé dans le répertoire /scratch/downloads d'un hôte ESXi, le service hostd peut échouer. Cet échec se produit lorsque hostd tente automatiquement de supprimer les dossiers dans le répertoire /scratch/downloads une heure après la création des fichiers.

  • Si vous modifiez le fichier de configuration d'un hôte ESXi pour activer un lecteur de carte à puce comme périphérique de relais, vous ne pourrez peut-être pas utiliser le lecteur si vous avez également activé la fonctionnalité Support vMotion alors qu'un périphérique est connecté.

  • Dans les environnements vSAN, les journaux de VMkernel qui enregistrent les activités relatives aux machines virtuelles et à ESXi peuvent être saturés par le message Unable to register file system.

  • Si vous utilisez vSphere Web Client pour augmenter la taille de disque d'une machine virtuelle, vSphere Web Client peut ne pas refléter entièrement la nouvelle configuration et afficher la même allocation de stockage pour la machine virtuelle.

  • Si vous tentez de démarrer avec PXE une machine virtuelle qui utilise un microprogramme EFI, avec un adaptateur réseau vmxnet3 et WDS, et que vous n'avez pas désactivé l'option d'extension de variable Windows dans WDS, la machine virtuelle peut démarrer très lentement.

  • En raison de problèmes avec les dispositifs USB d'Apple, les périphériques avec une version d'iOS ultérieure à iOS 11 ne peuvent pas se connecter aux machines virtuelles avec une version d'OS X ultérieure à OS X 10.12.

  • Si vous activez la fonctionnalité Stateful Install sur un profil d'hôte et que la carte réseau VMkernel est connectée à un commutateur virtuel distribué, l'application du profil d'hôte sur un autre hôte ESXi 6.7 à l'aide de vSphere Auto Deploy peut échouer pendant un démarrage à l'aide de PXE. L'hôte reste en mode de maintenance. 

  • Si une machine virtuelle a des snapshots pris à l'aide de CBRC, puis que CBRC est désactivé, les opérations de consolidation de disque peuvent échouer avec une erreur Un paramètre spécifié n'est pas correct : spec.deviceChange.device en raison d'un fichier de synthèse supprimé une fois CBRC désactivé. Une alerte La consolidation des disques de machine virtuelle est nécessaire. s'affiche jusqu'à ce que le problème soit résolu. Ce correctif empêche le problème, mais il continue d'exister pour les machines virtuelles qui ont des snapshots pris avec la fonctionnalité CBRC activée, puis désactivée ultérieurement.

  • Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'un problème d'allocation de mémoire. 

  • En raison d'une erreur de calcul dans le noyau VMkernel, l'utilitaire esxtop signale des statistiques incorrectes pour la latence moyenne de périphérique par commande (DAVG/cmd) et la latence moyenne d'ESXi VMkernel par commande (KAVG/cmd) sur les LUN avec VMware vSphere Storage APIs - Array Integration (VAAI).

  • Ce correctif définit Storage Array Type Plug-in (SATP) sur VMW_SATP_ALUA, la règle de sélection de chemin d'accès (PSP, Path Selection Policy) sur VMW_PSP_RR et les options de réclamation sur tpgs_on comme valeurs par défaut pour les modèles de baies de stockage DELL MD suivants : MD32xx, MD32xxi, MD36xxi, MD36xxf, MD34xx, MD38xxf et MD38xxi. 

  • Après une migration à froid ou un basculement vSphere High Availability, une machine virtuelle peut ne pas se connecter à un groupe de ports distribués, car le port a été supprimé avant de mettre la machine virtuelle sous tension.

  • Les hôtes ESXi peuvent ne pas refléter le paramètre LONGUEUR DE TRANSFERT MAXIMALE signalé par le périphérique SCSI dans la page VPD des limites de bloc. Par conséquent, les commandes d'E/S émises avec une taille de transfert supérieure à la limite peuvent échouer avec une entrée de journal semblable à celles-ci :

    2017-01-24T12:09:40.065Z cpu6:1002438588)ScsiDeviceIO: SCSICompleteDeviceCommand:3033: Cmd(0x45a6816299c0) 0x2a, CmdSN 0x19d13f from world 1001390153 to dev "naa.514f0c5d38200035" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.

  • Ce correctif définit Storage Array Type Plug-in (SATP) sur VMW_SATP_ALUA, la règle de sélection de chemin d'accès (PSP, Path Selection Policy) sur VMW_PSP_RR et les options de réclamation sur tpgs_on comme valeurs par défaut pour les baies de stockage de type HITACHI OPEN-v avec prise en charge du protocole ALUA (Asymmetric Logical Unit Access).

    Ce correctif définit également Storage Array Type Plug-in (SATP) sur VMW_SATP_DEFAULT_AA, la règle de sélection de chemin d'accès (PSP) sur VMW_PSP_RR et les options de réclamation sur tpgs_off comme valeurs par défaut pour les baies de stockage de type HITACHI OPEN-v sans prise en charge du protocole ALUA.

  • Si la machine virtuelle cible et la machine virtuelle du proxy sont activées pour CBRC, le disque de snapshot mis au repos ne peut pas être ajouté à chaud sur la machine virtuelle du proxy, car le résumé du disque de snapshot dans la machine virtuelle cible est désactivé pendant la création du snapshot. Par conséquent, le processus de sauvegarde de la machine virtuelle échoue.

  • Le fichier syslog.log peut être rempli à plusieurs reprises par des messages relatifs aux appels à l'objet géré HostImageConfigManager.

  • Pendant l'extension de la partition du vidage mémoire d'un hôte ESXi, des rapports vCenter Server peuvent avertir qu'aucune cible de vidage mémoire n'est configurée, car avant d'augmenter la taille de la partition, la partition du vidage mémoire existante est temporairement désactivée.

  • En raison d'une condition de concurrence dans VSCSI, si vous utilisez EMC RecoverPoint, un hôte ESXi peut échouer avec un écran de diagnostic violet pendant l'arrêt ou la mise hors tension d'une machine virtuelle.

  • Les vSphere Virtual Volumes avec la clé de métadonnées VMW_VVolType définie sur Autre et la clé de métadonnées VMW_VVolTypeHint définie sur Sidecar peuvent ne pas pouvoir utiliser la clé de métadonnées VMW_VmID sur les machines virtuelles associées et ne peuvent pas être suivies au moyen des ID.

  • Ce correctif définit les règles de réclamation Storage Array Type Plugin (SATP) pour les baies de stockage Solidfire SSD SAN sur VMW_SATP_DEFAULT_AA et la règle de sélection de chemin d'accès (PSP, Path Selection Policy) sur VMW_PSP_RR avec 10 opérations d'E/S par seconde par défaut pour obtenir des performances optimales.

  • Un redémarrage rapide d'un système avec un contrôleur LSI ou un rechargement d'un pilote LSI, tel que lsi_mr3, peut placer les disques derrière le contrôleur LSI dans un état hors ligne. Le microprogramme du contrôleur LSI envoie une commande SCSI STOP UNIT au cours du déchargement, mais une commande SCSI START UNIT correspondante peut ne pas être émise durant le rechargement. Si les disques sont mis hors ligne, toutes les banques de données hébergées sur ces disques cessent de répondre ou deviennent inaccessibles.

  • Si vous utilisez vSphere vMotion pour migrer une machine virtuelle avec des filtres de périphérique de fichier à partir d'une banque de données vSphere Virtual Volumes vers un autre hôte, et que Changed Block Tracking (CBT), VMware vSphere Flash Read Cache (VFRC) ou les filtres d'E/S sont activés sur la machine virtuelle, la migration peut entraîner des problèmes avec l'une des fonctionnalités. Pendant la migration, les filtres de périphérique de fichier peuvent ne pas être correctement transférés sur l'hôte. Par conséquent, vous pouvez observer des sauvegardes incrémentielles corrompues dans CBT, une dégradation des performances de VFRC et des filtres d'E/S de cache, une réplication corrompue des filtres d'E/S et un disque endommagé, lorsque les filtres d'E/S de cache sont configurés en mode d'écriture. Des problèmes peuvent également se produire avec le chiffrement de machine virtuelle.

  • Si une machine virtuelle se trouve sur un snapshot VMFSsparse, les E/S émises vers la machine virtuelle peuvent être traitées uniquement partiellement au niveau de VMFSsparse, mais les couches supérieures, telles que les filtres d'E/S, peuvent supposer que le transfert a réussi. Cela peut entraîner l'incohérence des données. Ce correctif définit un état d'erreur transitoire pour référence à partir de couches supérieures si une E/S est effectuée.

  • Des données SCSI INQUIRY sont mises en cache au niveau de la couche Architecture de stockage enfichable (PSA, Pluggable Storage Architecture) pour les LUN RDM et la réponse pour les commandes SCSI INQUIRY suivantes peut être renvoyée à partir du cache au lieu d'interroger le LUN. Pour éviter l'extraction des données SCSI INQUIRY mises en cache, outre la modification du fichier .vmx d'une machine virtuelle avec RDM, ESXi 6.7 Update 1 vous permet d'ignorer SCSI INQUIRY également à l'aide de la commande ESXCLI

    esxcli storage core device inquirycache set --device <id périphérique> --ignore true.

    Avec l'option ESXCLI, un redémarrage de la machine virtuelle n'est pas nécessaire.

  • Ce correctif définit Storage Array Type Plugin (SATP) sur VMW_SATP_ALUA, la règle de sélection de chemin d'accès (PSP) sur VMW_PSP_RR et les options de réclamation sur tpgs_on en tant que valeurs par défaut pour les baies de stockage Tegile IntelliFlash avec prise en charge du protocole ALUA (Asymmetric Logical Unit Access). Le correctif définit également Storage Array Type Plugin (SATP) sur VMW_SATP_DEFAULT_AA, la règle de sélection de chemin d'accès (PSP) sur VMW_PSP_RR et les options de réclamation sur tpgs_off comme valeurs par défaut pour les baies de stockage Tegile IntelliFlash sans prise en charge du protocole ALUA.

  • Pendant un démarrage d'ESXi, si les commandes émises via la détection de périphériques initiale échouent avec ASYMMETRIC ACCESS STATE CHANGE UA, le basculement de chemin d'accès peut prendre plus de temps, car les commandes sont bloquées dans l'hôte ESXi. Cela peut ralentir le démarrage d'ESXi.
    Des entrées de journal semblables à celles-ci peuvent s'afficher :
    2018-05-14T01:26:28.464Z cpu1:2097770)NMP: nmp_ThrottleLogForDevice:3689: Cmd 0x1a (0x459a40bfbec0, 0) to dev "eui.0011223344550003" on path "vmhba64:C0:T0:L3" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x6 0x2a 0x6. Act:FAILOVER 2018-05-14T01:27:08.453Z cpu5:2097412)ScsiDeviceIO: 3029: Cmd(0x459a40bfbec0) 0x1a, CmdSN 0x29 from world 0 to dev "eui.0011223344550003" failed H:0x5 D:0x0 P:0x0 Invalid sense data: 0x0 0x0 0x0. 2018-05-14T01:27:48.911Z cpu4:2097181)ScsiDeviceIO: 3029: Cmd(0x459a40bfd540) 0x25, CmdSN 0x2c from world 0 to dev "eui.0011223344550003" failed H:0x5 D:0x0 P:0x0 Invalid sense data: 0x0 0x0 0x0. 2018-05-14T01:28:28.457Z cpu1:2097178)ScsiDeviceIO: 3029: Cmd(0x459a40bfbec0) 0x9e, CmdSN 0x2d from world 0 to dev "eui.0011223344550003" failed H:0x5 D:0x0 P:0x0 Invalid sense data: 0x0 0x0 0x0. 2018-05-14T01:28:28.910Z cpu2:2097368)WARNING: ScsiDevice: 7641: GetDeviceAttributes during periodic probe'eui.0011223344550003': failed with I/O error

  • Une banque de données VMFS6 peut signaler par erreur un manque d'espace, en raison d'entrées de cache obsolètes. Les rapports d'allocation d'espace sont corrigés avec les mises à jour automatiques des entrées du cache, mais ce correctif empêche l'erreur même avant une mise à jour.

  • Si vous supprimez un serveur NTP de votre configuration à l'aide de vSphere Web Client, les paramètres du serveur peuvent rester dans le fichier /etc/ntp.conf.

  • Si vous sélectionnez les microprocesseurs Intel Merom ou Penryn dans le menu déroulant Mode EVC de VMware avant la migration de machines virtuelles d'un hôte ESXi 6.0 vers un hôte ESXi 6.5 ou un hôte ESXi 6.7, les machines virtuelles peuvent cesser de répondre.

  • Les deux événements VOB suivants peuvent être générés en raison des variations de la latence d'E/S dans une baie de stockage, mais ils ne signalent pas un réel problème dans des machines virtuelles :

    • 1. Les performances du périphérique naa.xxx se sont détériorées. La latence d'E/S est passée d'une valeur moyenne de 4 114 microsecondes à 84 518 microsecondes.
    • 2. Les performances du périphérique naa.xxx se sont améliorées. La latence d'E/S est passée de 346 115 microsecondes à 67 046 microsecondes.

  • L'exportation d'une machine virtuelle volumineuse à l'aide de VMware Host Client peut échouer ou se terminer avec des fichiers VMDK incomplets, car le bail émis par la méthode ExportVm peut expirer avant la fin du transfert de fichier.

  • Un nombre élevé de tâches de mise en réseau, en particulier plusieurs appels à QueryNetworkHint(), peut dépasser la limite de mémoire du processus hostd et le faire échouer par intermittence.

  • Les lecteurs qui ne prennent pas en charge la page VPD des limites de bloc 0xb0 peuvent générer des journaux de code d'événement qui saturent le fichier vmkernel.log.

  • OMIVV s'appuie sur des informations de la propriété iDRAC hardware.systemInfo.otherIdentifyingInfo.ServiceTag pour extraire le paramètre SerialNumber permettant d'identifier certains serveurs modulaires Dell. Une incompatibilité dans la propriété serviceTag peut empêcher cette intégration.

  • vSphere Virtual Volumes peut cesser de répondre en raison d'une boucle infinie qui charge les CPU à 100 %, si un fournisseur VASA perd les informations de liaison provenant de la base de données. Hostd peut également cesser de répondre. Un message d'erreur irrécupérable peut s'afficher.

  • Les métadonnées de vSphere Virtual Volumes peuvent être disponibles uniquement lorsqu'une machine virtuelle commence à s'exécuter. Par conséquent, le logiciel du fournisseur de baie de stockage peut échouer à appliquer des stratégies qui affectent la disposition optimale de volumes lors de l'utilisation régulière et après un basculement.

  • Si vous utilisez un fournisseur VASA, plusieurs appels de getTaskUpdate à des tâches annulées ou supprimées peuvent être visibles. Par conséquent, vous pouvez observer une consommation de bande passante VASA supérieure et un débordement du journal.

  • Des machines virtuelles avec une version matérielle 10 ou ultérieure, utilisant EFI et exécutant Windows Server 2016 sur des processeurs AMD, peuvent cesser de répondre lors du redémarrage. Ce problème ne se produit pas si une machine virtuelle utilise le BIOS, ou si la version matérielle est 11 ou ultérieure, ou si le système d'exploitation invité n'est pas Windows, ou encore si les processeurs sont Intel.

  • Si vous activez l'outil d'analyse réseau NetFlow pour échantillonner chaque paquet sur un groupe de ports vSphere Distributed Switch, en définissant le taux d'échantillonnage sur 0, la latence du réseau peut atteindre 1 000 ms au cas où les flux dépassent 1 million.

  • Les tickets obsolètes, qui ne sont pas supprimés avant que hostd génère un nouveau ticket, peuvent épuiser les inodes des disques de RAM. Par conséquent, certains hôtes ESXi peuvent cesser de répondre.

  • L'utilitaire de ligne de commande esxtop peut ne pas afficher une valeur à jour de la profondeur de file d'attente des périphériques si la profondeur de file d'attente du chemin du périphérique correspondant change.

  • La réinitialisation manuelle des alarmes de santé du matériel pour revenir à un état normal, en sélectionnant Réinitialiser sur vert après avoir cliqué avec le bouton droit sur le panneau encadré Alarmes peut ne pas fonctionner comme prévu. Les alarmes peuvent réapparaître après 90 secondes.

  • Auparavant, si un composant, comme un processeur ou un ventilateur était manquant dans un système vCenter Server, les capteurs de présence affichaient l'état Inconnu. Cependant, les capteurs de présence n'ont pas d'état de santé qui leur est associé.

  • Si vous configurez le répertoire /productLocker sur une banque de données VMFS partagée, lorsque vous migrez une machine virtuelle à l'aide de vSphere vMotion, VMware Tools dans la machine virtuelle peut afficher un état incorrect non pris en charge.

  • Pour des machines virtuelles volumineuses, une migration vSphere vMotion chiffrée peut échouer en raison d'un espace de segment de migration insuffisant.

  • Une machine virtuelle qui effectue des centaines d'opérations d'ajout ou de suppression de disques à chaud sans être mise hors tension ou migrée peut être arrêtée et devenir non valide. Cela affecte les solutions de sauvegarde, et la machine virtuelle de proxy de sauvegarde peut être arrêtée en raison de ce problème.

    Un contenu similaire au suivant peut s'afficher dans le journal hostd :

    2018-06-08T10:33:14.150Z info hostd[15A03B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datatore/path/to/proxyVM/proxyVM.vmx opID=5953cf5e-3-a90a user=vpxuser:ADMIN\admin] State Transition (VM_STATE_ON -> VM_STATE_RECONFIGURING) ...
2018-06-08T10:33:14.167Z error hostd[15640B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datastore/path/to/proxyVM/proxyVM.vmx opID=5953cf5e-3-a90a user=vpxuser:ADMIN\admin] Could not apply pre-reconfigure domain changes: Failed to add file policies to domain :171: world ID :0:Cannot allocate memory ...
2018-06-08T10:33:14.826Z info hostd[15640B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datastore/path/to/proxyVM/proxyVM.vmx opID=5953cf5e-3-a90a user=vpxuser:ADMIN\admin] State Transition (VM_STATE_RECONFIGURING -> VM_STATE_ON) ...
2018-06-08T10:35:53.120Z error hostd[15A44B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datastore/path/to/proxyVM/proxyVM.vmx] Expected permission (3) for /vmfs/volumes/path/to/backupVM not found in domain 171

    Un contenu similaire au suivant peut s'afficher dans le journal vmkernel :

    2018-06-08T05:40:53.264Z cpu49:68763 opID=4c6a367c)World: 12235: VC opID 5953cf5e-3-a90a maps to vmkernel opID 4c6a367c
2018-06-08T05:40:53.264Z cpu49:68763 opID=4c6a367c)WARNING: Heap: 3534: Heap domainHeap-54 already at its maximum size. Cannot expand.

  • Des capteurs IPMI désactivés ou qui ne signalent aucune donnée peuvent générer de fausses alarmes de santé du matériel.

  • Lorsque vous activez IPFIX et que le trafic est intense avec différents flux, le signal de pulsation du système peut échouer à exclure le CPU d'IPFIX pendant un long moment et déclencher un écran de diagnostic violet.

  • Des performances médiocres des opérations de vSphere vMotion longue distance peuvent être observées à une latence élevée, telle que 100 ms et plus, avec des liaisons réseau haute vitesse, telles que 1 GbE et plus, en raison de la limite de mémoire tampon du socket codé en dur de 16 Mo.

  • Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une condition de concurrence dans une requête par le protocole MLD (Multicast Listener Discovery) version 1 dans les environnements IPv6. Un message d'erreur semblable à celui-ci peut s'afficher :

    #PF Exception 14 in world 2098376:vmk0-rx-0 IP 0x41802e62abc1 addr 0x40
...
0x451a1b81b9d0:[0x41802e62abc1]mld_set_version@(tcpip4)#+0x161 stack: 0x430e0593c9e8
0x451a1b81ba20:[0x41802e62bb57]mld_input@(tcpip4)#+0x7fc stack: 0x30
0x451a1b81bb20:[0x41802e60d7f8]icmp6_input@(tcpip4)#+0xbe1 stack: 0x30
0x451a1b81bcf0:[0x41802e621d3b]ip6_input@(tcpip4)#+0x770 stack: 0x451a00000000

  • Lorsqu'un utilisateur crée et ajoute une carte réseau VMkernel dans la pile réseau vSphereProvisioning pour l'utiliser pour le trafic NFC, le démon qui gère les connexions NFC peut ne pas parvenir à nettoyer les anciennes connexions. Cela entraîne l'épuisement de la limite autorisée de processus. Par conséquent, l'hôte cesse de répondre et ne parvient pas à créer des processus pour les connexions SSH entrantes.

  • Une tentative pour créer des volumes VFFS en utilisant une licence vSphere standard peut échouer avec l'erreur Licence non disponible pour effectuer l'opération, car la fonctionnalité vSphere Flash Read Cache n'est pas couverte par cette édition. Ce problème est dû au fait que le système utilise des autorisations VMware vSphere Flash Read Cache pour vérifier si le provisionnement de VFFS est autorisé.

  • Dans un environnement partagé tel que les disques de mappage de périphérique brut (RDM), vous ne pouvez pas utiliser de verrous de multi-écriture pour des machines virtuelles sur plus de 8 hôtes ESXi. Si vous migrez une machine virtuelle sur un neuvième hôte, il peut échouer à se mettre sous tension avec le message d'erreur Impossible d'ouvrir xxxx.vmdk ou l'un des snapshots dont il dépend. (Trop d'utilisateurs). Ce correctif rend l'option de configuration avancée /VMFS3/GBLAllowMW visible. Vous pouvez activer ou désactiver manuellement les verrous de multi-écriture pour plus de 8 hôtes en utilisant la fonction de verrouillage basée sur la génération.

  • Des fournisseurs CIM tiers, par HPE et Stratus par exemple, peuvent démarrer normalement, mais peuvent manquer de certaines fonctionnalités attendues lors de l'utilisation d'applications externes.

  • Un hôte ESXi peut cesser de répondre si le signal de pulsation de banque de données s'arrête prématurément lors de la fermeture de VMFS. Par conséquent, le gestionnaire d'affinité ne peut pas quitter normalement.

  • Des systèmes de surveillance SNMP peuvent signaler des statistiques de mémoire sur les hôtes ESXi différentes des valeurs que les commandes free, top ou vmstat signalent.

  • Si la cible connectée à un hôte ESXi prend en charge le protocole ALUA implicite uniquement et possède seulement des chemins d'accès inactifs, l'hôte peut échouer avec un écran de diagnostic violet au moment de la détection du périphérique en raison d'une condition de concurrence. Une trace de débogage similaire à la suivante peut apparaître :

    SCSIGetMultipleDeviceCommands (vmkDevice=0x0, result=0x451a0fc1be98, maxCommands=1, pluginDone=<optimized out>) at bora/vmkernel/storage/device/scsi_device_io.c:2476
0x00004180171688bc in vmk_ScsiGetNextDeviceCommand (vmkDevice=0x0) at bora/vmkernel/storage/device/scsi_device_io.c:2735
0x0000418017d8026c in nmp_DeviceStartLoop (device=device@entry=0x43048fc37350) at bora/modules/vmkernel/nmp/nmp_core.c:732
0x0000418017d8045d in nmpDeviceStartFromTimer (data=..., data@entry=...) at bora/modules/vmkernel/nmp/nmp_core.c:807

  • L'état Conformité du cluster d'un cluster compatible vSAN peut apparaître comme Non conforme, car la vérification de conformité peut ne pas reconnaître les banques de données vSAN comme des banques de données partagées.

  • Des E/S peuvent échouer avec une erreur FCP_DATA_CNT_MISMATCH, qui se traduit en HOST_ERROR dans l'hôte ESXi et qui indique des erreurs de lien ou des commutateurs défectueux sur certains chemins d'accès du périphérique.

  • Dans une configuration d'ESXi avec plusieurs chemins d'accès aux LUN derrière des cibles SVC IBM, en cas de perte de connexion sur des chemins d'accès actifs et si, en même temps, les autres chemins d'accès connectés ne permettent pas de servir les E/S, l'hôte ESXi peut ne pas détecter cette condition comme APD, même si aucun chemin d'accès n'est disponible pour servir des E/S. Par conséquent, les E/S vers le périphérique ne sont pas en échec rapide.

  • Un ralentissement des performances du réseau des serveurs NUMA peut se produire pour les périphériques qui utilisent VMware NetQueue, en raison d'un seuil d'épinglage. Il survient lorsque les files d'attente Rx sont épinglées à un nœud NUMA en modifiant la valeur par défaut de la configuration avancée NetNetqNumaIOCpuPinThreshold.

  • Certains hôtes peuvent ne pas parvenir à démarrer après la mise à niveau vers vSAN 6.7 Update 1 à partir d'une version antérieure.  Ce problème se produit sur les serveurs compatibles NUMA dans un cluster vSAN avec 3, 4 ou 5 groupes de disques par hôte. L'hôte peut expirer lors de la création du dernier groupe de disques. 

  • vSAN crée des composants de l'attribut blk après avoir créé un groupe de disques. Si le composant de l'attribut blk est absent de l'API qui prend en charge la commande diskgroup rebuild, le message d'avertissement suivant peut s'afficher dans le journal vmkernel : Throttled: BlkAttr not ready for disk.

  • Lorsque tous les groupes de disques sont supprimés d'un cluster vSAN, vSphere Client affiche un avertissement similaire au suivant :
    Le cluster VMware vSAN du centre de données n'a pas de capacité 
    Après que vous désactivez vSAN sur le cluster, le message d'avertissement persiste.

  • Si vous annulez le mappage de LUN depuis un système de stockage EMC VPLEX, les hôtes ESXi peuvent cesser de répondre ou échouer avec un écran de diagnostic violet. Des entrées de journal semblables à celles-ci peuvent s'afficher :
    2018-01-26T18:53:28.002Z cpu6:33514)WARNING: iodm: vmk_IodmEvent:192: vmhba1: FRAME DROP event has been observed 400 times in the last one minute.
2018-01-26T18:53:37.271Z cpu24:33058)WARNING: Unable to deliver event to user-space.

  • Le pilote HBA d'un hôte ESXi peut se déconnecter à partir d'un système de stockage EMC VPLEX lorsque la charge d'E/S est importante et ne pas se reconnecter lorsque des chemins d'accès d'E/S sont disponibles.

  • Dans un cluster vSAN avec les contrôleurs HPE ProLiant Gen9 Smart Array, tels que P440 et P840, les voyants du localisateur peuvent ne pas être allumés sur le bon périphérique en panne.

  • Si vous annulez le mappage de LUN depuis un système de stockage EMC VPLEX, les hôtes ESXi peuvent cesser de répondre ou échouer avec un écran de diagnostic violet. Des entrées de journal semblables à celles-ci peuvent s'afficher :
    2018-01-26T18:53:28.002Z cpu6:33514)WARNING: iodm: vmk_IodmEvent:192: vmhba1: FRAME DROP event has been observed 400 times in the last one minute.
2018-01-26T18:53:37.271Z cpu24:33058)WARNING: Unable to deliver event to user-space.

  • Le pilote HBA d'un hôte ESXi peut se déconnecter à partir d'un système de stockage EMC VPLEX lorsque la charge d'E/S est importante et ne pas se reconnecter lorsque des chemins d'accès d'E/S sont disponibles.

  • ESXi 6.7 Update 1 active un plug-in LSU Microsemi Smart PQI (smartpqi) afin de prendre en charge les opérations de gestion des disques attachés sur le contrôleur HPE ProLiant Gen10 Smart Array.

  • ESXi 6.7 Update 1 vous permet d'exécuter les commandes ESXCLI de stockage suivantes pour activer le voyant d'état sur des disques SSD basés sur VMD Intel sans télécharger Intel CLI :

    • esxcli storage core device set -l locator -d
    • esxcli storage core device set -l error -d
    • esxcli storage core device set -l off -d. 
  • ESXi 6.7 Update 1 permet la prise en charge du pilote nfnic pour Cisco UCS Fibre Channel over Ethernet (FCoE).
  • ESXi 6.7 Update 1 ajoute la prise en charge de NGUID dans le pilote NVMe.
  • Un hôte ESXi et hostd peuvent cesser de répondre en raison d'un épuisement de mémoire causé par le plug-in de fonctionnement du disque lsi_mr3.
  • Le pilote Intel i40en natif dans ESXi peut ne pas fonctionner avec des cartes réseau de la série X722 dans des réseaux IPv6 et le service Wake-on-LAN peut échouer.
  • Des messages de journaux colorés Le périphérique 10fb ne prend pas en charge l'auto-négociation de contrôle de flux peuvent s'afficher en tant qu'alertes, mais il s'agit d'un message journal courant qui reflète l'état de la prise en charge du contrôle de flux de certaines cartes réseau. Sur certaines images OEM, ce journal peut s'afficher fréquemment, mais il n'indique aucun problème avec l'hôte ESXi.
  • Certains adaptateurs QLogic FastLinQ QL41xxx peuvent ne pas créer de fonctions virtuelles une fois que SR-IOV est activé sur l'adaptateur et que l'hôte est redémarré.
  • Dans de rares occasions, les cartes réseau utilisant le pilote ntg3, telles que les cartes Broadcom BCM5719 et 5720 GbE, peuvent cesser temporairement l'envoi de paquets après un échec de la tentative d'envoyer un paquet dépassant la taille limite. Le pilote ntg3, version 4.1.3.2 résout ce problème.

ESXi-6.7.0-20181002001-no-tools

Nom du profil	ESXi-6.7.0-20181002001-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	16 octobre 2018
Niveau d'acceptation	PartnerSupported
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB concernés	VMW_bootbank_brcmfcoe_11.4.1078.5-11vmw.670.1.28.10302608 VMW_bootbank_nenic_1.0.21.0-1vmw.670.1.28.10302608 VMW_bootbank_vmw-ahci_1.2.3-1vmw.670.1.28.10302608 VMware_bootbank_esx-base_6.7.0-1.28.10302608 VMware_bootbank_vsan_6.7.0-1.28.10290435 VMware_bootbank_vsanhealth_6.7.0-1.28.10290721 VMware_bootbank_esx-update_6.7.0-1.28.10302608 VMware_bootbank_lsu-intel-vmd-plugin_1.0.0-2vmw.670.1.28.10302608 VMW_bootbank_lsi-msgpt3_16.00.01.00-3vmw.670.1.28.10302608 VMW_bootbank_smartpqi_1.0.1.553-12vmw.670.1.28.10302608 VMware_bootbank_vmware-esx-esxcli-nvme-plugin_1.2.0.34-1.28.10302608 VMW_bootbank_nvme_1.2.2.17-1vmw.670.1.28.10302608 VMW_bootbank_bnxtroce_20.6.101.0-20vmw.670.1.28.10302608 VMW_bootbank_vmkusb_0.1-1vmw.670.1.28.10302608 VMware_bootbank_lsu-hp-hpsa-plugin_2.0.0-16vmw.670.1.28.10302608 VMW_bootbank_ne1000_0.8.4-1vmw.670.1.28.10302608 VMware_bootbank_lsu-lsi-lsi-mr3-plugin_1.0.0-13vmw.670.1.28.10302608 VMW_bootbank_i40en_1.3.1-22vmw.670.1.28.10302608 VMW_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.670.1.28.10302608 VMware_bootbank_lsu-smartpqi-plugin_1.0.0-3vmw.670.1.28.10302608 VMW_bootbank_nenic_1.0.21.0-1vmw.670.1.28.10302608 VMW_bootbank_lsi-msgpt2_20.00.04.00-5vmw.670.1.28.10302608 VMware_bootbank_vmware-esx-esxcli-nvme-plugin_1.2.0.34-1.28.10302608 VMW_bootbank_ipmi-ipmi-devintf_39.1-5vmw.670.1.28.10302608 VMware_bootbank_vsanhealth_6.7.0-1.28.10290721 VMW_bootbank_nhpsa_2.0.22-3vmw.670.1.28.10302608 VMware_bootbank_cpu-microcode_6.7.0-1.28.10302608 VMW_bootbank_lsi-msgpt3_16.00.01.00-3vmw.670.1.28.10302608 VMW_bootbank_bnxtroce_20.6.101.0-20vmw.670.1.28.10302608 VMW_bootbank_mtip32xx-native_3.9.8-1vmw.670.1.28.10302608 VMware_bootbank_lsu-lsi-lsi-mr3-plugin_1.0.0-13vmw.670.1.28.10302608 VMW_bootbank_nhpsa_2.0.22-3vmw.670.1.28.10302608 VMW_bootbank_lsi-msgpt2_20.00.04.00-5vmw.670.1.28.10302608 VMW_bootbank_vmkfcoe_1.0.0.1-1vmw.670.1.28.10302608 VMW_bootbank_nfnic_4.0.0.14-0vmw.670.1.28.10302608 VMW_bootbank_mtip32xx-native_3.9.8-1vmw.670.1.28.10302608 VMware_bootbank_lsu-smartpqi-plugin_1.0.0-3vmw.670.1.28.10302608 VMW_bootbank_lsi-mr3_7.702.13.00-5vmw.670.1.28.10302608 VMW_bootbank_iser_1.0.0.0-1vmw.670.1.28.10302608 VMW_bootbank_nvmxnet3_2.0.0.29-1vmw.670.1.28.10302608 VMW_bootbank_lsi-msgpt35_03.00.01.00-12vmw.670.1.28.10302608 VMW_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.670.1.28.10302608 VMW_bootbank_elxnet_11.4.1095.0-5vmw.670.1.28.10302608 VMW_bootbank_ixgben_1.4.1-16vmw.670.1.28.10302608 VMW_bootbank_ntg3_4.1.3.2-1vmw.670.1.28.10302608 VMW_bootbank_ipmi-ipmi-si-drv_39.1-5vmw.670.1.28.10302608 VMW_bootbank_qedentv_2.0.6.4-10vmw.670.1.28.10302608 VMW_bootbank_i40en_1.3.1-22vmw.670.1.28.10302608 VMW_bootbank_ipmi-ipmi-devintf_39.1-5vmw.670.1.28.10302608 VMware_bootbank_cpu-microcode_6.7.0-1.28.10302608 VMW_bootbank_lpfc_11.4.33.3-11vmw.670.1.28.10302608
PR résolus	1220910 , 2036262 , 2036302 , 2039186 , 2046226 , 2057603 , 2058908 , 2066026 , 2071482 , 2072977 , 2078138 , 2078782 , 2078844 , 2079807 , 2080427 , 2082405 , 2083581 , 2084722 , 2085117 , 2086803 , 2086807 , 2089047 , 2096126 , 2096312 , 2096947 , 2096948 , 2097791 , 2098170 , 2098868 , 2103579 , 2103981 , 2106747 , 2107087 , 2107333 , 2110971 , 2118588 , 2119610 , 2119663 , 2120346 , 2126919 , 2128933 , 2129130 , 2129181 , 2131393 , 2131407 , 2133153 , 2133588 , 2136004 , 2137261 , 2139127 , 2145089 , 2146206 , 2146535 , 2149518 , 2152380 , 2154913 , 2156841 , 2157501 , 2157817 , 2163734 , 2165281 , 2165537 , 2165567 , 2166114 , 2167098 , 2167878 , 2173810 , 2186253 , 2187008 , 2204439 , 2095671 , 2095681 , 2124061 , 2095671 , 2095681 , 2093493 , 2103337 , 2112361 , 2099772 , 2137374 , 2112193 , 2153838 , 2142221 , 2106647 , 2137374 , 2156445
Numéros CVE associés	S/O

• Ce correctif met à jour les problèmes suivants :

  • Si vous supprimez manuellement le dossier de bundle de support d'une machine virtuelle téléchargé dans le répertoire /scratch/downloads d'un hôte ESXi, le service hostd peut échouer. Cet échec se produit lorsque hostd tente automatiquement de supprimer les dossiers dans le répertoire /scratch/downloads une heure après la création des fichiers.

  • Si vous modifiez le fichier de configuration d'un hôte ESXi pour activer un lecteur de carte à puce comme périphérique de relais, vous ne pourrez peut-être pas utiliser le lecteur si vous avez également activé la fonctionnalité Support vMotion alors qu'un périphérique est connecté.

  • Dans les environnements vSAN, les journaux de VMkernel qui enregistrent les activités relatives aux machines virtuelles et à ESXi peuvent être saturés par le message Unable to register file system.

  • Si vous utilisez vSphere Web Client pour augmenter la taille de disque d'une machine virtuelle, vSphere Web Client peut ne pas refléter entièrement la nouvelle configuration et afficher la même allocation de stockage pour la machine virtuelle.

  • Si vous tentez de démarrer avec PXE une machine virtuelle qui utilise un microprogramme EFI, avec un adaptateur réseau vmxnet3 et WDS, et que vous n'avez pas désactivé l'option d'extension de variable Windows dans WDS, la machine virtuelle peut démarrer très lentement.

  • En raison de problèmes avec les dispositifs USB d'Apple, les périphériques avec une version d'iOS ultérieure à iOS 11 ne peuvent pas se connecter aux machines virtuelles avec une version d'OS X ultérieure à OS X 10.12.

  • Si vous activez la fonctionnalité Stateful Install sur un profil d'hôte et que la carte réseau VMkernel est connectée à un commutateur virtuel distribué, l'application du profil d'hôte sur un autre hôte ESXi 6.7 à l'aide de vSphere Auto Deploy peut échouer pendant un démarrage à l'aide de PXE. L'hôte reste en mode de maintenance. 

  • Si une machine virtuelle a des snapshots pris à l'aide de CBRC, puis que CBRC est désactivé, les opérations de consolidation de disque peuvent échouer avec une erreur Un paramètre spécifié n'est pas correct : spec.deviceChange.device en raison d'un fichier de synthèse supprimé une fois CBRC désactivé. Une alerte La consolidation des disques de machine virtuelle est nécessaire. s'affiche jusqu'à ce que le problème soit résolu. Ce correctif empêche le problème, mais il continue d'exister pour les machines virtuelles qui ont des snapshots pris avec la fonctionnalité CBRC activée, puis désactivée ultérieurement.

  • Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'un problème d'allocation de mémoire. 

  • En raison d'une erreur de calcul dans le noyau VMkernel, l'utilitaire esxtop signale des statistiques incorrectes pour la latence moyenne de périphérique par commande (DAVG/cmd) et la latence moyenne d'ESXi VMkernel par commande (KAVG/cmd) sur les LUN avec VMware vSphere Storage APIs - Array Integration (VAAI).

  • Ce correctif définit Storage Array Type Plug-in (SATP) sur VMW_SATP_ALUA, la règle de sélection de chemin d'accès (PSP, Path Selection Policy) sur VMW_PSP_RR et les options de réclamation sur tpgs_on comme valeurs par défaut pour les modèles de baies de stockage DELL MD suivants : MD32xx, MD32xxi, MD36xxi, MD36xxf, MD34xx, MD38xxf et MD38xxi. 

  • Après une migration à froid ou un basculement vSphere High Availability, une machine virtuelle peut ne pas se connecter à un groupe de ports distribués, car le port a été supprimé avant de mettre la machine virtuelle sous tension.

  • Les hôtes ESXi peuvent ne pas refléter le paramètre LONGUEUR DE TRANSFERT MAXIMALE signalé par le périphérique SCSI dans la page VPD des limites de bloc. Par conséquent, les commandes d'E/S émises avec une taille de transfert supérieure à la limite peuvent échouer avec une entrée de journal semblable à celles-ci :

    2017-01-24T12:09:40.065Z cpu6:1002438588)ScsiDeviceIO: SCSICompleteDeviceCommand:3033: Cmd(0x45a6816299c0) 0x2a, CmdSN 0x19d13f from world 1001390153 to dev "naa.514f0c5d38200035" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.

  • Ce correctif définit Storage Array Type Plug-in (SATP) sur VMW_SATP_ALUA, la règle de sélection de chemin d'accès (PSP, Path Selection Policy) sur VMW_PSP_RR et les options de réclamation sur tpgs_on comme valeurs par défaut pour les baies de stockage de type HITACHI OPEN-v avec prise en charge du protocole ALUA (Asymmetric Logical Unit Access).

    Ce correctif définit également Storage Array Type Plug-in (SATP) sur VMW_SATP_DEFAULT_AA, la règle de sélection de chemin d'accès (PSP) sur VMW_PSP_RR et les options de réclamation sur tpgs_off comme valeurs par défaut pour les baies de stockage de type HITACHI OPEN-v sans prise en charge du protocole ALUA.

  • Si la machine virtuelle cible et la machine virtuelle du proxy sont activées pour CBRC, le disque de snapshot mis au repos ne peut pas être ajouté à chaud sur la machine virtuelle du proxy, car le résumé du disque de snapshot dans la machine virtuelle cible est désactivé pendant la création du snapshot. Par conséquent, le processus de sauvegarde de la machine virtuelle échoue.

  • Le fichier syslog.log peut être rempli à plusieurs reprises par des messages relatifs aux appels à l'objet géré HostImageConfigManager.

  • Pendant l'extension de la partition du vidage mémoire d'un hôte ESXi, des rapports vCenter Server peuvent avertir qu'aucune cible de vidage mémoire n'est configurée, car avant d'augmenter la taille de la partition, la partition du vidage mémoire existante est temporairement désactivée.

  • En raison d'une condition de concurrence dans VSCSI, si vous utilisez EMC RecoverPoint, un hôte ESXi peut échouer avec un écran de diagnostic violet pendant l'arrêt ou la mise hors tension d'une machine virtuelle.

  • Les vSphere Virtual Volumes avec la clé de métadonnées VMW_VVolType définie sur Autre et la clé de métadonnées VMW_VVolTypeHint définie sur Sidecar peuvent ne pas pouvoir utiliser la clé de métadonnées VMW_VmID sur les machines virtuelles associées et ne peuvent pas être suivies au moyen des ID.

  • Ce correctif définit les règles de réclamation Storage Array Type Plugin (SATP) pour les baies de stockage Solidfire SSD SAN sur VMW_SATP_DEFAULT_AA et la règle de sélection de chemin d'accès (PSP, Path Selection Policy) sur VMW_PSP_RR avec 10 opérations d'E/S par seconde par défaut pour obtenir des performances optimales.

  • Un redémarrage rapide d'un système avec un contrôleur LSI ou un rechargement d'un pilote LSI, tel que lsi_mr3, peut placer les disques derrière le contrôleur LSI dans un état hors ligne. Le microprogramme du contrôleur LSI envoie une commande SCSI STOP UNIT au cours du déchargement, mais une commande SCSI START UNIT correspondante peut ne pas être émise durant le rechargement. Si les disques sont mis hors ligne, toutes les banques de données hébergées sur ces disques cessent de répondre ou deviennent inaccessibles.

  • Si vous utilisez vSphere vMotion pour migrer une machine virtuelle avec des filtres de périphérique de fichier à partir d'une banque de données vSphere Virtual Volumes vers un autre hôte, et que Changed Block Tracking (CBT), VMware vSphere Flash Read Cache (VFRC) ou les filtres d'E/S sont activés sur la machine virtuelle, la migration peut entraîner des problèmes avec l'une des fonctionnalités. Pendant la migration, les filtres de périphérique de fichier peuvent ne pas être correctement transférés sur l'hôte. Par conséquent, vous pouvez observer des sauvegardes incrémentielles corrompues dans CBT, une dégradation des performances de VFRC et des filtres d'E/S de cache, une réplication corrompue des filtres d'E/S et un disque endommagé, lorsque les filtres d'E/S de cache sont configurés en mode d'écriture. Des problèmes peuvent également se produire avec le chiffrement de machine virtuelle.

  • Si une machine virtuelle se trouve sur un snapshot VMFSsparse, les E/S émises vers la machine virtuelle peuvent être traitées uniquement partiellement au niveau de VMFSsparse, mais les couches supérieures, telles que les filtres d'E/S, peuvent supposer que le transfert a réussi. Cela peut entraîner l'incohérence des données. Ce correctif définit un état d'erreur transitoire pour référence à partir de couches supérieures si une E/S est effectuée.

  • Des données SCSI INQUIRY sont mises en cache au niveau de la couche Architecture de stockage enfichable (PSA, Pluggable Storage Architecture) pour les LUN RDM et la réponse pour les commandes SCSI INQUIRY suivantes peut être renvoyée à partir du cache au lieu d'interroger le LUN. Pour éviter l'extraction des données SCSI INQUIRY mises en cache, outre la modification du fichier .vmx d'une machine virtuelle avec RDM, ESXi 6.7 Update 1 vous permet d'ignorer SCSI INQUIRY également à l'aide de la commande ESXCLI

    esxcli storage core device inquirycache set --device <id périphérique> --ignore true.

    Avec l'option ESXCLI, un redémarrage de la machine virtuelle n'est pas nécessaire.

  • Ce correctif définit Storage Array Type Plugin (SATP) sur VMW_SATP_ALUA, la règle de sélection de chemin d'accès (PSP) sur VMW_PSP_RR et les options de réclamation sur tpgs_on en tant que valeurs par défaut pour les baies de stockage Tegile IntelliFlash avec prise en charge du protocole ALUA (Asymmetric Logical Unit Access). Le correctif définit également Storage Array Type Plugin (SATP) sur VMW_SATP_DEFAULT_AA, la règle de sélection de chemin d'accès (PSP) sur VMW_PSP_RR et les options de réclamation sur tpgs_off comme valeurs par défaut pour les baies de stockage Tegile IntelliFlash sans prise en charge du protocole ALUA.

  • Pendant un démarrage d'ESXi, si les commandes émises via la détection de périphériques initiale échouent avec ASYMMETRIC ACCESS STATE CHANGE UA, le basculement de chemin d'accès peut prendre plus de temps, car les commandes sont bloquées dans l'hôte ESXi. Cela peut ralentir le démarrage d'ESXi.
    Des entrées de journal semblables à celles-ci peuvent s'afficher :
    2018-05-14T01:26:28.464Z cpu1:2097770)NMP: nmp_ThrottleLogForDevice:3689: Cmd 0x1a (0x459a40bfbec0, 0) to dev "eui.0011223344550003" on path "vmhba64:C0:T0:L3" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x6 0x2a 0x6. Act:FAILOVER 2018-05-14T01:27:08.453Z cpu5:2097412)ScsiDeviceIO: 3029: Cmd(0x459a40bfbec0) 0x1a, CmdSN 0x29 from world 0 to dev "eui.0011223344550003" failed H:0x5 D:0x0 P:0x0 Invalid sense data: 0x0 0x0 0x0. 2018-05-14T01:27:48.911Z cpu4:2097181)ScsiDeviceIO: 3029: Cmd(0x459a40bfd540) 0x25, CmdSN 0x2c from world 0 to dev "eui.0011223344550003" failed H:0x5 D:0x0 P:0x0 Invalid sense data: 0x0 0x0 0x0. 2018-05-14T01:28:28.457Z cpu1:2097178)ScsiDeviceIO: 3029: Cmd(0x459a40bfbec0) 0x9e, CmdSN 0x2d from world 0 to dev "eui.0011223344550003" failed H:0x5 D:0x0 P:0x0 Invalid sense data: 0x0 0x0 0x0. 2018-05-14T01:28:28.910Z cpu2:2097368)WARNING: ScsiDevice: 7641: GetDeviceAttributes during periodic probe'eui.0011223344550003': failed with I/O error

  • Une banque de données VMFS6 peut signaler par erreur un manque d'espace, en raison d'entrées de cache obsolètes. Les rapports d'allocation d'espace sont corrigés avec les mises à jour automatiques des entrées du cache, mais ce correctif empêche l'erreur même avant une mise à jour.

  • Si vous supprimez un serveur NTP de votre configuration à l'aide de vSphere Web Client, les paramètres du serveur peuvent rester dans le fichier /etc/ntp.conf.

  • Si vous sélectionnez les microprocesseurs Intel Merom ou Penryn dans le menu déroulant Mode EVC de VMware avant la migration de machines virtuelles d'un hôte ESXi 6.0 vers un hôte ESXi 6.5 ou un hôte ESXi 6.7, les machines virtuelles peuvent cesser de répondre.

  • Les deux événements VOB suivants peuvent être générés en raison des variations de la latence d'E/S dans une baie de stockage, mais ils ne signalent pas un réel problème dans des machines virtuelles :

    • 1. Les performances du périphérique naa.xxx se sont détériorées. La latence d'E/S est passée d'une valeur moyenne de 4 114 microsecondes à 84 518 microsecondes.
    • 2. Les performances du périphérique naa.xxx se sont améliorées. La latence d'E/S est passée de 346 115 microsecondes à 67 046 microsecondes.

  • L'exportation d'une machine virtuelle volumineuse à l'aide de VMware Host Client peut échouer ou se terminer avec des fichiers VMDK incomplets, car le bail émis par la méthode ExportVm peut expirer avant la fin du transfert de fichier.

  • Un nombre élevé de tâches de mise en réseau, en particulier plusieurs appels à QueryNetworkHint(), peut dépasser la limite de mémoire du processus hostd et le faire échouer par intermittence.

  • Les lecteurs qui ne prennent pas en charge la page VPD des limites de bloc 0xb0 peuvent générer des journaux de code d'événement qui saturent le fichier vmkernel.log.

  • OMIVV s'appuie sur des informations de la propriété iDRAC hardware.systemInfo.otherIdentifyingInfo.ServiceTag pour extraire le paramètre SerialNumber permettant d'identifier certains serveurs modulaires Dell. Une incompatibilité dans la propriété serviceTag peut empêcher cette intégration.

  • vSphere Virtual Volumes peut cesser de répondre en raison d'une boucle infinie qui charge les CPU à 100 %, si un fournisseur VASA perd les informations de liaison provenant de la base de données. Hostd peut également cesser de répondre. Un message d'erreur irrécupérable peut s'afficher.

  • Les métadonnées de vSphere Virtual Volumes peuvent être disponibles uniquement lorsqu'une machine virtuelle commence à s'exécuter. Par conséquent, le logiciel du fournisseur de baie de stockage peut échouer à appliquer des stratégies qui affectent la disposition optimale de volumes lors de l'utilisation régulière et après un basculement.

  • Si vous utilisez un fournisseur VASA, plusieurs appels de getTaskUpdate à des tâches annulées ou supprimées peuvent être visibles. Par conséquent, vous pouvez observer une consommation de bande passante VASA supérieure et un débordement du journal.

  • Des machines virtuelles avec une version matérielle 10 ou ultérieure, utilisant EFI et exécutant Windows Server 2016 sur des processeurs AMD, peuvent cesser de répondre lors du redémarrage. Ce problème ne se produit pas si une machine virtuelle utilise le BIOS, ou si la version matérielle est 11 ou ultérieure, ou si le système d'exploitation invité n'est pas Windows, ou encore si les processeurs sont Intel.

  • Si vous activez l'outil d'analyse réseau NetFlow pour échantillonner chaque paquet sur un groupe de ports vSphere Distributed Switch, en définissant le taux d'échantillonnage sur 0, la latence du réseau peut atteindre 1 000 ms au cas où les flux dépassent 1 million.

  • Les tickets obsolètes, qui ne sont pas supprimés avant que hostd génère un nouveau ticket, peuvent épuiser les inodes des disques de RAM. Par conséquent, certains hôtes ESXi peuvent cesser de répondre.

  • L'utilitaire de ligne de commande esxtop peut ne pas afficher une valeur à jour de la profondeur de file d'attente des périphériques si la profondeur de file d'attente du chemin du périphérique correspondant change.

  • La réinitialisation manuelle des alarmes de santé du matériel pour revenir à un état normal, en sélectionnant Réinitialiser sur vert après avoir cliqué avec le bouton droit sur le panneau encadré Alarmes peut ne pas fonctionner comme prévu. Les alarmes peuvent réapparaître après 90 secondes.

  • Auparavant, si un composant, comme un processeur ou un ventilateur était manquant dans un système vCenter Server, les capteurs de présence affichaient l'état Inconnu. Cependant, les capteurs de présence n'ont pas d'état de santé qui leur est associé.

  • Si vous configurez le répertoire /productLocker sur une banque de données VMFS partagée, lorsque vous migrez une machine virtuelle à l'aide de vSphere vMotion, VMware Tools dans la machine virtuelle peut afficher un état incorrect non pris en charge.

  • Pour des machines virtuelles volumineuses, une migration vSphere vMotion chiffrée peut échouer en raison d'un espace de segment de migration insuffisant.

  • Une machine virtuelle qui effectue des centaines d'opérations d'ajout ou de suppression de disques à chaud sans être mise hors tension ou migrée peut être arrêtée et devenir non valide. Cela affecte les solutions de sauvegarde, et la machine virtuelle de proxy de sauvegarde peut être arrêtée en raison de ce problème.

    Un contenu similaire au suivant peut s'afficher dans le journal hostd :

    2018-06-08T10:33:14.150Z info hostd[15A03B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datatore/path/to/proxyVM/proxyVM.vmx opID=5953cf5e-3-a90a user=vpxuser:ADMIN\admin] State Transition (VM_STATE_ON -> VM_STATE_RECONFIGURING) ...
2018-06-08T10:33:14.167Z error hostd[15640B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datastore/path/to/proxyVM/proxyVM.vmx opID=5953cf5e-3-a90a user=vpxuser:ADMIN\admin] Could not apply pre-reconfigure domain changes: Failed to add file policies to domain :171: world ID :0:Cannot allocate memory ...
2018-06-08T10:33:14.826Z info hostd[15640B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datastore/path/to/proxyVM/proxyVM.vmx opID=5953cf5e-3-a90a user=vpxuser:ADMIN\admin] State Transition (VM_STATE_RECONFIGURING -> VM_STATE_ON) ...
2018-06-08T10:35:53.120Z error hostd[15A44B70] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/datastore/path/to/proxyVM/proxyVM.vmx] Expected permission (3) for /vmfs/volumes/path/to/backupVM not found in domain 171

    Un contenu similaire au suivant peut s'afficher dans le journal vmkernel :

    2018-06-08T05:40:53.264Z cpu49:68763 opID=4c6a367c)World: 12235: VC opID 5953cf5e-3-a90a maps to vmkernel opID 4c6a367c
2018-06-08T05:40:53.264Z cpu49:68763 opID=4c6a367c)WARNING: Heap: 3534: Heap domainHeap-54 already at its maximum size. Cannot expand.

  • Des capteurs IPMI désactivés ou qui ne signalent aucune donnée peuvent générer de fausses alarmes de santé du matériel.

  • Lorsque vous activez IPFIX et que le trafic est intense avec différents flux, le signal de pulsation du système peut échouer à exclure le CPU d'IPFIX pendant un long moment et déclencher un écran de diagnostic violet.

  • Des performances médiocres des opérations de vSphere vMotion longue distance peuvent être observées à une latence élevée, telle que 100 ms et plus, avec des liaisons réseau haute vitesse, telles que 1 GbE et plus, en raison de la limite de mémoire tampon du socket codé en dur de 16 Mo.

  • Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'une condition de concurrence dans une requête par le protocole MLD (Multicast Listener Discovery) version 1 dans les environnements IPv6. Un message d'erreur semblable à celui-ci peut s'afficher :

    #PF Exception 14 in world 2098376:vmk0-rx-0 IP 0x41802e62abc1 addr 0x40
...
0x451a1b81b9d0:[0x41802e62abc1]mld_set_version@(tcpip4)#+0x161 stack: 0x430e0593c9e8
0x451a1b81ba20:[0x41802e62bb57]mld_input@(tcpip4)#+0x7fc stack: 0x30
0x451a1b81bb20:[0x41802e60d7f8]icmp6_input@(tcpip4)#+0xbe1 stack: 0x30
0x451a1b81bcf0:[0x41802e621d3b]ip6_input@(tcpip4)#+0x770 stack: 0x451a00000000

  • Lorsqu'un utilisateur crée et ajoute une carte réseau VMkernel dans la pile réseau vSphereProvisioning pour l'utiliser pour le trafic NFC, le démon qui gère les connexions NFC peut ne pas parvenir à nettoyer les anciennes connexions. Cela entraîne l'épuisement de la limite autorisée de processus. Par conséquent, l'hôte cesse de répondre et ne parvient pas à créer des processus pour les connexions SSH entrantes.

  • Une tentative pour créer des volumes VFFS en utilisant une licence vSphere standard peut échouer avec l'erreur Licence non disponible pour effectuer l'opération, car la fonctionnalité vSphere Flash Read Cache n'est pas couverte par cette édition. Ce problème est dû au fait que le système utilise des autorisations VMware vSphere Flash Read Cache pour vérifier si le provisionnement de VFFS est autorisé.

  • Dans un environnement partagé tel que les disques de mappage de périphérique brut (RDM), vous ne pouvez pas utiliser de verrous de multi-écriture pour des machines virtuelles sur plus de 8 hôtes ESXi. Si vous migrez une machine virtuelle sur un neuvième hôte, il peut échouer à se mettre sous tension avec le message d'erreur Impossible d'ouvrir xxxx.vmdk ou l'un des snapshots dont il dépend. (Trop d'utilisateurs). Ce correctif rend l'option de configuration avancée /VMFS3/GBLAllowMW visible. Vous pouvez activer ou désactiver manuellement les verrous de multi-écriture pour plus de 8 hôtes en utilisant la fonction de verrouillage basée sur la génération.

  • Des fournisseurs CIM tiers, par HPE et Stratus par exemple, peuvent démarrer normalement, mais peuvent manquer de certaines fonctionnalités attendues lors de l'utilisation d'applications externes.

  • Un hôte ESXi peut cesser de répondre si le signal de pulsation de banque de données s'arrête prématurément lors de la fermeture de VMFS. Par conséquent, le gestionnaire d'affinité ne peut pas quitter normalement.

  • Des systèmes de surveillance SNMP peuvent signaler des statistiques de mémoire sur les hôtes ESXi différentes des valeurs que les commandes free, top ou vmstat signalent.

  • Si la cible connectée à un hôte ESXi prend en charge le protocole ALUA implicite uniquement et possède seulement des chemins d'accès inactifs, l'hôte peut échouer avec un écran de diagnostic violet au moment de la détection du périphérique en raison d'une condition de concurrence. Une trace de débogage similaire à la suivante peut apparaître :

    SCSIGetMultipleDeviceCommands (vmkDevice=0x0, result=0x451a0fc1be98, maxCommands=1, pluginDone=<optimized out>) at bora/vmkernel/storage/device/scsi_device_io.c:2476
0x00004180171688bc in vmk_ScsiGetNextDeviceCommand (vmkDevice=0x0) at bora/vmkernel/storage/device/scsi_device_io.c:2735
0x0000418017d8026c in nmp_DeviceStartLoop (device=device@entry=0x43048fc37350) at bora/modules/vmkernel/nmp/nmp_core.c:732
0x0000418017d8045d in nmpDeviceStartFromTimer (data=..., data@entry=...) at bora/modules/vmkernel/nmp/nmp_core.c:807

  • L'état Conformité du cluster d'un cluster compatible vSAN peut apparaître comme Non conforme, car la vérification de conformité peut ne pas reconnaître les banques de données vSAN comme des banques de données partagées.

  • Des E/S peuvent échouer avec une erreur FCP_DATA_CNT_MISMATCH, qui se traduit en HOST_ERROR dans l'hôte ESXi et qui indique des erreurs de lien ou des commutateurs défectueux sur certains chemins d'accès du périphérique.

  • Dans une configuration d'ESXi avec plusieurs chemins d'accès aux LUN derrière des cibles SVC IBM, en cas de perte de connexion sur des chemins d'accès actifs et si, en même temps, les autres chemins d'accès connectés ne permettent pas de servir les E/S, l'hôte ESXi peut ne pas détecter cette condition comme APD, même si aucun chemin d'accès n'est disponible pour servir des E/S. Par conséquent, les E/S vers le périphérique ne sont pas en échec rapide.

  • Un ralentissement des performances du réseau des serveurs NUMA peut se produire pour les périphériques qui utilisent VMware NetQueue, en raison d'un seuil d'épinglage. Il survient lorsque les files d'attente Rx sont épinglées à un nœud NUMA en modifiant la valeur par défaut de la configuration avancée NetNetqNumaIOCpuPinThreshold.

  • Certains hôtes peuvent ne pas parvenir à démarrer après la mise à niveau vers vSAN 6.7 Update 1 à partir d'une version antérieure.  Ce problème se produit sur les serveurs compatibles NUMA dans un cluster vSAN avec 3, 4 ou 5 groupes de disques par hôte. L'hôte peut expirer lors de la création du dernier groupe de disques. 

  • vSAN crée des composants de l'attribut blk après avoir créé un groupe de disques. Si le composant de l'attribut blk est absent de l'API qui prend en charge la commande diskgroup rebuild, le message d'avertissement suivant peut s'afficher dans le journal vmkernel : Throttled: BlkAttr not ready for disk.

  • Lorsque tous les groupes de disques sont supprimés d'un cluster vSAN, vSphere Client affiche un avertissement similaire au suivant :
    Le cluster VMware vSAN du centre de données n'a pas de capacité 
    Après que vous désactivez vSAN sur le cluster, le message d'avertissement persiste.

  • Si vous annulez le mappage de LUN depuis un système de stockage EMC VPLEX, les hôtes ESXi peuvent cesser de répondre ou échouer avec un écran de diagnostic violet. Des entrées de journal semblables à celles-ci peuvent s'afficher :
    2018-01-26T18:53:28.002Z cpu6:33514)WARNING: iodm: vmk_IodmEvent:192: vmhba1: FRAME DROP event has been observed 400 times in the last one minute.
2018-01-26T18:53:37.271Z cpu24:33058)WARNING: Unable to deliver event to user-space.

  • Le pilote HBA d'un hôte ESXi peut se déconnecter à partir d'un système de stockage EMC VPLEX lorsque la charge d'E/S est importante et ne pas se reconnecter lorsque des chemins d'accès d'E/S sont disponibles.

  • Dans un cluster vSAN avec les contrôleurs HPE ProLiant Gen9 Smart Array, tels que P440 et P840, les voyants du localisateur peuvent ne pas être allumés sur le bon périphérique en panne.

  • Si vous annulez le mappage de LUN depuis un système de stockage EMC VPLEX, les hôtes ESXi peuvent cesser de répondre ou échouer avec un écran de diagnostic violet. Des entrées de journal semblables à celles-ci peuvent s'afficher :
    2018-01-26T18:53:28.002Z cpu6:33514)WARNING: iodm: vmk_IodmEvent:192: vmhba1: FRAME DROP event has been observed 400 times in the last one minute.
2018-01-26T18:53:37.271Z cpu24:33058)WARNING: Unable to deliver event to user-space.

  • Le pilote HBA d'un hôte ESXi peut se déconnecter à partir d'un système de stockage EMC VPLEX lorsque la charge d'E/S est importante et ne pas se reconnecter lorsque des chemins d'accès d'E/S sont disponibles.

  • ESXi 6.7 Update 1 active un plug-in LSU Microsemi Smart PQI (smartpqi) afin de prendre en charge les opérations de gestion des disques attachés sur le contrôleur HPE ProLiant Gen10 Smart Array.

  • ESXi 6.7 Update 1 vous permet d'exécuter les commandes ESXCLI de stockage suivantes pour activer le voyant d'état sur des disques SSD basés sur VMD Intel sans télécharger Intel CLI :

    • esxcli storage core device set -l locator -d
    • esxcli storage core device set -l error -d
    • esxcli storage core device set -l off -d. 
  • ESXi 6.7 Update 1 permet la prise en charge du pilote nfnic pour Cisco UCS Fibre Channel over Ethernet (FCoE).
  • ESXi 6.7 Update 1 ajoute la prise en charge de NGUID dans le pilote NVMe.
  • Un hôte ESXi et hostd peuvent cesser de répondre en raison d'un épuisement de mémoire causé par le plug-in de fonctionnement du disque lsi_mr3.
  • Le pilote Intel i40en natif dans ESXi peut ne pas fonctionner avec des cartes réseau de la série X722 dans des réseaux IPv6 et le service Wake-on-LAN peut échouer.
  • Des messages de journaux colorés Le périphérique 10fb ne prend pas en charge l'auto-négociation de contrôle de flux peuvent s'afficher en tant qu'alertes, mais il s'agit d'un message journal courant qui reflète l'état de la prise en charge du contrôle de flux de certaines cartes réseau. Sur certaines images OEM, ce journal peut s'afficher fréquemment, mais il n'indique aucun problème avec l'hôte ESXi.
  • Certains adaptateurs QLogic FastLinQ QL41xxx peuvent ne pas créer de fonctions virtuelles une fois que SR-IOV est activé sur l'adaptateur et que l'hôte est redémarré.
  • Dans de rares occasions, les cartes réseau utilisant le pilote ntg3, telles que les cartes Broadcom BCM5719 et 5720 GbE, peuvent cesser temporairement l'envoi de paquets après un échec de la tentative d'envoyer un paquet dépassant la taille limite. Le pilote ntg3, version 4.1.3.2 résout ce problème.

ESXi-6.7.0-20181001001s-standard

Nom du profil	ESXi-6.7.0-20181001001s-standard
Build	Pour plus d'informations sur la build, reportez-vous à la section Correctifs contenus dans cette version.
Fournisseur	VMware, Inc.
Date de publication	16 octobre 2018
Niveau d'acceptation	PartnerSupported
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB concernés	VMware_bootbank_vsanhealth_6.7.0-0.28.10176879 VMware_bootbank_vsan_6.7.0-0.28.10176879 VMware_bootbank_esx-base_6.7.0-0.28.10176879 VMware_bootbank_esx-ui_1.30.0-9946814 VMware_locker_tools-light_10.3.2.9925305-10176879
PR résolus	1804719, 2093433, 2099951, 2168471
Numéros CVE associés	S/O

• Ce correctif met à jour les problèmes suivants :

  • La bibliothèque ESXi userworld libxml2 est mise à jour vers la version 2.9.7.

  • Le démon NTP est mis à jour vers la version ntp-4.2.8p11.

  • La base de données SQLite est mise à jour vers la version 3.23.1.

  • La bibliothèque ESXi userworld libcurl a été mise à jour vers libcurl-7.59.0.

  • OpenSSH est mis à jour vers la version 7.7p1.

  • La bibliothèque ESXi userworld OpenSSL est mise à jour vers la version openssl-1.0.2o.

  • La bibliothèque tierce Python est mise à jour vers la version 3.5.5.

  • L'image ISO de Windows préalable à Vista pour VMware Tools n'est plus fournie avec ESXi. L'image ISO de Windows préalable à Vista est disponible au téléchargement pour les utilisateurs qui en ont besoin. Pour obtenir des informations sur le téléchargement, consultez la page Téléchargement de produits.

ESXi-6.7.0-20181001001s-no-tools

Nom du profil	ESXi-6.7.0-20181001001s-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	16 octobre 2018
Niveau d'acceptation	PartnerSupported
Matériel concerné	S.O.
Logiciels concernés	S.O.
VIB concernés	VMware_bootbank_vsanhealth_6.7.0-0.28.10176879 VMware_bootbank_vsan_6.7.0-0.28.10176879 VMware_bootbank_esx-base_6.7.0-0.28.10176879 VMware_bootbank_esx-ui_1.30.0-9946814
PR résolus	1804719, 2093433, 2099951, 2168471
Numéros CVE associés	S/O

• Ce correctif met à jour les problèmes suivants :

  • La bibliothèque ESXi userworld libxml2 est mise à jour vers la version 2.9.7.

  • Le démon NTP est mis à jour vers la version ntp-4.2.8p11.

  • La base de données SQLite est mise à jour vers la version 3.23.1.

  • La bibliothèque ESXi userworld libcurl a été mise à jour vers libcurl-7.59.0.

  • OpenSSH est mis à jour vers la version 7.7p1.

  • La bibliothèque ESXi userworld OpenSSL est mise à jour vers la version openssl-1.0.2o.

  • La bibliothèque tierce Python est mise à jour vers la version 3.5.5.

  • L'image ISO de Windows préalable à Vista pour VMware Tools n'est plus fournie avec ESXi. L'image ISO de Windows préalable à Vista est disponible au téléchargement pour les utilisateurs qui en ont besoin. Pour obtenir des informations sur le téléchargement, consultez la page Téléchargement de produits.

Problèmes connus

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

• ESXi670-201810201-UG
• Problèmes connus des versions antérieures

ESXi670-201810201-UG

• Après avoir effectué la mise à niveau d'un hôte vers ESXi 6.7 Update 1, si vous corrigez un profil d'hôte, les vérifications de conformité peuvent échouer si l'hôte est avec des périphériques NVMe, qui prennent en charge uniquement NGUID comme identifiant de périphérique

  Après avoir mis à niveau vers ESXi 6.7 Update 1 un hôte avec des périphériques NVMe, qui prennent en charge uniquement NGUID comme identifiant de périphérique, si vous essayez de corriger un profil d'hôte configuré pour la fonctionnalité Stateful Install, les vérifications de conformité peuvent échouer. Cela est dû au fait que l'identifiant de périphérique présenté par le pilote NVMe dans ESXi 6.7 Update 1 est NGUID lui-même, plutôt qu'un identifiant t10 généré par ESXi.

  Solution : Mettez à jour la configuration de profil d'hôte comme suit :

  1. Accédez au profil d'hôte.
  2. Cliquez sur Copier les paramètres depuis l'hôte.
  3. Sélectionnez l'hôte à partir duquel vous souhaitez copier les paramètres de configuration.
  4. Cliquez sur OK.
  5. Cliquez avec le bouton droit sur l'hôte et sélectionnez Profils d'hôte > Réinitialiser les personnalisations d'hôte.
• Panne de l'hôte lors de la conversion d'un hôte de données en hôte témoin

  Lorsque vous convertissez un cluster vSAN en cluster étendu, vous devez fournir un hôte témoin. Vous pouvez convertir un hôte de données en hôte témoin, mais vous devez utiliser le mode de maintenance avec migration des données complète pendant le processus. Si vous placez l'hôte en mode de maintenance, que vous activez l'option Assurer l'accessibilité, puis que vous configurez l'hôte en tant qu'hôte témoin, l'hôte peut échouer avec un écran de diagnostic violet.

  Solution : Supprimez le groupe de disques sur l'hôte témoin, puis recréez le groupe de disques.

• Les paquets en monodiffusion étiquetés depuis une fonction virtuelle (FV) ne peuvent pas arriver à leur fonction physique (FP) lorsque les groupes de ports connectés à la fonction virtuelle et la fonction physique sont définis sur VGT (Virtual Guest Tagging)

  Si vous configurez VGT en mode de jonction sur les groupes de ports de fonction virtuelle et de fonction physique, le trafic de monodiffusion ne peut pas passer entre la fonction virtuelle et la fonction physique.

  Solution : N'utilisez pas la fonction physique pour VGT lorsque ses fonctions virtuelles sont utilisées pour VGT. Lorsque vous devez utiliser VGT sur une fonction physique et une fonction virtuelle pour une raison quelconque, la fonction virtuelle et la fonction physique doivent être sur des cartes réseau physiques différentes.

• La liaison de carte réseau physique peut être perdue après un démarrage PXE

  Si la carte vmknic est connectée à un commutateur logique NSX-T avec la liaison de carte réseau physique configurée, la configuration peut être perdue après un démarrage PXE. Si un adaptateur iSCSI logiciel est configuré, une erreur de conformité d'hôte similaire à la suivante peut s'afficher : L'adaptateur iSCSI vmhba65 n'a pas la carte réseau vmkX configurée dans le profil.

  Solution : Configurez la liaison de carte réseau physique et l'adaptateur iSCSI logiciel manuellement après que l'hôte a démarré.

• L'adresse MAC du réseau de gestion vmk0 peut être supprimée lors de la correction d'un profil d'hôte

  La correction d'un profil d'hôte avec une interface VMkernel créée sur un commutateur logique VMware NSX-T peut supprimer vmk0 des hôtes ESXi. Ces profils d'hôte ne peuvent pas être utilisés dans un environnement NSX-T.

  Solution : Configurez les hôtes manuellement. 

• Le service SNMP échoue fréquemment après la mise à niveau vers ESXi 6.7

  Le service SNMP peut échouer fréquemment, à des intervalles aussi courts que 30 min, après une mise à niveau vers ESXi 6.7, si l'exécution du thread principal n'est pas terminée lorsqu'un thread enfant est appelé. Le service génère des vidages de mémoire snmpd-zdump. Si le service SNMP échoue, vous pouvez le redémarrer avec les commandes suivantes :

  esxcli system snmp set -e false et esxcli system snmp set -e true.

  Solution : aucune.

• Lors du rééquilibrage des disques, la quantité de données à déplacer affichées par le service de santé de vSAN ne correspond pas à la quantité affichée par RVC (Ruby vSphere Console)

  RVC effectue un calcul approximatif pour déterminer la quantité de données à déplacer lors du rééquilibrage des disques. La valeur affichée par le service de santé vSAN est plus précise. Lors du rééquilibrage des disques, consultez le service de santé de vSAN pour vérifier la quantité de données à déplacer.

  Solution : aucune.

• PR 2132792 : Un hôte avec au moins trois groupes de disques ne parvient pas à démarrer après la mise à niveau vers vSAN 6.7 Update 1

  Dans certains cas, un hôte peut ne pas parvenir à démarrer après la mise à niveau vers vSAN 6.7 Update 1 à partir d'une version antérieure. Cette condition rare se produit sur les serveurs compatibles NUMA dans un cluster vSAN avec 3, 4 ou 5 groupes de disques par hôte.

  Solution : si un hôte avec au moins trois groupes de disques ne parvient pas à démarrer pendant la mise à niveau vers vSAN 6.7 Update 1, modifiez la configuration d'ESXi sur chaque hôte comme suit :
  Exécutez les commandes suivantes sur chaque hôte vSAN :
  esxcfg-advcfg --set 0 /LSOM/blPLOGRecovCacheLines
auto-backup.sh

Problèmes connus des versions antérieures

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

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

• Problèmes d'installation, de mise à niveau et de migration
• Problèmes liés aux fonctionnalités de sécurité
• Problèmes de mise en réseau
• Problèmes de stockage
• Problèmes de sauvegarde et de restauration
• Problèmes de vCenter Server Appliance, vCenter Server, vSphere Web Client et vSphere Client
• Problèmes de gestion des machines virtuelles
• Problèmes de vSphere HA et Fault Tolerance
• Problèmes liés à Auto Deploy et Image Builder
• Problèmes divers

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

• L'installation ou la mise à niveau d'ESXi échoue en raison d'une corruption des serveurs HPE ProLiant - DL380/360 Gen 9

  Le problème survient sur les serveurs HPE ProLiant - DL380/360 Gen 9 dotés d'un contrôleur de stockage Smart Array P440ar.

  Solution : définissez le serveur en mode BIOS sur UEFI avant d'installer ou de mettre à niveau ESXi.

• Après la mise à niveau d'ESXi vers la version 6.7 et une restauration consécutive vers la version 6.5 ou une version antérieure, vous pouvez rencontrer des échecs renvoyant des messages d'erreur

  Des pannes et des messages d'erreur peuvent survenir lorsque vous effectuez l'une des actions suivantes sur votre hôte ESXi après une restauration vers la version 6.5 ou une version antérieure :

  • Installation de correctifs et de VIB sur l'hôte
    Message d'erreur : [DependencyError] VIB VMware_locker_tools-light nécessite esx-version > = 6.6.0
  • Installation ou mise à niveau VMware Tools sur des machines virtuelles
    Message d'erreur : Impossible d'installer VMware Tools.

  Après la restauration d'ESXi vers la version 6.7, le nouveau VIB tools-light ne revient pas à la version antérieure. En conséquence, le VIB devient incompatible avec l'hôte ESXi à l'origine de ces problèmes.

  Solution : effectuez les actions suivantes pour résoudre ce problème.

  SSH vers l'hôte et exécutez l'une de ces commandes :

  esxcli software vib install -v /path/to/tools-light.vib

  ou

  esxcli software vib install -d /path/to/depot/zip -n tools-light

  Où vib et zip disposent de la version d'ESXi en cours d'exécution.

  Remarque : pour les machines virtuelles sur lesquelles la nouvelle version de VMware Tools est déjà installée, vous n'avez pas besoin de restaurer VMware Tools lorsque l'hôte ESXi est restauré.

• Les caractères spéciaux barre oblique inverse (\) ou guillemet double (") utilisés dans les mots de passe entraînent l'échec de la vérification préalable de l'installation

  Si les caractères spéciaux barre oblique inverse (\) ou guillemets doubles (") sont utilisés dans des champs d'ESXi, de vCenter Single Sign-On ou de mot de passe du système d'exploitation pendant l'installation des modèles de vCenter Server Appliance, la vérification préalable de l'installation échoue et renvoie l'erreur suivante :

  Message d'erreur : com.vmware.vcsa.installer.template.cli_argument_validation: \Escape non valide : ligne ## colonne ## (car ###)

  Solution : si vous incluez les caractères spéciaux barre oblique inverse (\) ou guillemets doubles (") dans des mots de passe pour ESXi, des systèmes d'exploitation ou Single-Sign-On, les caractères spéciaux doivent être échappés. Par exemple, le mot de passe pass\word doit être échappés comme suit : pass\\word.

• Le programme d'installation de Windows vCenter Server 6.7 échoue lorsque des caractères non-ASCII sont présents dans le mot de passe

  Le programme d'installation de Windows vCenter Server 6.7 échoue lorsque le mot de passe de Single Sign-On contient des caractères non-ASCII pour les paramètres régionaux japonais, chinois, coréens et taïwanais.

  Solution : assurez-vous que le mot de passe Single Sign-On contient uniquement des caractères ASCII pour les paramètres régionaux chinois, japonais, coréen et taïwanais.

• Impossible de se connecter à l'interface de vSphere Appliance Management si le caractère deux-points (:) fait partie du mot de passe racine de vCenter Server

  Pendant l'installation de l'interface utilisateur de vCenter Server Appliance (page Configurer la machine virtuelle du dispositif de l'Étape 1), si vous incluez le caractère deux-points (:) au mot de passe racine de vCenter Server, la connexion à l'interface vSphere Appliance Management (https://vc_ip:5480) échoue et vous empêche d'ouvrir une session. Le mot de passe peut être accepté par la vérification de la règle de mot de passe lors de la configuration, mais la connexion échoue.

  Solution : n'utilisez pas le caractère deux-points (:) pour définir le mot de passe racine de vCenter Server dans l'interface utilisation de vCenter Server Appliance (Configurer la machine virtuelle du dispositif de l'Étape 1).

• L'installation de vCenter Server Appliance échoue lorsque le caractère barre oblique inverse (\) est inclus dans le mot de passe de vCenter Single Sign-On

  Lors de l'installation de l'interface utilisateur de vCenter Server Appliance (page Configuration de SSO de l'Étape 2), si vous incluez le caractère barre oblique inverse (\) au mot de passe de vCenter Single Sign-On, l'installation échoue et renvoie l'erreur : Échec de l'enregistrement du service d'analyse auprès du gestionnaire de composants. Le mot de passe peut être accepté par la vérification de la règle de mot de passe, mais l'installation échoue.

  Solution : n'utilisez pas le caractère barre oblique inverse (\) pour définir le mot de passe de vCenter Single Sign-On dans le programme d'installation de l'interface utilisateur de vCenter Server Appliance (page Configuration de SSO de l'Étape 2)

• L'installation d'ESXi basée sur un script échoue sur les serveurs HP ProLiant Gen 9 et renvoie une erreur 

  Lorsque vous effectuez une installation d'ESXi basée sur un script sur un serveur HP ProLiant Gen 9 dans les conditions suivantes : 

  • L'option Partition utilisateur intégrée est activée dans le BIOS. 
  • Vous utilisez plusieurs lecteurs USB lors de l'installation : un lecteur USB contenant le fichier ks.cfg et les autres lecteurs USB ne sont pas formatés et utilisables.

  L'installation échoue et renvoie le message d'erreur suivant : Partitions non initialisées.

  Solution :

  1. désactivez l'option Partition utilisateur intégrée dans le BIOS du serveur.
  2. Formatez le lecteur USB non formaté avec un système de fichiers ou déconnectez-le du serveur.
• La mise à niveau de Windows vCenter Server 6.0.x ou 6.5.x vers vCenter Server 6.7 échoue si vCenter Server contient des profils d'hôtes 5.5 dont les noms contiennent des caractères non-ASCII ou ASCII étendus

  Lorsqu'un serveur Windows vCenter Server 6.0.x ou 6.5.x source contient les profils d'hôte vCenter Server 5.5.x dont les noms comportent des caractères non-ASCII ou ASCII étendus, UpgradeRunner échoue à démarrer lors du processus de vérification préalable à la mise à niveau.

  Solution : Avant la mise à niveau de Windows vCenter Server 6.0.x ou 6.5.x vers vCenter Server 6.7, mettez à niveau l'hôte ESXi 5.5.x avec des profils d'hôte dont les noms ne comportent aucun caractère non-ASCII ou ASCII étendus vers ESXi 6.0.x ou 6.5.x, puis mettez à jour le profil d'hôte à partir de l'hôte mis à niveau en cliquant sur Copier les paramètres à partir des hôtes.

• Vous ne pouvez pas exécuter la commande camregister avec l'option -x si le mot de passe de vCenter Single Sign-On contient des caractères non-ASCII

  Lorsque vous exécutez la commande camregister avec l'option de fichier -x, par exemple pour enregistrer vSphere Authentication Proxy, le processus échoue et renvoie un message d'erreur d'accès refusé lorsque le mot de passe de vCenter Single Sign-On contient des caractères non-ASCII.

  Solution : configurez le mot de passe de vCenter Single Sign-On uniquement avec des caractères ASCII, ou utilisez l'option de mot de passe –p lorsque vous exécutez la commande camregister pour entrer le mot de passe de vCenter Single Sign-On contenant des caractères non-ASCII.

• L'interpréteur de commande Bash et la connexion SSH sont désactivés après la mise à niveau vers vCenter Server 6.7

  Après la mise à niveau vers vCenter Server 6.7, vous ne pouvez pas accéder à vCenter Server Appliance à l'aide de l'interpréteur de commandes Bash ou d'une connexion SSH.

  Solution :

  1. après avoir correctement effectué la mise à niveau vers vCenter Server 6.7, connectez-vous à l'interface de gestion de vCenter Server Appliance. Dans un navigateur Web, accédez à : https://adresse_ip_dispositif_ou_nom complet: 5480
  2. Connectez-vous en tant qu'utilisateur racine.
     Le mot de passe racine par défaut est le mot de passe défini lors du déploiement de vCenter Server Appliance.
  3. Cliquez sur Accéder, puis sur Modifier.
  4. Modifier les paramètres d'accès de l'interpréteur de commandes Bash et de la connexion SSH. 
     Lors de l'activation de l'accès de l'interpréteur de commandes Bash à vCenter Server Appliance, entrez le nombre de minutes d'activation de l'accès.
  5. Cliquez sur OK pour enregistrer les paramètres.
• La migration du nœud de gestion se bloque si vCenter Server pour Windows 6.0 est installé sur Windows Server 2008 R2 sans activer précédemment Transport Layer Security 1.2

  Ce problème se produit si vous effectuez la migration de vCenter Server pour Windows 6.0 à l'aide d'un Platform Services Controller externe (topologie MxN) sur Windows Server 2008 R2. Après la migration du Platform Services Controller (PSC) externe, lorsque vous exécutez l'Assistant Migration sur le nœud de gestion celui-ci échoue, et signale qu'il ne peut pas récupérer la version du PSC. Cette erreur se produit, car Windows Server 2008 R2 ne prend pas en charge TLS 1.2 (Transport Layer Security) par défaut, qui est le protocole TLS par défaut de Platform Services Controller 6.7.

  Solution : activez TLS 1.2 pour Windows Server 2008 R2.1.

  1. Accédez à la clé de registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
  2. Créez un dossier et nommez-le TLS 1.2.
  3. Créez deux clés avec le dossier TLS 1.2, puis nommez les clés Client et Server.
  4. Sous la clé Client, créez deux valeurs DWORD (32 bits) et nommez-les DisabledByDefault et Enabled.
  5. Sous la clé Serveur, créez deux valeurs DWORD (32 bits) et nommez-les DisabledByDefault et Enabled.
  6. Assurez-vous que le champ Valeur est défini sur 0 et que la base est Hexadecimal for DisabledByDefault.
  7. Assurez-vous que la valeur du champ est définie sur 1 et que la base est Hexadecimal for Enabled.
  8. Redémarrez l'ordinateur Windows Server 2008 R2.

  Pour plus d'informations sur l'utilisation de TLS 1.2 avec Windows Server 2008 R2, reportez-vous à la documentation du fournisseur du système d'exploitation.

• vCenter Server contient des profils d'hôte dont la version est antérieure à la version 6.0 échoue lors de la mise à niveau vers la version 6.7

  vCenter Server 6.7 ne prend pas en charge les profils d'hôte dont la version est antérieure à la version 6.0. Pour effectuer la mise à niveau vers vCenter Server 6.7, vous devez tout d'abord mettre à niveau les profils d'hôte vers la version 6.0 ou versions ultérieures, si vous disposez de l'un des composants suivants :

  • Version du ou des hôtes ESXi : 5.1 ou 5.5
  • Version de vCenter Server : 6.0 ou 6.5
  • Version des profils d'hôte : 5.1 ou 5.5

  Solution : voir KB 52932

• Après la mise à niveau vers vCenter Server 6.7, toutes les modifications apportées au fichier /etc/ssh/sshd_config de l'hôte ESXi sont ignorées et le fichier est restauré dans la configuration par défaut de vCenter Server 6.7

  En raison de modifications apportées aux valeurs par défaut dans le fichier /etc/ssh/sshd_config, la mise à niveau de vCenter Server 6.7 remplace n'importe quelle modification manuelle apportée à ce fichier de configuration par la configuration par défaut. Cette modification était nécessaire, car certains paramètres précédents (par exemple, les chiffrements autorisés) ne sont plus compatibles avec le comportement actuel d'ESXi et empêchaient SSHD (démon SSH) de démarrer correctement.

  ATTENTION : la modification /etc/ssh/sshd_config n'est pas recommandée. SSHD est désactivé par défaut, et la méthode de modification de la configuration du système conseillée est via l'API VIM (y compris l'interface client de l'hôte ESXi) ou ESXCLI.

  Solution : si des modifications au fichier /etc/ssh/sshd_config sont nécessaires, vous pouvez les appliquer après avoir terminé la mise à niveau de vCenter Server 6.7. Le fichier de configuration par défaut contient désormais un numéro de version. Conservez ce numéro de version pour éviter de remplacer le fichier.

  Pour plus d'informations sur la modification du fichier /etc/ssh/sshd_config, consultez les articles suivants de la base de connaissances :

  • Pour plus d'informations sur l'activation par clé publique/privée d'authentification, reportez-vous à l'article 1002866 de la base de connaissances
  • Pour plus d'informations sur la modification de la configuration SSHD par défaut, reportez-vous à l'article 1020530 de la base de connaissances

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

• La sécurité basée sur la virtualisation (VBS) sur vSphere dans les systèmes d'exploitation invités Windows RS1, RS2 et RS3 nécessite qu'HyperV soit activé dans le système d'exploitation invité.

  La sécurité basée sur la virtualisation (VBS) sur vSphere dans les systèmes d'exploitation invités Windows RS1, RS2 et RS3 nécessite qu'HyperV soit activé dans le système d'exploitation invité.

  Solution : Activez la plate-forme Hyper-V sur Windows Server 2016. Dans le Gestionnaire de serveur, sous Serveur local, sélectionnez Gérer -> Assistant Ajouter des rôles et des fonctionnalités et sous Installation basée sur le rôle ou les fonctionnalités, sélectionnez Hyper-V dans le pool de serveurs, puis spécifiez les rôles de serveur. Choisissez les valeurs par défaut des rôles de serveur, des fonctionnalités, d'Hyper-V, des commutateurs virtuels, de la migration et des banques par défaut. Redémarrez l'hôte.

  Activer Hyper-V sur Windows 10 : Accédez au Panneau de configuration -> Programmes -> Activer ou désactiver des fonctionnalités Windows. Vérifiez que la plate-forme Hyper-V inclut l'hyperviseur Hyper-V et les services Hyper-V. Désactivez la case à cocher Outils de gestion Hyper-V. Cliquez sur OK. Redémarrez l'hôte.

Problèmes de mise en réseau

• Les indicateurs Hostprofile PeerDNS ne fonctionnent pas dans certains scénarios

  Si PeerDNS pour IPv4 est activé pour une vmknic sur un hôte sans état disposant d'un profil d'hôte associé, l'indicateur iPv6PeerDNS peut s'afficher avec un état différent dans le profil d'hôte extrait après le redémarrage de l'hôte.

  Solution : aucune.

• Lorsque vous mettez à niveau des vSphere Distributed Switches vers la version 6.6, vous pouvez rencontrer certains problèmes connus

  Pendant la mise à niveau, les machines virtuelles connectées peuvent rencontrer une perte de paquets pendant quelques secondes.

  Solution : si vous disposez de plusieurs vSphere Distributed Switches nécessitant une mise à niveau vers la version 6.6, effectuez la mise à niveau des commutateurs de manière séquentielle.

  Planifiez la mise à niveau des vSphere Distributed Switches pendant une période de maintenance, définissez le mode DRS sur manuel et n'appliquez pas les recommandations DRS pendant la durée de la mise à niveau.

  Pour en savoir plus sur les problèmes connus et leurs solutions, consultez KB 52621

• La mise sous tension de la machine virtuelle échoue lorsque Network I/O Control est activé et que toutes les liaisons montantes actives sont hors service

  La mise sous tension d'une machine virtuelle échoue lorsque Network I/O Control est activé et que les conditions suivantes sont réunies :

  • La machine virtuelle est connectée à un groupe de ports distribués sur un vSphere Distributed Switch
  • La machine virtuelle est configurée avec une réservation d'allocation de bande passante et l'adaptateur réseau (vNIC) de la machine virtuelle dispose d'une réservation configurée
  • La stratégie d'association du groupe de ports distribués est définie sur Basculement
  • Toutes les liaisons montantes actives sur le Distributed Switch sont hors service. Dans ce cas, vSphere DRS ne peut pas utiliser les liaisons montantes en veille et la mise sous tension de la machine virtuelle échoue.

  Solution : déplacez les adaptateurs en veille disponibles vers la liste des adaptateurs actifs dans la stratégie d'association du groupe de ports distribués.

• Le battement réseau sur une carte réseau utilisant le pilote qfle3f peut entraîner le blocage de l'hôte ESXi

  Le pilote qfle3f peut entraîner le blocage de l'hôte ESXi (PSOD) lorsque la carte réseau physique qui utilise le pilote qfle3f rencontre un battement d'état de lien fréquent toutes les 1 à 2 secondes.

  Solution : assurez-vous que le battement réseau ne se produit pas. Si l'intervalle de battement de l'état de lien ne dépasse pas 10 secondes, le pilote qfle3f n'entraîne pas le blocage d'ESXi. Pour plus d'informations, consultez KB 2008093.

• Les analyseurs de paquets échouent à reconnaître les paquets de trafic en miroir de ports ERSPAN Type III

  Si un mauvais bit est introduit de manière incorrecte dans l'en-tête de paquet ERSPAN Type III, tous les paquets ERSPAN Type III s'affichent comme corrompus dans les analyseurs de paquets.

  Solution : utilisez des paquets GRE ou ERSPAN Type II, si votre analyseur de trafic prend en charge ces types. 

• Les commandes esxcli de la configuration DNS ne sont pas prises en charge sur des piles TCP/IP autres que par défaut

  La configuration DNS des piles TCP/IP autres que par défaut n'est pas prise en charge. Les commandes telles que esxcli network ip dns server add -N vmotion -s 10.11.12.13 ne fonctionnent pas.

  Solution : n'utilisez pas les commandes esxcli de configuration DNS sur les piles TCP/IP autres que par défaut.

• Lors de l'application d'un profil d'hôte avec la passerelle IPv4 activée par défaut pour l'interface de la vmknic, la vérification de la conformité échoue et renvoie une erreur

  Lorsque vous appliquez un profil d'hôte avec la passerelle IPv4 activée par défaut pour l'interface de la vmknic, le paramètre est renseigné avec la valeur « 0.0.0.0 » qui ne correspond pas aux informations de l'hôte, ce qui entraîne l'erreur suivante :

  La configuration IPv4 de la passerelle de la vmknic ne correspond pas à la spécification

  Solution :

  1. Modifiez les paramètres du profil d'hôte.
  2. Accédez à Configuration de la mise en réseau > Carte réseau virtuelle de l'hôte ou Groupe de ports de l'hôte > (nom du vSphere Distributed Switch ou nom du groupe de ports) > Paramètres de l'adresse IP.
  3. Dans le menu déroulant Adaptateur réseau VMkernel de la passerelle par défaut (IPv4), sélectionnez l'option Choisir une passerelle IPv4 par défaut pour la vmknic et entrez la Passerelle IPv4 par défaut de la vmknic.
• Les cartes réseau de la série Intel Fortville ne peuvent pas recevoir de paquets d'encapsulation Geneve avec une longueur d'option supérieure à 255 octets

  Si vous configurez l'encapsulation Geneve avec une longueur d'option supérieure à 255 octets, les paquets ne sont pas reçus correctement sur les cartes réseau Intel Fortville X710, XL710 et XXV710.

  Solution : désactivez la troncation VLAN matérielle sur ces cartes réseau en exécutant la commande suivante :

  esxcli network nic software set --untagging=1 -n vmnicX.

• La session de mise en miroir RSPAN_SRC échoue après la migration

  Lorsqu'une machine virtuelle connectée à un port attribué à la session de mise en miroir RSPAN_SRC est migrée vers un autre hôte, la pNic requise sur le réseau de destination de l'hôte de destination est absente et la session de mise en miroir RSPAN_SRC ne parvient pas à se configurer sur le port. Cela entraîne l'échec de la connexion au port, mais le processus de migration vMotion réussit.

  Solution : pour restaurer l'échec de connexion au port, effectuez l'une des opérations suivantes :

  • Supprimez le port ayant échoué et ajoutez un nouveau port.
  • Désactivez le port et réactivez-le.

  La session de mise en miroir échoue à se configurer, mais la connexion de port est restaurée.

Problèmes de stockage

• Les banques de données NFS deviennent par intermittence en lecture seule

  Les banques de données d'un hôte NFS peuvent se retrouver en lecture seule lorsque de la vmknic NFS perd temporairement son adresse IP ou après un redémarrage d'hôtes sans état.

  Solution : vous pouvez démonter et remonter les banques de données pour rétablir la connectivité via la vmknic NFS. Vous pouvez également définir l'autorisation en écriture des banques de données NFS à l'adresse IP de la vmknic NFS et à l'adresse IP de la de gestion.

• Lorsque vous modifiez les stratégies de stockage d'une machine virtuelle, la sélection de la stratégie de stockage PMem avec hôte local échoue et renvoie une erreur 

  Dans la boîte de dialogue Modifier les stratégies de stockage de VM, si vous sélectionnez Stratégie de stockage PMem avec hôte local dans le menu déroulant et que vous cliquez sur OK, la tâche échoue et renvoie l'une de erreurs suivantes :

  Cette opération n'est pas prise en charge sur l'objet.

  ou

  Support de périphérique incompatible spécifié pour le périphérique 0 détaillé.

  Solution : vous ne pouvez pas appliquer la stratégie de stockage PMem avec hôte local à la page d'accueil de la machine virtuelle. Pour un disque virtuel, vous pouvez utiliser l'Assistant Migration pour migrer le disque virtuel et appliquer la stratégie de stockage PMem avec hôte local.

• Les banques de données peuvent apparaître comme inaccessibles après que les hôtes ESXi dans un cluster sont restaurés depuis un état de perte de périphérique permanente

  Ce problème peut se produire dans un environnement où les hôtes dans le cluster partagent un grand nombre de banque de données, par exemple, 512 à 1 000 banques de données.
  Une fois les hôtes dans le cluster restaurés à partir de la condition de perte de périphérique permanente, les banques de données sont montées avec succès au niveau des hôtes. Toutefois, dans vCenter Server, plusieurs banques de données peuvent continuer de s'afficher comme étant inaccessibles pour un certain nombre d'hôtes.

  Solution : sur les hôtes affichant des banques de données inaccessibles dans la vue de vCenter Server, effectuez l'opération Réanalyser le stockage depuis vCenter Server.

• La migration d'une machine virtuelle à partir d'une banque de données VMFS3 vers VMFS5 échoue dans un environnement d'hôte ESXi 6.5 et 6.7 mixte

  Si vous disposez d'un environnement d'hôte mixte, vous ne pouvez pas migrer une machine virtuelle à partir d'une banque de données VMFS3 connectée à un hôte ESXi 6.5 vers une banque de données VMFS5 sur un hôte ESXi 6.7.

  Solution : mettez à niveau la banque de données VMFS3 vers VMFS5 pour pouvoir migrer la machine virtuelle vers l'hôte ESXi 6.7.

• Le message d'avertissement concernant une banque de données VMFS3 reste inchangé après la mise à niveau de la banque de données VMFS3 à l'aide de l'interface de ligne de commande

  Généralement, vous utilisez l'interface de ligne de commande pour mettre à niveau la banque de données VMFS3 qui a échoué à se mettre à niveau pendant une mise à niveau d'ESXi. La banque de données VMFS3 peut échouer à se mettre à niveau en raison de plusieurs raisons, notamment les suivantes :

  • Aucun espace n'est disponible sur la banque de données VMFS3.
  • L'une des extensions de la banque de données étendue est hors ligne.

  Après que vous corrigez la raison de l'échec et mettez à niveau la banque de données VMFS3 vers VMFS5 à l'aide de l'interface de ligne de commande, l'hôte continue à détecter la banque de données VMFS3 et signale l'erreur suivante :

  Volumes VMFS (ver. 3) obsolètes détectés. La mise à niveau de ces volumes vers VMFS (ver5) est obligatoire pour une disponibilité continue sur l'hôte vSphere 6.7.

  Solution : Pour supprimer le message d'erreur, redémarrez hostd à l'aide de la commande /etc/init.d/hostd restart ou redémarrez l'hôte.

• Le pilote ESXi natif Mellanox ConnectX-4/ConnectX-5 peut présenter une dégradation de ses performances lorsque sa fonctionnalité DRSS (Default Queue Receive Side Scaling) par défaut est activée

  La technologie RSS (Receive Side Scaling) répartit le trafic réseau entrant entre plusieurs files d'attente basées sur le matériel, autorisant le traitement du trafic entrant par plusieurs CPU. En mode DRSS (Default Queue Receive Side Scaling), l'intégralité du périphérique est en mode RSS. Le pilote présente une seule file d'attente logique au système d'exploitation et est soutenu par plusieurs files d'attente de matériel.

  Le pilote natif nmlx5_core des cartes Mellanox ConnectX-4 et ConnectX-5 active la fonctionnalité DRSS par défaut. Bien que la fonctionnalité DRSS permette d'améliorer les performances de nombreuses charges de travail, elle peut entraîner une éventuelle dégradation des performances de certaines charges de travail avec plusieurs machines virtuelles et avec plusieurs vCPU.

  Solution : si une dégradation significative des performances est observée, vous pouvez désactiver la fonctionnalité DRSS.

  1. Exécutez la commande esxcli system module parameters set -m nmlx5_core -p DRSS=0 RSS=0.
  2. Redémarrez l'hôte.
• Le nom de la banque de données ne s'extrait pas dans le paramètre du fichier de vidage mémoire dans le profil d'hôte

  Lorsque vous extrayez un profil d'hôte, le champ Nom de la banque de données est vide dans le paramètre du fichier de vidage mémoire du profil d'hôte. Ce problème se produit lors de l'utilisation de la commande esxcli pour définir le vidage mémoire.

  Solution :

  1. Extrayez un profil d'hôte depuis un hôte ESXi.
  2. Modifiez les paramètres de profil d'hôte et accédez à Paramètres généraux du système > Configuration du vidage mémoire > Fichier de vidage mémoire.
  3. Sélectionnez Créer le fichier de vidage mémoire avec une option de banque de données et de taille explicite et entrez le nom de la banque de données à l'emplacement dans lequel vous voulez que le fichier de vidage mémoire réside.
• Les adaptateurs FCoE logiciels natifs configurés sur un hôte ESXi peuvent disparaître au redémarrage de l'hôte

  Après que vous activez avec succès l'adaptateur FCoE logiciel natif (vmhba) pris en charge par le pilote vmkfcoe et redémarrez l'hôte, l'adaptateur peut disparaître de la liste des adaptateurs. Cela peut se produire lorsque vous utilisez des cartes réseau convergé Cavium QLogic 57810 ou QLogic 57840 prises en charge par le pilote qfle3.

  Solution : pour récupérer l'adaptateur vmkfcoe, procédez comme suit :

  1. Exécutez la commande de la liste d'adaptateurs de base de stockage esxcli pour vous assurer que l'adaptateur est manquant dans la liste.
  2. Vérifiez la configuration du vSwitch sur la vmnic associée à l'adaptateur FCoE manquant.
  3. Exécutez la commande suivante pour détecter le vmhba FCoE :
     • Dans une configuration d'infrastructure :
       #esxcli fcoe nic discover -n vmnic_number
     • Dans une configuration VN2VN :
       #esxcli fcoe nic discover -n vmnic_number
• Les tentatives de création d'une banque de données VMFS sur un hôte ESXi 6.7 peuvent échouer dans certains environnements FCoE logiciels

  Vos tentatives de création de la banque de données VMFS échouent si vous utilisez la configuration suivante :

  • Adaptateurs FCoE logiciels natifs configurés sur un hôte ESXi 6.7.
  • Cartes réseau convergé Cavium QLogic 57810 ou 57840.
  • Commutateur FCoE Cisco connecté directement à un port FCoE sur une baie de stockage de la sérié Dell EMC VNX5300 ou VNX5700.

  Solution : aucune.

  Sinon, vous pouvez passer à la configuration de bout en bout suivante :
  Hôte ESXi > Commutateur FCoE Cisco > Commutateur FC > Baie de stockage de la série DELL EMC VNX5300 et VNX5700.

Problèmes de sauvegarde et de restauration

• Dans Explorateur Windows, certaines sauvegardes avec des caractères unicode sont affichées autrement que dans les navigateurs et les chemins de fichiers système

  Certaines sauvegardes contenant des caractères unicode s'affichent différemment dans le dossier du système de fichiers de l'Explorateur Windows que dans les navigateurs et les chemins de fichiers système.

  Solution : à l'aide de http, https ou ftp, vous pouvez parcourir les sauvegardes avec votre navigateur Web plutôt que d'accéder aux emplacements des dossier de stockage via l'Explorateur Windows.

Problèmes de vCenter Server Appliance, vCenter Server, vSphere Web Client et vSphere Client

• Le paramètre du mode de synchronisation de l'heure n'est pas conservé lors de la mise à niveau vCenter Server Appliance

  Si la synchronisation de l'heure NTP est désactivée sur un dispositif vCenter Server Appliance source, et que vous effectuez une mise à niveau vers vCenter Server Appliance 6.7, une fois la mise à niveau réussie, la synchronisation de l'heure NTP sera activée sur le dispositif récemment mis à niveau.

  Solution :

  1. après avoir correctement effectué la mise à niveau vers vCenter Server Appliance 6.7, connectez-vous à l'interface de gestion de vCenter Server Appliance en tant que racine.

     Le mot de passe racine par défaut est le mot de passe défini lors du déploiement de vCenter Server Appliance.

      https://IP_or_FQDN_of_appliance:5480

  2. Dans l'interface de gestion de vCenter Server Appliance, cliquez sur Heure.
  3. Dans le volet Synchronisation de l'heure, cliquez sur Modifier.
  4. Dans le menu déroulant Mode, sélectionnez Désactivé.

     Le dispositif vCenter Server Appliance 6.7 récemment mis à niveau n'utilisera plus la synchronisation de l'heure NTP et utilisera à la place les paramètres de fuseau horaire du système.

• La connexion à vSphere Web Client avec l'authentification de session Windows échoue sur les navigateurs Firefox de version 54 ou versions ultérieures

  Si vous utilisez la version 54 ou versions ultérieures de Firefox pour vous connecter à vSphere Web Client et que vous utilisez votre session Windows pour l'authentification, le plug-in VMware Enhanced Authentication peut échouer pour renseigner votre nom d'utilisateur et à vous connecter.

  Solution : si vous utilisez l'authentification de session Windows pour vous connecter à vSphere Web Client, utilisez l'un des navigateurs suivants : Internet Explorer, Chrome ou Firefox de version 53 et versions antérieures.

• Les notifications d'alarme de santé matérielle de vCenter ne se déclenchent pas dans certaines situations

  Lorsque plusieurs capteurs de la même catégorie sur un hôte ESXi sont déclenchés à un intervalle inférieur à cinq minutes, les interruptions ne sont pas reçues et les notifications par e-mail ne sont pas envoyées.

  Solution : aucune. Vous pouvez vérifier la section des capteurs matériels pour les alertes.

• Lorsque vous utilisez l'option de synchronisation de l'heure du programme d'installation VCSA, vous devez connecter l'ESX cible au serveur NTP dans le paramètre Date et heure depuis la gestion d'ESX

  Si vous souhaitez sélectionner l'option Synchronisation de l'heure sur le serveur NTP dans Programme d'installation VCSA -> Étape 2 -> Configuration du dispositif -> Synchronisation de l'heure (serveur ESX/NTP), l'ESX cible doit déjà être connecté au serveur NTP dans le paramètre Date et heure de la gestion d'ESX, sinon, la sélection de l'option échouera lors de l'installation.

  Solution :

  1. Définissez l'option Synchronisation de l'heure dans Étape 2 -> Configuration du dispositif sur Synchroniser sur ESX
  2. Définissez l'option Synchronisation de l'heure dans Étape 2 -> Configuration du dispositif sur Synchroniser sur les serveurs NTP, assurez-vous que ESX et VC sont définis pour se connecter aux serveurs NTP.
• Lorsque vous surveillez la santé de Windows vCenter Server, un message d'erreur s'affiche

  Le service de santé n'est pas disponible pour Windows vCenter Server. Si vous sélectionnez vCenter Server et que vous cliquez sur Surveiller > Santé, un message d'erreur s'affiche :

  Impossible d'interroger les informations de santé de vSAN. Vérifiez les journaux de vSphere Client pour obtenir des informations détaillées.

  Ce problème peut survenir après la mise à niveau de Windows vCenter Server à partir de la version 6.0 Update 1 ou de la version 6.0 Update 2 vers la version 6.7. Vous pouvez ignorer ce message.

  Solution : aucune. Les utilisateurs peuvent accéder aux informations de santé de vSAN via vCenter Server Appliance.

• Les alarmes de santé du matériel vCenter ne fonctionnent pas avec des versions antérieures d'ESXi

  Si ESXi 6.5 Update 1 ou une version antérieure est ajoutée à vCenter 6.7, les alarmes de santé du matériel connexes ne seront pas générées en cas d'événements matériels tels que des températures de CPU élevées, des pannes de ventilateur et des variations de tension.

  Solution : aucune.

• vCenter Server cesse de fonctionner dans certains cas lorsque vous utilisez vmodl pour modifier ou étendre un disque

  Lorsque vous configurez un disque de machine virtuelle dans un cluster de stockage sur lequel DRS est activé à l'aide du vmodl le plus récent, vCenter Server cesse de fonctionner. Une solution précédente utilisant un vmodl de version antérieure n'est plus fonctionnelle et provoque également l'arrêt de vCenter Server.

  Solution : aucune.

• La migration de vCenter Server pour Windows vers vCenter Server Appliance échoue et renvoie une erreur

  Lorsque vous migrez vCenter Server pour Windows 6.0.x ou 6.5.x vers vCenter Server Appliance 6.7, la migration peut échouer pendant la phase d'exportation de données et renvoyer l'erreur suivante : Le dossier zip compressé est non valide ou corrompu.

  Solution : vous devez compresser le dossier d'exportation de données manuellement et procédez comme suit :

  1. Dans le système source, créez une variable d'environnement MA_INTERACTIVE_MODE.
  2. Accédez à Ordinateur > Propriétés > Paramètres système avancés > Variables d'environnement > Variables système > Nouveau.
  3. Entrez « MA_INTERACTIVE_MODE » comme nom de la variable avec la valeur 0 ou 1.
  4. Démarrez l'Assistant Migration VMware et fournissez votre mot de passe.
  5. Démarrer la Migration à partir de la machine client. La migration s'interrompt et la console de l'Assistant Migration affiche le message suivant : Pour continuer la migration, créez le fichier export.zip manuellement depuis les données d'exportation (incluez le dossier d'exportation).
  6. REMARQUE : n'appuyez sur aucune touche, ni aucun onglet de la console de l'Assistant Migration.
  7. Accédez au dossier %appdata%\vmware\migration-assistant.
  8. Supprimer le fichier export.zip créé par l'Assistant Migration.
  9. Pour continuer la migration, créez manuellement le fichier export.zip à partir du dossier d'exportation.
  10. Revenez à la console de l'Assistant Migration. Saisissez Y, puis appuyez sur Entrée.
• Différence entre le numéro de build de l'interface VAMI et celui de vSphere Client

  Dans vSphere 6.7, l'onglet Résumé de l'interface VAMI affiche la build ISO des produits vCenter Server et vCenter Server Appliance. L'onglet Résumé de vSphere Client affiche la build de vCenter, qui est un composant de ce dernier.

  Solution : aucune.

• vCenter Server Appliance 6.7 affiche un message d'erreur dans la section Mises à jour disponibles de l'interface de gestion (VAMI) de vCenter Server Appliance

  La section Mises à jour disponibles de l'interface de gestion (VAMI) de vCenter Server Appliance affiche le message d'erreur suivant :

  Vérifiez l'URL et réessayez.

  Ce message est généré lorsque vCenter Server Appliance recherche un correctif ou une mise à jour, mais ne les trouve pas. Aucune fonctionnalité n'est affectée par ce problème. Ce problème sera résolu avec la version du premier correctif de vSphere 6.7.

  Solution : aucune. Aucune fonctionnalité n'est affectée par ce problème.

Problèmes de gestion des machines virtuelles

• Le nom de la machine virtuelle dans l'inventaire s'affiche sous son nom de chemin d'accès

  Ce problème peut se produire lorsqu'une banque de données sur laquelle réside la machine virtuelle passe à l'état Tous chemins hors service et devient inaccessible. Lorsque l'hostd charge ou recharge l'état de la machine virtuelle, il ne parvient pas à lire le nom de celle-ci et renvoie son chemin d'accès à la place. Par exemple, /vmfs/volumes/123456xxxxxxcc/cs-00.111.222.333.

  Solution : après la résolution du problème de stockage, la machine virtuelle se recharge et son nom s'affiche à nouveau.

• Vous devez sélectionner le niveau de sécurité de plate-forme « Démarrage sécurisé » lors de l'activation de VBS dans un système d'exploitation invité sur les systèmes AMD

  Sur les systèmes AMD, les machines virtuelles vSphere ne fournissent pas de vIOMMU. Puisqu'une vIOMMU est requise pour la protection DMA, les utilisateurs AMD ne peuvent pas sélectionner « Démarrage sécurisé et protection DMA » dans l'éditeur de stratégie de groupe Windows lorsqu'ils « activent la virtualisation basée sur la sécurité ». Au lieu de cela, sélectionnez « Démarrage sécurisé ». Si vous sélectionnez la mauvaise option, cela entraîne la désactivation en mode silencieux des services VBS par Windows.

  Solution : sélectionnez le niveau de sécurité de plate-forme « Démarrage sécurisé » dans un système d'exploitation invité sur les systèmes AMD.

• Vous ne pouvez pas ajouter à chaud de mémoire et de CPU aux machines virtuelles Windows lorsque la sécurité basée sur la virtualisation (VBS) est activée dans Windows

  La sécurité basée sur la virtualisation (VBS) est une nouvelle fonctionnalité introduite dans Windows 10 et Windows Server 2016. vSphere prend en charge l'exécution de Windows avec la fonctionnalité VBS activée à partir de la version vSphere 6.7. Toutefois, l'ajout à chaud de mémoire et de CPU ne fonctionne pas pour les machines virtuelles Windows lorsque la sécurité basée sur la virtualisation (VBS) est activée.

  Solution : mettez la machine virtuelle hors tension, modifiez les paramètres de la CPU ou de la mémoire, et mettez la machine virtuelle sous tension.

• L'arborescence de snapshot d'une machine virtuelle de clone lié peut s'avérer incomplète après une récupération réseau vSAN suite à une panne

  Une panne de réseau vSAN peut affecter l'accessibilité des objets vSAN et des machines virtuelles. Après une récupération réseau, les objets vSAN retrouvent leur accessibilité. Le service d'hostd recharge l'état de la machine virtuelle à partir du stockage pour récupérer les machines virtuelles. Toutefois, pour une machine virtuelle de clone lié, hostd peut ne pas détecter que l'espace de noms de la machine virtuelle parent a récupéré son accessibilité. Cela a pour résultat que la machine virtuelle reste dans un état inaccessible et que les informations du snapshot de machine virtuelle ne s'affichent pas dans vCenter Server.

  Solution : annulez l'enregistrement de la machine virtuelle, puis enregistrez-la de nouveau pour forcer hostd à recharger l'état de la machine virtuelle. Les informations du snapshot seront chargées à partir du stockage.

• Un dispositif virtuel OVF ne parvient pas à démarrer dans vSphere Client

  vSphere Client ne prend pas en charge la sélection des extensions vService dans l'Assistant Déployer le modèle OVF. Par conséquent, si un dispositif virtuel OVF utilise des extensions vService et que vous utilisez vSphere Client pour déployer le fichier OVF, le déploiement réussit, mais le dispositif virtuel échoue à démarrer.

  Solution : utilisez vSphere Web Client pour déployer les dispositifs virtuels OVF qui utilisent des extensions vService. 

Problèmes de vSphere HA et Fault Tolerance

• Lorsque vous configurez Proactive HA en mode manuel/mixte dans la build vSphere 6.7 RC, vous êtes invité deux fois à appliquer les recommandations DRS    

  Lorsque vous configurez Proactive HA en mode manuel/mixte dans la build vSphere 6.7 RC et qu'une mise à jour de santé rouge est envoyée à partir du plug-in du fournisseur Proactive HA, vous êtes invité deux fois à appliquer les recommandations sous Cluster -> Surveiller -> vSphere DRS -> Recommandations. La première invite consiste à passer l'hôte en mode de maintenance. La seconde invite consiste à migrer toutes les machines virtuelles sur un hôte entrant en mode de maintenance. Dans vSphere 6.5, ces deux étapes sont présentées comme une recommandation unique pour passer en mode de maintenance, qui répertorie toutes les machines virtuelles sont à migrer.

  Solution : cela n'a aucun impact sur les workflows ou les résultats. Vous devez appliquer les recommandations deux fois. Si vous utilisez des scripts automatisés, vous devez modifier les scripts afin d'y inclure l'étape supplémentaire.

• Interaction de la mise à niveau d'importation différée lorsque VCHA n'est pas configuré

  La fonctionnalité VCHA est disponible dans le cadre de la version 6.5. À compter de la version 6.5, un cluster VCHA ne peut pas être mis à niveau tout en préservant la configuration de VCHA. L'approche recommandée pour la mise à niveau consiste d'abord à supprimer la configuration de VCHA via vSphere Client ou en appelant une API de destruction de VCHA. En conséquence, pour le workflow de mise à niveau de l'importation différée sans configuration de VCHA, il n'existe aucune interaction avec VCHA.

  Lorsque l'importation en différé est en cours, ne configurez pas de nouvelle configuration de VCHA. La configuration de VCHA requiert le clonage de la machine virtuelle active en tant que machine virtuelle témoin/passive. Suite à une importation en différé en cours, la quantité de données à cloner est importante et peut entraîner des problèmes de performances.

  Solution : aucune.

Problèmes avec Auto Deploy et Image Builder

• Le redémarrage d'un hôte sans état ESXi réinitialise la valeur numRxQueue de l'hôte

  Lorsqu'un hôte ESXi provisionné avec vSphere Auto Deploy redémarre, il perd la valeur numRxQueue définie précédemment. La fonctionnalité Profils d'hôte ne prend pas en charge l'enregistrement de la valeur numRxQueue après le redémarrage de l'hôte.

  Solution : Après le redémarrage de l'hôte sans état ESXi :

  1. Supprimez la vmknic de l'hôte.
  2. Créez une vmknic sur l'hôte avec la valeur numRxQueue prévue.
• Après la mise en cache sur un lecteur, si le serveur est en mode UEFI, un démarrage à partir du cache n'aboutit pas, sauf si vous sélectionnez explicitement le périphérique à partir duquel démarrer le gestionnaire de démarrage UEFI

  En cas de mise en cache sans état, une fois que l'image ESXi est mise en cache sur un lecteur cible 512n, 512e, USB ou 4Kn, le démarrage d'ESXi sans état depuis autodeploy peut échouer lors d'un redémarrage système. Cela se produit si le service autodeploy ne fonctionne pas.

  Le système tente de rechercher l'image ESXi mise en cache sur le disque, la suivante dans l'ordre de démarrage. Si l'image mise en cache d'ESXi est trouvée, l'hôte est démarré à partir de celle-ci. Dans le BIOS hérité, cette fonctionnalité fonctionne sans rencontrer de problèmes. Cependant, en mode UEFI du BIOS, le périphérique suivant avec l'image mise en cache peut être introuvable. En conséquence, l'hôte ne peut pas démarrer à partir de l'image, même si celle-ci est présente sur le disque.

  Solution : lors du redémarrage du système, si le service autodeploy ne fonctionne pas, sélectionnez manuellement le disque avec l'image mise en cache depuis le gestionnaire de démarrage UEFI.

• Un délai de démarrage d'hôte ESXi sans état peut prendre 20 minutes (ou plus)

  Le démarrage d'un hôte ESXi sans état avec 1 000 banques de données configurées peut nécessiter de 20 minutes (ou plus).

  Solution : aucune.

Problèmes divers

• ESXi peut échouer lors d'un redémarrage avec des machines virtuelles en cours d'exécution sur les LUN iSCSI réclamés par le pilote qfle3i

  ESXi peut échouer lors d'un redémarrage avec des machines virtuelles en cours d'exécution sur les LUN iSCSI réclamés par le pilote qfle3i si vous tentez de redémarrer le serveur avec des machines virtuelles dans l'état d'E/S en cours d'exécution.

  Solution : commencez par mettre les machines virtuelles hors tension, puis redémarrez l'hôte ESXi.

• Les déchargements de matériel sans état VXLAN ne sont pas pris en charge avec le trafic TCP du système d'exploitation invité sur IPv6 sur les cartes UCS VIC 13xx

  Vous pouvez rencontrer des problèmes avec le trafic TCP encapsulé VXLAN sur IPv6 sur les cartes Cisco UCS VIC 13xx configurées pour utiliser la fonctionnalité de déchargement de matériel sans état VXLAN. Pour les déploiements VXLAN impliquant le trafic TCP du système d'exploitation invité sur IPV6, les paquets TCP soumis à TSO ne sont pas traités correctement par les cartes Cisco UCS VIC 13xx, ce qui entraîne une interruption du trafic. Les déchargements sans état ne sont pas effectués correctement. Du côté du protocole TCP, cela peut entraîner des totaux contrôle de paquets incorrects signalés à la pile logicielle d'ESXi, avec pour résultat un traitement incorrect du protocole TCP dans le système d'exploitation invité.

  Solution : pour résoudre ce problème, désactivez la fonctionnalité de déchargement sans état VXLAN sur les cartes Cisco UCS VIC 13xx pour le trafic TCP encapsulé VXLAN sur IPV6. Pour désactiver la fonctionnalité de déchargement sans état VXLAN dans le gestionnaire UCS, désactivez le champ LAN extensible virtuel dans la stratégie de la carte Ethernet. Pour désactiver la fonctionnalité de déchargement sans état VXLAN dans le CIMC d'un serveur UCS de la série C de Cisco, décochez le champ Activer VXLAN dans la section Propriétés de la vNIC des interfaces Ethernet.

• Répertorier un nombre important de volumes VMFS non résolus à l'aide de l'API QueryUnresolvedVmfsVolume de traitement par lots peut s'avérer long

  ESXi fournit l'API QueryUnresolvedVmfsVolume de traitement par lots afin que vous puissiez interroger et répertorier des volumes VMFS ou des snapshots de LUN non résolus. Vous pouvez ensuite utiliser d'autres API de traitement par lots pour effectuer des opérations, telles que signer à nouveau des volumes VMFS non résolus spécifiques. Par défaut, lorsque l'API QueryUnresolvedVmfsVolume est appelée sur un hôte, le système effectue un contrôle de réactivité du système de fichiers supplémentaire pour tous les volumes non résolus détectés.  Le contrôle de réactivité effectué détecte si le LUN spécifié est monté sur d'autres hôtes, si un signal de pulsation VMFS actif est en cours ou si un système de fichiers est actif. Cette opération prend du temps et nécessite au moins 16 secondes par LUN. Par conséquent, lorsque votre environnement se compose d'un grand nombre de LUN de snapshot, l'opération d'interrogation et d'établissement de liste peut prendre un certain temps.

  Solution : pour réduire la durée de l'opération d'interrogation, vous pouvez désactiver le contrôle de réactivité du système de fichiers. 

  1. Connectez-vous à votre hôte en tant que racine.
  2. Ouvrez le fichier de configuration d'hostd à l'aide d'un éditeur de texte. Le fichier de configuration se trouve dans /etc/vmware/hostd/config.xml sous le nœud plug-ins/hostsvc/stockage.
  3. Ajoutez le paramètre checkLiveFSUnresolvedVolume et définissez sa valeur sur FALSE. Utilisez la syntaxe suivante :

     <checkLiveFSUnresolvedVolume>FALSE</checkLiveFSUnresolvedVolume>

  Sinon, vous pouvez définir l'option avancée ESXi VMFS.UnresolvedVolumeLiveCheck sur FALSE dans vSphere Client.

• La vérification de la conformité échoue et renvoie une erreur pour l'option UserVars.ESXiVPsDisabledProtocols lorsqu'un hôte ESXi mis à niveau vers la version 6.7 est attaché à un profil d'hôte avec la version 6.0

  Le problème se produit lorsque vous effectuez les actions suivantes :

  1. Extraire un profil d'hôte depuis un hôte ESXi avec la version 6.0.
  2. Mettre à niveau l'hôte ESXi vers la version 6.7.
  3. L'hôte s'affiche comme non conforme pour l'option UserVars.ESXiVPsDisabledProtocols, même après la correction.

  Solution : 

  • extrayez un nouveau profil d'hôte de l'hôte ESXi mis à niveau et attachez l'hôte au profil.
  • Mettez à niveau le profil d'hôte à l'aide des paramètres de copie de l'hôte depuis l'hôte ESXi mis à niveau.
• Après la mise à niveau vers ESXi 6.7, les charges de travail de mise en réseau sur les cartes réseau Intel 10GbE entraînent une utilisation de CPU supérieure

  Si vous exécutez certains types de charges de travail de mise en réseau sur un hôte ESXi 6.7 mis à niveau, vous pouvez constater que l'utilisation de la CPU augmente dans les conditions suivantes :

  • Les cartes réseau de l'hôte ESXi proviennent des gammes Intel 82599EB ou X540
  • La charge de travail implique plusieurs machines virtuelles qui s'exécutent simultanément, et chaque machine virtuelle est configurée avec plusieurs vCPU
  • Avant la mise à niveau vers ESXi 6.7, le pilote ixgbe de VMKLinux a été utilisé

  Solution : restaurez pilote ixgbe de VMKLinux hérité :

  1. Connectez-vous à l'hôte ESXi et exécutez la commande suivante :
     # esxcli system module set -e false -m ixgben
  2. Redémarrez l'hôte.

  Remarque : le pilote ixgbe de VMKLinux fourni hérité version 3.7.x ne prend pas en charge les cartes réseau Intel X550. Utilisez le pilote asynchrone ixgbe de VMKLinux version 4.x avec les cartes réseau Intel X550.

• Impossible d'annuler la mise en attente des correctifs lorsque vous utilisez un Platform Services Controller externe

  Si vous corrigez un Platform Services Controller externe (topologie MxN) à l'aide de l'interface de gestion de VMware Appliance avec des correctifs mis en attente dans un référentiel de mise à jour, et que vous tentez ensuite d'annuler la mise en attente des correctifs, le message d'erreur suivant s'affiche : Erreur lors de l'appel de méthode [Errno 2] Aucun fichier ou répertoire de ce type : '/storage/core/software-update/stage' 

  Solution :

  1. accédez à l'interpréteur de commande du dispositif et connectez-vous en tant qu'utilisateur disposant du rôle de super administrateur.
  2. exécutez la commande software-packages unstage pour annuler la mise en attente des correctifs transférés. Tous les répertoires et tous les fichiers générés par le processus de transfert sont supprimés.
  3. Actualisez l'interface de gestion de VMware Appliance, qui signale maintenant les correctifs comme étant supprimés.
• L'installation initiale d'un VIB CIM DELL peut ne pas répondre

  Après l'installation d'un VIB CIM tiers, celle-ci peut ne pas répondre.

  Solution : pour résoudre ce problème, entrez les deux commandes suivantes pour redémarrer sfcbd :

  1. esxcli system wbem set --enable false
  2. esxcli system wbem set --enable true

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