check-circle-line exclamation-circle-line close-line

Notes de mise à jour de VMware ESXi 6.0 Update 3a

ESXi 6.0 Update 3 | 11 juillet 2017 | Build ISO 5572656

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

  • Cette version d'ESXi 6.0 Update 3a résout divers problèmes documentés dans la section Problèmes résolus.

Versions antérieures d'ESXi 6.0

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

Internationalisation

VMware ESXi 6.0 est disponible dans les langues suivantes :

  • Anglais
  • Français
  • Allemand
  • Japonais
  • Coréen
  • Chinois simplifié
  • Espagnol
  • Chinois traditionnel

Les composants de VMware vSphere 6.0, notamment vCenter Server, ESXi, vSphere Web Client et vSphere Client n'acceptent pas la saisie de caractères non-ASCII.

Compatibilité

Compatibilité des versions d'ESXi, de vCenter Server et de vSphere Web Client

La page Matrice d'interopérabilité des produits VMware fournit des informations sur la compatibilité des versions actuelles et précédentes des composants VMware vSphere, notamment ESXi, VMware vCenter Server, vSphere Web Client et les produits VMware en option. Pour plus d'informations sur les agents de gestion et de sauvegarde pris en charge, consultez également la Matrice d'interopérabilité des produits VMware avant d'installer ESXi ou vCenter Server.

vSphere Web Client est modularisé avec vCenter Server. Vous pouvez installer vSphere Client depuis le menu d'exécution automatique de VMware vCenter qui fait partie du fichier ISO des modules.

Compatibilité matérielle pour ESXi

Pour afficher la liste des processeurs, périphériques de stockage, baies SAN et périphériques E/S compatibles avec vSphere 6.0, consultez les informations relatives à ESXi 6.0 dans le Guide de compatibilité VMware.

Compatibilité des périphériques pour ESXi

Pour déterminer les périphériques compatibles avec ESXi 6.0, consultez les informations relatives à ESXi 6.0 dans le Guide de compatibilité VMware.

Certains périphériques sont déconseillés, car ils ne sont plus pris en charge par ESXi 6.0. Pendant le processus de mise à niveau, le pilote de périphérique est installé sur l'hôte ESXi 6.0. Si le pilote du périphérique peut encore fonctionner sur ESXi 6.0, ce dernier ne le prend pas en charge. Pour obtenir la liste des périphériques obsolètes et que ESXi 6.0 ne prend plus en charge, reportez-vous à l'article KB 2087970 de la base de connaissances.

Compatibilité du commutateur tiers pour ESXi

VMware prend désormais en charge Cisco Nexus 1000V avec vSphere 6.0. vSphere requiert au minimum la version 5.2(1)SV3(1.4) de NX-OS. Pour plus d'informations sur Cisco Nexus 1000V, reportez-vous aux Notes de mise à jour Cisco. Comme dans les versions précédentes de vSphere, le mode Cisco Nexus 1000V AVS n'est pas pris en charge.

Compatibilité des systèmes d'exploitation invités pour ESXi

Pour déterminer les systèmes d'exploitation invités compatibles avec vSphere 6.0, consultez les informations sur ESXi 6.0 dans le Guide de compatibilité de VMware.

 

Compatibilité des machines virtuelles pour ESXi

Les machines virtuelles compatibles avec ESX 3.x et versions ultérieures (version matérielle 4) sont prises en charge par ESXi 6.0. Les machines virtuelles compatibles avec ESX 2.x et versions ultérieures (version 3 du matériel) ne sont pas prises en charge. Pour utiliser ces machines virtuelles sur ESXi 6.0, effectuez une mise à niveau de la compatibilité de la machine virtuelle. Reportez-vous à la documentation Mise à niveau vSphere.

Installation et mises à niveau de cette version

Notes d'installation de cette version

Lisez la documentation Installation et configuration de vSphere qui présente des instructions sur l'installation et la configuration d'ESXi et de vCenter Server.

Bien que les installations soient simples, plusieurs étapes de configuration ultérieures sont indispensables. Lisez la documentation suivante :

Modèles de déploiement de vSphere 6.0 recommandés

VMware recommande uniquement deux modèles de déploiement :

  • vCenter Server avec Platform Services Controller intégré. Ce modèle est recommandé si une ou plusieurs instances de vCenter Server autonomes doivent être déployées dans un centre de données. La réplication entre ces modèles de vCenter Server avec Platform Services Controller intégré n'est pas recommandée.

  • vCenter Server avec Platform Services Controller externe. Ce modèle est recommandé uniquement si plusieurs instances de vCenter Server doivent être liées ou si vous souhaitez réduire l'encombrement du Platform Services Controller dans le centre de données. La réplication entre ces modèles de vCenter Server avec Platform Services Controller externe est prise en charge.

Lisez la documentation Installation et configuration de vSphere pour vous guider lors de l'installation et de la configuration de vCenter Server.

Lisez la documentation Mettre à jour la séquence pour vSphere 6.0 et ses produits VMware compatibles pour connaître la séquence correcte de mise à jour des composants vSphere.

Lisez également l'article KB 2108548 de la base de connaissances pour vous guider lors de l'installation et de la configuration de vCenter Server.

Informations sur le système d’exploitation hôte de vCenter

Lisez l'article KB 2091273 de la base de connaissances.

Sauvegarde et restauration de vCenter Server et des déploiements de vCenter Server Appliance qui utilisent un Platform Services Controller externe

Bien que les instructions de la documentation Installation et configuration de vSphere vous déconseillent de tenter de sauvegarder et de restaurer les déploiements de vCenter Server et de vCenter Server Appliance qui utilisent un Platform Services Controller externe, vous pouvez effectuer cette tâche en procédant comme indiqué dans l'article KB 2110294 de la base de connaissances.

Migration à partir de Platform Services Controller intégré vers Platform Services Controller externe

vCenter Server avec Platform Services Controller intégré ne peut pas être migré automatiquement vers vCenter Server avec Platform Services Controller externe. Les tests de cet utilitaire de migration ne sont pas terminés.

Avant d'installer vCenter Server, déterminez l'option de déploiement que vous souhaitez mettre en œuvre. Si plusieurs instances de vCenter Server sont requises pour la configuration de la réplication, déployez toujours vCenter avec Platform Services Controller externe.

Migration de solutions tierces

Pour plus d'informations sur la mise à niveau avec des personnalisations tierces, voir la documentation Mise à niveau de vSphere. Pour plus d'informations sur l'utilisation d'Image Builder pour créer un fichier ISO personnalisé, voir la documentation Installation et configuration de vSphere.

Mises à niveau et installations non autorisées pour les CPU non pris en charge

vSphere 6.0 prend uniquement en charge les processeurs disponibles depuis juin 2006 (troisième trimestre). Comparé à vSphere 5.x, vSphere 6.0 ne prend plus en charge les processeurs suivants :

  • AMD Opteron 12xx Series
  • AMD Opteron 22xx Series
  • AMD Operton 82xx Series

Pendant une installation ou une mise à niveau, le programme d'installation vérifie la compatibilité du CPU hôte avec vSphere 6.0. Si le matériel de votre hôte n'est pas compatible, un écran violet apparaît et affiche un message d'information pour signaler une incompatibilité, et le processus d'installation de vSphere 6.0 s'interrompt.

Notes de mise à niveau de cette version

Pour obtenir des instructions sur la mise à niveau de vCenter Server et des hôtes ESX/ESXi, consultez la documentation Mise à niveau de vSphere.

Composants en libre accès pour VMware vSphere 6.0

Les déclarations de copyright et les licences applicables aux composants logiciels en libre accès distribués dans vSphere 6.0 sont accessibles sur http://www.vmware.com. Vous devez vous connecter à votre compte My VMware. Puis, dans le menu Téléchargements, sélectionnez vSphere. Dans l'onglet Open Source, vous pouvez également télécharger les fichiers source pour une licence GPL, LGPL ou d'autres licences semblables pour lesquelles le code source ou les modifications du code source doivent être accessibles pour la dernière version disponible de vSphere.

Remarques concernant l'assistance produit

  • Base de données vCenter Server Oracle 11g et 12c comme base de données externe pour vCenter Server Appliance ont été désapprouvés dans la version vSphere 6.0. VMware continue à prendre en charge Oracle 11g et 12c comme base de données externe dans vSphere 6.0. VMware abandonnera la prise en charge d'Oracle 11g et 12c en tant que base de données externe pour vCenter Server Appliance dans une future version majeure.

  • vSphere Web Client. L'option Rapports de stockage de l'onglet Surveiller d'un objet n'est plus disponible dans vSphere 6.0 Web Client.

  • vSphere Client. L'onglet Vues de stockage n'est plus disponible dans vSphere 6.0 Web Client.

  • Site Recovery Manager : Les versions de Site Recovery Manager (SRM) antérieures à SRM 6.5 ne prennent pas en charge la personnalisation des IP ni les opérations d'exécution de scripts dans les invités pour les machines virtuelles qui sont placées sur ESXi 6.0 et qui utilisent VMware Tools version 10.1 et versions ultérieures. Pour plus d'informations, reportez-vous à la section Problèmes 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. Reportez-vous à la page Télécharger correctifs de VMware pour plus d'informations sur les bulletins individuels.

La version de correctifs ESXi600-Update03a contient les bulletins suivants :

La version de correctifs ESXi600-Update03a (Security-only build) contient les bulletins suivants :

La version de correctifs ESXi600-Update03a contient les profils d'image suivants :

La version de correctifs ESXi600-Update03a (Security-only build) contient les profils d'image suivants :

Problèmes résolus

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

Problèmes de sauvegarde
  • Lorsque vous ajoutez à chaud un disque virtuel existant ou nouveau à une machine virtuelle pour laquelle le suivi CBT (Changed Block Tracking) est activé et qui se trouve sur la banque de données VVOL, le système d’exploitation invité peut cesser de répondre

    Lorsque vous ajoutez à chaud un disque virtuel existant ou nouveau à une machine virtuelle pour laquelle le suivi CBT est activé et qui se trouve sur la banque de données VVOL, le système d’exploitation invité peut cesser de répondre jusqu'à ce que l’ajout à chaud soit terminé. L’absence de réponse de la machine virtuelle dépend de la taille du disque virtuel ajouté. La machine virtuelle reprend automatiquement lorsque l'ajout à chaud est terminé.

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

Problèmes CIM et API
  • L’agent SNMP signale les valeurs de compteur ifOutErrors et ifOutOctets de manière incorrecte

    L’agent Simple Network Management Protocol (SNMP) signale la même valeur de compteurs pour ifOutErrors et ifOutOctets, alors qu'elles doivent être différentes.

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

  • La pile IPMI ne répond pas après la réinitialisation à froid du BMC

    La pile de l'interface intelligente de gestion de plate-forme (IPMI, Intelligent Platform Management Interface) ne répond pas après la réinitialisation à froid du contrôleur de gestion de la carte de base (BMC, Baseboard Management Controller).

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

  • Les modules de mémoire DDR4 sont affichés comme inconnus sur la page d'état de santé du matériel dans vCenter Server

    Les modules de mémoire DDR4 des serveurs 13G de Dell sont affichés comme inconnus sur la page de l’état du matériel dans vCenter Server.

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

Problèmes de système d'exploitation invité
  • Échec d'un hôte avec écran de diagnostic violet affichant VMKPCIPassthru_SetupIntrProxy lorsque vous utilisez le relais PCI

    Lorsque vous utilisez le relais PCI avec des périphériques qui utilisent MSI-X et des noyaux Linux plus récents, un écran de diagnostic violet indiquant VMKPCIPassthru_SetupIntrProxy s’affiche. Ce problème provient du code dans PCIPassthruChangeIntrSettings.

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

Problèmes de profils d’hôte et Auto Deploy
  • Vous ne pouvez pas vous connecter à un hôte ESXi qui est ajouté à un domaine Active Directory avec Auto Deploy à l’aide de vSphere Authentication Proxy

    Après avoir utilisé vSphere Auto Deploy pour ajouter des hôtes à un domaine Active Directory à l’aide de vSphere Authentication Proxy, vous ne pouvez pas vous connecter à l’hôte avec les informations d’identification AD.

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

Problèmes d'internationalisation
  • Les caractères non latins peuvent s’afficher incorrectement dans les noms de profil de stockage de VM

    Les caractères UTF-8 ne sont pas gérés correctement avant leur transmission à un fournisseur VVol Vasa. Par conséquent, les profils de stockage de VM qui utilisent les caractères internationaux ne sont pas reconnus par le fournisseur Vasa ou alors sont traités ou affichés incorrectement par le fournisseur Vasa.

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

Problèmes divers
  • Le système d’exploitation invité peut sembler ralentir ou présenter un pic d'utilisation du CPU

    Votre système d’exploitation invité peut sembler ralentir ou présenter un pic d'utilisation du CPU qui disparaît une fois que vous désactivez ASLR dans le système d’exploitation invité et que vous effectuez une FSR.

    Les processus suivants peuvent provoquer ce comportement :
    1. Le cache de traduction se remplit de traductions pour de nombreuses instructions CPUID/RDTSC au niveau utilisateur rencontrées à différentes adresses virtuelles dans le système d’exploitation invité.
    2. Le moniteur de votre machine virtuelle utilise une fonction de hachage avec dispersion faible lors de la recherche de traductions.

    La désactivation d'ASLR résout le problème temporairement jusqu'à ce que vous mettiez à niveau l'hôte ESXi vers une version qui contient le correctif. Le problème est résolu dans cette version.

  • Échec d'un hôte ESXi avec un écran violet ou affichage d'un message d’avertissement lors de la destruction d’un segment vmkernel contigu avec une taille initiale allouée de 64 Mo ou plus

    Le calcul incorrect de capacité supplémentaire de mémoire entraîne l'échec d'un hôte ESXi avec un écran violet ou l'affichage d'un message d’avertissement au moment de décharger lors de la destruction d’un segment vmkernel contigu avec une taille initiale allouée de 64 Mo ou plus.

    Le message d'avertissement suivant s'affiche :

    Segment : 2781 : segment de mémoire non vide (<heapName>) détruit (valeur de <size>, devrait être <size>).

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

  • Vous pouvez observer des messages d’erreur de contention de verrouillage sur un fichier lunTimestamps.log dans les journaux hostd

    Pour mettre à jour l'horodatage de la dernière visualisation pour chaque LUN sur un hôte ESXi, le processus doit obtenir le verrouillage du fichier /etc/vmware/lunTimestamps.log. Le verrouillage est maintenu plus longtemps que nécessaire dans chaque processus. Si trop de processus de ce type essayent de mettre à jour le fichier /etc/vmware/lunTimestamps.log, ils peuvent entraîner une contention de verrouillage sur ce fichier. Si hostd est l'un des processus qui essaie d’acquérir le verrouillage, l’hôte ESXi peut se déconnecter de vCenter Server ou cesser de répondre, et produire des messages d’erreur de contention de verrouillage (dans le fichier lunTimestamps.log ) dans les journaux hostd. Vous pouvez obtenir un message d’erreur de type :

    Error interacting with configuration file /etc/vmware/lunTimestamps.log: Timeout while waiting for lock, /etc/vmware/lunTimestamps.log.LOCK, to be released. Another process has kept this file locked for more than 30 seconds. The process currently holding the lock is (). This is likely a temporary condition. Please try your operation again.

    Remarque :

    • nom_processus est le processus ou le service qui maintient le verrouillage de /etc/vmware/lunTimestamps.log. Par exemple, smartd, esxcfg-scsidevs, localcli, etc.
    • PID est l’ID de processus de ces services.

     

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

  • Une machine virtuelle peut se mettre hors tension automatiquement avec une erreur « MXUserAllocSerialNumber : trop de verrous »

    Lors du fonctionnement normal de la VM, les services de VMware Tools (version 9.10.0 et ultérieures) créent des connexions vSocket pour échanger des données avec l’hyperviseur. Lorsqu'un grand nombre de ces connexions sont effectuées, l’hyperviseur peut manquer de numéros de série de verrouillage et la machine virtuelle se met hors tension avec une erreur.

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

  • Engorgement des journaux système

    Chaque fois que le noyau API vmk_ScsiCmdGetVMUuid ne parvient pas à obtenir un UUID de VM valide, il imprime un message d’erreur de ce type dans les journaux système :

    2016-06-30T16:46:08.749Z cpu6:33528)WARNING: World: vm 0: 11020: vm not found

    Ce problème est résolu dans cette version par l'appel conditionnel de la fonction World_GetVcUuid qui a provoqué l'engorgement de l'API du noyau vmk_ScsiCmdGetVMUuid.

Problèmes de mise en réseau
  • Un hôte ESXi peut cesser de répondre lorsque vous le reconnectez à vCenter Server

    Si vous déconnectez votre hôte ESXi de vCenter Server et si certaines des machines virtuelles sur cet hôte utilisent un LAG, votre hôte ESXi peut cesser de répondre lorsque vous le reconnectez à vCenter Server après avoir recréé le même décalage sur vCenter Server et vous pouvez obtenir une erreur semblable à la suivante :
    0x439116e1aeb0:[0x418004878a9c]LACPScheduler@ # +0x3c stack: 0x417fcfa00040 0x439116e1aed0:[0x418003df5a26]Net_TeamScheduler@vmkernel#nover+0x7a stack: 0x43070000003c 0x439116e1af30:[0x4180044f5004]TeamES_Output@ # +0x410 stack: 0x4302c435d958 0x439116e1afb0:[0x4180044e27a7]EtherswitchPortDispatch@ # +0x633 stack: 0x0

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

  • Les statistiques réseau affichent un nombre anormal de paquets dans le diagramme de performances réseau de vCenter Server

    Le calcul du nombre de paquets réseau peut être géré par plusieurs CPU. Ce calcul peut présenter une erreur de calcul au niveau des statistiques réseau et afficher un nombre incorrect dans le diagramme de performances réseau.

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

  • Le démarrage par PXE des machines virtuelles configurées pour utiliser le microprogramme EFI échoue dans certains environnements DHCP

    Une machine virtuelle configurée pour utiliser le microprogramme EFI ne parvient pas à obtenir une adresse IP lors de toute tentative de démarrage par PXE si l'environnement DHCP répond par monodiffusion IP. Le microprogramme EFI n'était pas capable de recevoir une réponse DHCP envoyée par monodiffusion IP.

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

  • Toutes les machines virtuelles perdent leur connectivité en raison du manque de mémoire du segment de mémoire Еtherswitch

    Il existe une fuite de mémoire dans le segment de mémoire Еtherswitch présentant une taille comprise entre 32 et 63 octets. Lorsque le segment de mémoire est à court de mémoire, les machines virtuelles perdent la connexion.

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

  • L'hôte ESXi échoue avec un écran de diagnostic violet au niveau de DVFilter vMotion et signale une erreur « PCPU 25: no heartbeat (3/3 IPIs received) »

    Lorsque vous redémarrez l'hôte ESXi dans les conditions suivantes, l'hôte peut échouer avec un écran de diagnostic violet et une erreur PCPU xxx: no heartbeat.
     

    •  Vous utilisez vSphere Network Appliance (DVFilter) dans un environnement NSX
    •  Vous migrez une machine virtuelle avec vMotion sous le contrôle de DVFilter

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

  • Les machines virtuelles (VM) qui font partie de pools VDI (Virtual Desktop Infrastructure) reposant sur la technologie Instant Clone perdent la connexion aux services Guest Introspection

    Les machines virtuelles existantes qui utilisent Instant Clone, ainsi que celles créées avec ou sans Instant Clone, perdent la connexion au module hôte Guest Introspection. Par conséquent, les machines virtuelles ne sont pas protégées et aucune nouvelle configuration de Guest Introspection ne peut être transmise à l'hôte ESXi. Un avertissement « Guest introspection not ready » peut également apparaître dans l'interface utilisateur de vCenter Server.

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

  • Le journal VMkernel inclut un ou plusieurs avertissements « Couldn't enable keep alive »

    Ces avertissements se produisent lors de la communication de solutions VMware NSX et de partenaires via un socket VMCI (vsock). Le journal VMkernel ignore désormais ces avertissements répétés, car ils peuvent être ignorés sans risque.

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

  • Une alerte de noyau peut se produire en raison d'une perte de connectivité réseau pour une machine virtuelle ayant un pilote de vNIC e1000 ou e1000e

    Pour une machine virtuelle ayant un pilote de vNIC e1000 ou e1000e, lorsque le pilote e1000/e1000e indique à l'émulation vmkernel e1000/e1000e d'ignorer un descripteur (l'adresse et la longueur du descripteur de transmission sont égales à 0), une perte de connectivité peut survenir et la machine virtuelle peut passer à l'état d'alerte de noyau.

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

  • vSphere vMotion échoue lorsqu'un hôte ESXi est connecté à un vSphere Distributed Switch configuré avec le protocole LACP

    Si un hôte ESXi est connecté à un vSphere Distributed Switch configuré avec le protocole LACP et si le LAG comporte des liaisons montantes hors service lorsque vous essayez d'utiliser vSphere vMotion, un message d'avertissement semblable au suivant s'affiche : L'interface réseau actuellement connectée « Adaptateur réseau 1 » utilise un « DSwitchName » qui n'est pas accessible.

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

  • Un hôte ESXi peut devenir indisponible lors de l'arrêt

    Si vous utilisez un type d'adresse IPv6 sur un hôte ESXi, l'hôte peut devenir indisponible lors de l'arrêt

    Mettez à niveau votre hôte ESXi vers la version 6.0 Update 3a.

Problèmes de sécurité
  • Mise à jour de la bibliothèque Pixman

    La bibliothèque Pixman est mise à jour vers la version 0.35.1.

  • La pile Likewise sur ESXi n'est pas activée pour prendre en charge SMBv2

    Le contrôleur de domaine Windows 2012 prend en charge SMBv2, tandis que la pile Likewise sur ESXi prend uniquement en charge SMBv1.

    Avec cette version, la pile Likewise sur ESXi est activée pour la prise en charge de SMBv2.

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

  • Mise à jour de VMware Tools

    VMware Tools est mis à jour vers la version 10.1.5. Pour plus d'informations, reportez-vous à Notes de mise à jour de VMware Tools 10.1.5.

    VMware Tools 10.1.5 résout des problèmes de sécurité dans les composants Open Source.

  • Mise à jour d'OpenSSL

    Le module OpenSSL est mis à jour vers la version openssl-1.0.2k afin de résoudre CVE-2017-3731, CVE-2017-3730, CVE-2017-3732 et CVE-2016-7055.

  • Mise à jour de Python

    Python est mis à jour vers la version 2.7.13 afin de résoudre les problèmes CVE-2016-2183 et CVE-2016-1000110.

Problèmes de configuration de serveur
  • Le service vpxd se bloque et l'interface utilisateur de vSphere Web Client ne peut pas se connecter à vCenter Server ni mettre à jour ce dernier

    Dans certains cas, le chemin de profil pour l'objet VMODL n'est pas défini. Cette condition déclenche un problème de sérialisation lors de la validation du fichier de réponses dans le cadre de la configuration du réseau, ce qui provoque un incident du service vpxd.

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

  • Impossible de joindre un hôte ESXi 6.x à Active Directory via un profil d'hôte

    Lorsque vous essayez d'utiliser des profils d'hôte pour joindre un hôte ESXi 6.x à un domaine Active Directory, l'application se bloque ou échoue avec une erreur.

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

Problèmes de stockage
  • La commande vm-support est exécutée avec une erreur récupérable

    La commande vm-support utilise un script appelé smartinfo.sh pour collecter des données SMART pour chaque périphérique de stockage sur l'hôte ESXi. La commande vm-support impose un délai d'expiration de 20 secondes pour chaque commande qui collecte des données de support. Cependant, smartinfo.sh prend plus de 20 secondes, ce qui entraîne l'exécution de la commande vm-support avec l'erreur suivante : cmd /usr/lib/vmware/vm-support/bin/smartinfo.sh a expiré après 20 secondes en raison d'une absence de progression dans les 10 dernières secondes (0 octets lus).

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

  • hostd se bloque en raison de bibliothèques non initialisées

    Lorsque vous essayez de rajouter un hôte à vCenter Server, hostd peut se bloquer si IOFilter est activé pour l'hôte et si les machines virtuelles sur lesquelles Changed Block Tracking (CBT) est activé résident sur cet hôte. La bibliothèque de filtres utilise les bibliothèques d'interrogation et de travailleur. Lorsque la bibliothèque de filtres est initialisée avant les bibliothèques d'interrogation et de travailleur, elle ne peut pas fonctionner correctement et se bloque.

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

  • Un hôte ESXi peut cesser de répondre lorsqu'une machine virtuelle sur cet hôte est en cours d'exécution sur un snapshot SeSparse

    Après avoir créé un snapshot de machine virtuelle d'un format SEsparse, vous pouvez atteindre une condition de concurrence rare s'il existe des IOPS d'écriture significatives, mais variables dans le snapshot. Cette condition de concurrence peut empêcher l'hôte ESXi de répondre.

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

  • Les machines virtuelles qui utilisent le format de disque virtuel SEsparse peuvent cesser de répondre lors de l'exécution de charges de travail d'E/S spécifiques

    Les machines virtuelles avec des snapshots SEsparse peuvent cesser de répondre pendant les opérations d'E/S impliquant un type spécifique de charge de travail d'E/S dans plusieurs threads.

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

  • La récupération d'une erreur pendant une opération de modification du profil de stockage génère un ID de profil corrompu

    Si un fournisseur de VASA VVol renvoie une erreur pendant une opération de modification du profil de stockage, vSphere tente d'annuler l'opération, mais l'ID de profil est corrompu au cours du processus.

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

  • Latence de lecture/écriture incorrecte affichée dans vSphere Web Client pour les banques de données VVol

    La latence de lecture/écriture par hôte affichée pour les banques de données VVol dans vSphere Web Client est incorrecte.

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

  • Les opérations de profil d'hôte échouent dans un environnement Auto Deploy

    Les opérations de profil d'hôte telles que la vérification de conformité, la correction et le clonage du profil d'hôte échouent dans un environnement Auto Deploy.
    Les scénarios suivants sont observés :

    1. Au cours de la nouvelle installation d'hôtes ESXi à l'aide d'Auto Deploy
      • La vérification de conformité des profils d'hôte échoue avec un message semblable au suivant :
        L'hôte est indisponible pour contrôler la conformité.
      • La correction du profil d'hôte (appliquer des profils d'hôte) échoue avec l'erreur suivante :
        Échec de l'appel « HostProfileManager.GenerateConfigTaskList » pour l'objet « HostProfileManager » sur vCenter Server <vCenter_hostname>
    2. La modification de l'hôte de référence du profil d'hôte échoue avec l'erreur suivante :
      Échec de l'appel « HostProfileManager.CreateProfile » pour l'objet « HostProfileManager » sur vCenter Server <vCenter_hostname>.
    3. Le clonage du profil d'hôte échoue avec l'erreur suivante :
      Échec de l'appel « HostProfileManager.CreateProfile » pour l'objet « HostProfileManager » sur vCenter Server <vCenter_hostname>. Le profil ne dispose pas d'un hôte de référence associé

    Dans les fichiers journaux situés sous /var/log/syslog.log, les opérations ayant échoué s'affichent avec l'erreur suivante :
    Erreur : profileData à partir d'une instance de profil unique prise en charge dans VerifyMyProfilesPolicies.

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

  • Un hôte ESXi avec une machine virtuelle configurée avec VMware vFlash Read Cache (VFRC) peut échouer avec un écran violet

    Un hôte ESXi avec une machine virtuelle configurée avec VMware vFlash Read Cache (VFRC) peut échouer avec un écran violet lorsque le stockage principal devient lent ou inaccessible. Cet échec est dû à une erreur de verrouillage dans le code VFRC.

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

  • SESparse entraîne l'endommagement d'un système de fichiers du SE invité

    L'utilisation de SESparse pour la création de snapshots et le clonage de machines virtuelles peut entraîner l'endommagement d'un système de fichiers du système d'exploitation invité.

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

  • Une modification dynamique du paramètre de profondeur de file d'attente pour les périphériques entraîne un envoi massif de notifications d'événements à hostd

    Lorsque le contrôle d'E/S de stockage (SIOC) modifie le paramètre de profondeur de file d'attente maximale du LUN, une notification d'événement est envoyée à partir de l'architecture de stockage enfichable (PSA) à hostd. Dans les configurations où le paramètre de profondeur de file d'attente est modifié de manière dynamique, une charge de notifications d'événements est envoyée à hostd, ce qui provoque des problèmes de performances tels que des tâches vSphere lentes ou la déconnexion du service hostd de vCenter Server.

    Dans cette version, PSA n'envoie aucune notification d'événement à hostd.

  • Le nouveau calcul de la synthèse pour un disque Content Based Read Cache (CBRC) ne signale jamais un calcul du pourcentage d'achèvement, mais renvoie une erreur système

    Le filtre CBRC utilise le calcul sur 32 bits pour effectuer des calculs et renvoie un pourcentage d'achèvement pour chaque demande de nouveau calcul de synthèse. Pour les disques de grande capacité, le nombre de hachages est suffisant pour dépasser le calcul sur 32 bits, ce qui entraîne un pourcentage d'achèvement incorrect.

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

  • L'utilisateur doit configurer manuellement la règle SATP pour le modèle Pure Storage FlashArray

    Pour un périphérique Pure Storage FlashArray, l'utilisateur devra ajouter manuellement la règle SATP pour définir le SATP, le PSP et l'IOPS selon les exigences.

    Ce problème est résolu dans cette version et une nouvelle règle SATP est ajoutée à ESXi pour définir le SATP sur VMW_SATP_ALUA, le PSP sur VMW_PSP_RR et la valeur d'IOPS sur 1 pour tous les modèles Pure Storage FlashArray.

    Remarque : Dans le cas d'une installation ESXi sans état, si un ancien profil d'hôte est appliqué, il écrase les nouvelles règles après la mise à niveau.

  • Échec du démontage d'une banque de données

    Parfois, lorsque vous tentez de démonter une banque de données NFS à partir de vCenter Server, l'opération peut échouer avec l'erreur Échec du démontage d'une banque de données NFS - La banque de données comporte des fichiers ouverts, démontage impossible.

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

  • Lorsque vous utilisez Storage vMotion, l'UUID d'un disque virtuel peut changer

    Lorsque vous utilisez Storage vMotion sur un stockage vSphere Virtual Volumes, l'UUID d'un disque virtuel peut changer. Si l'UUID est modifié, le disque virtuel apparaît comme un disque nouveau et différent, car l'UUID identifie le disque virtuel. L'UUID est également visible dans le système d'exploitation invité et peut entraîner une identification erronée des lecteurs.

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

  • Des messages d'erreur du type « Impossible d'ouvrir le fichier » s'affichent dans vmkernel.log pendant le démarrage d'ESXi ou le montage du groupe de disques dans vSAN

    Des messages d'erreur du type « Impossible d'ouvrir le fichier » s'affichent dans le fichier vmkernel.log lorsqu'un hôte ESXi vSAN démarre ou pendant un montage manuel de groupe de disques dans vSAN.

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

  • Une machine virtuelle de clone lié avec son type de disque SESparse peut se bloquer en cas d'abandons d'E/S ou de paquets en raison d'un problème avec le pilote HBA, le contrôleur, le microprogramme, la connectivité ou la topologie de stockage

    Lorsque les opérations d'E/S se bloquent ou abandonnent au niveau du pilote HBA en raison d'un problème avec le pilote HBA, le contrôleur, le microprogramme, la connectivité ou la topologie de stockage, l'E/S bloquée n'est pas abandonnée, ce qui entraîne le blocage de la machine virtuelle.

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

  • Le système cesse de répondre et vous pouvez recevoir une erreur du type « Problème de suppression de blocs » dans le fichier vmkernel.log

    Lorsque les commandes unmap échouent, l'hôte ESXi peut cesser de répondre en raison d'une fuite de mémoire dans le chemin de la panne. Vous pouvez recevoir le message d'erreur suivant dans le fichier vmkernel.log : FSDisk: 300: Problème d'échec de la suppression de blocs [sync:0] et l'hôte cesse de répondre.

    Ce problème est résolu dans cette version en évitant la fuite de mémoire.

  • Si vous utilisez SEsparse et que vous activez l'opération de démappage, il se peut que le système de fichiers du système d'exploitation invité soit endommagé

    Si vous utilisez SEsparse et que vous activez l'opération de démappage pour créer des snapshots et des clones des machines virtuelles, une fois l'opération d'effacement (le démappage du stockage) terminée, il se peut que le système de fichiers du système d'exploitation invité soit endommagé. Le clone complet de la machine virtuelle s'effectue correctement.

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

  • La modification de la limite d'IOPS des disques virtuels avec le Changed Block Tracking (CBT) activé peut échouer

    Pour définir la stratégie de planification des E/S de stockage pour une machine virtuelle, vous pouvez configurer le débit d'E/S pour chaque disque de VM en modifiant la limite d'IOPS. Lorsque vous modifiez la limite d'IOPS et que le CBT est activé pour la machine virtuelle, l'opération échoue avec une erreur La modification du paramètre de planification a échoué. En raison de ce problème, les stratégies de planification de la machine virtuelle ne peuvent pas être modifiées. Le message d'erreur s'affiche dans le volet Tâches récentes de vSphere.

    Les erreurs suivantes apparaissent dans le fichier /var/log/vmkernel.log :

    2016-11-30T21:01:56.788Z cpu0:136101)VSCSI: 273: handle 8194(vscsi0:0):Input values: res=0 limit=-2 bw=-1 Shares=1000 2016-11-30T21:01:56.788Z cpu0:136101)ScsiSched: 2760: Invalid Bandwidth Cap Configuration 2016-11-30T21:01:56.788Z cpu0:136101)WARNING: VSCSI: 337: handle 8194(vscsi0:0):Failed to invert policy
     

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

  • Une tâche de création de snapshot ne peut pas être correctement annulée

    Lorsque vous tentez d'annuler une tâche de création de snapshot, mais que le fournisseur VASA ne réussit pas à annuler les opérations associées sous-jacentes sur un disque sauvegardé par VVoL, un snapshot du VVoL est créé et demeure jusqu'au nettoyage de la mémoire.

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

  • Une tâche de création de clone ne peut pas être correctement annulée

    Lorsque vous tentez d'annuler une tâche de création de clone, mais que le fournisseur VASA ne réussit pas à annuler les opérations associées sous-jacentes, vCenter Server crée un nouveau VVoL, copie toutes les données et signale que la création du clone a réussi.

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

Problèmes de matériel pris en charge
  • Les hôtes ESXi exécutant le correctif ESXi600-201611001 peuvent échouer avec un écran de diagnostic violet en raison d'interruptions non masquables (NMI, Non-Maskable-Interrupts) sur les serveurs HPE ProLiant Gen8

    Le correctif ESXi600-201611001 apporte une modification qui permet à ESXi de désactiver la fonctionnalité de remappage des interruptions d'Intel® IOMMU (également appelé VT-d). Sur les serveurs HPE ProLiant Gen8, la désactivation de cette fonctionnalité entraîne des erreurs PCI. Suite à ces erreurs, la plate-forme génère une interruption NMI qui provoque l'échec de l'hôte ESXi et l'affichage d'un écran de diagnostic violet.

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

Problèmes de mise à niveau et d'installation
  • Réintroduction du mot de passe nécessaire pour ouvrir une session sur un hôte ESXi via SSH

    Vous êtes invité à saisir votre mot de passe deux fois lors de la connexion à un hôte ESXi via SSH si l'hôte ESXi est mis à niveau de la version 5.5 vers la version 6.0 de vSphere alors qu'il fait partie d'un domaine.

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

Problèmes avec vCenter Server, vSphere Web Client et vSphere Client
  • Vous ne pouvez pas utiliser VMware Host Client dans Chrome 57

    Lorsque vous essayez de vous connecter à VMware Host Client à l’aide de Chrome 57, VMware Host Client signale immédiatement une erreur. L’erreur signalée est une erreur Angular Digest in progress.

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

Problèmes de gestion des machines virtuelles
  • Les fichiers de synthèse VMDK ne sont pas supprimés du dossier de la machine virtuelle lorsque vous supprimez cette machine virtuelle

    Lorsque vous créez un clone lié à partir d'un fichier de synthèse VMDK, vCenter Server marque le fichier de synthèse du disque pour indiquer qu'il ne peut pas être supprimé. Ainsi, lorsque vous supprimez la machine virtuelle, le fichier de synthèse VMDK n'est pas supprimé du dossier de machine virtuelle, car le paramètre ddb.deletable est défini sur False dans le fichier descripteur.

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

  • La machine virtuelle peut cesser de répondre

    Lorsque vous créez un snapshot d'une machine virtuelle, la machine virtuelle peut cesser de répondre.

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

  • La machine virtuelle peut cesser de répondre en raison d'une réduction de la quantité de mémoire active

    Si la quantité de mémoire active d'une machine virtuelle qui s'exécute sur un hôte ESXi passe en dessous de 1 % et chute à zéro, l'hôte peut réclamer de la mémoire, même s'il dispose de suffisamment de mémoire libre.

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

    1. Connectez-vous à vCenter Server via vSphere Web Client.
    2. Sélectionnez un hôte ESXi dans l'inventaire.
    3. Mettez toutes les machines virtuelles de l'hôte ESXi hors tension.
    4. Cliquez sur Paramètres.
    5. Sous l'en-tête Système, cliquez sur Paramètres système avancés.
    6. Recherchez le paramètre Mem.SampleActivePctMin.
    7. Cliquez sur Modifier.
    8. Remplacez la valeur existante par la valeur 1.
    9. Cliquez sur OK pour accepter les changements.
    10. Mettez les machines virtuelles sous tension.
  • Un hôte ESXi peut être déconnecté de vCenter Server

    En raison d'une fuite de mémoire, le processus hostd peut se bloquer et renvoyer l'erreur suivante : 

    Memory exceeds hard limit. Panic.

    Les journaux hostd signalent de nombreuses erreurs, comme par exemple Unable to build Durable Name.

    Ce type de fuite de mémoire entraîne la déconnexion de l'hôte de vCenter Server.

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

  • La machine virtuelle cesse de répondre pendant la consolidation du snapshot

    Pendant la consolidation du snapshot, il peut être nécessaire d'effectuer un calcul précis qui permettra de déterminer l'espace de stockage requis pour l'opération. Ce calcul précis peut entraîner l'interruption de la machine virtuelle, car il prend un certain temps.

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

  • La migration vMotion d'une machine virtuelle est interrompue pendant un temps, puis finit par échouer et par renvoyer une erreur de délai d'attente

    Si une machine virtuelle dispose d'un pilote (notamment d'un pilote graphique) ou d'une application qui utilise trop de mémoire, elle crée une page fixe dans la machine virtuelle. Lorsque la machine virtuelle est sur le point d'être migrée vers un autre hôte avec vMotion, le processus de migration est interrompu, puis finit par échouer en raison d'une mise en attente incorrecte des calculs d'entrée/sortie.

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

Problèmes de vSAN
  • L'affichage des valeurs de calcul bytsToSync dans VC et RVC peut être incorrect pour les objets RAID5/6

    Le calcul actuel des octets de resynchronisation surestime le trafic de resynchronisation complet pour les configurations RAID 5/6. Cela peut se produire lorsqu'une des situations suivantes se présente :

    • Le nœud est mis en mode de maintenance via le mode d'évacuation « Migration intégrale des données » ou « Assurer l'accessibilité ».
    • Un miroir complet est créé à partir d'un composant qui a été perdu suite à une panne du cluster.

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

  • Pour le signalement de problèmes d'espace, le système peut afficher un message d'erreur générique plutôt qu'un message spécifique

    Dans certains cas, le système peut afficher un message d'erreur générique plutôt qu'un message spécifique pour signaler des problèmes d'espace. Par exemple, lorsqu'un échec est dû à un manque d'espace disque, vous pouvez voir un message d'erreur comme « Échec de modification de la stratégie de stockage : 12 (Impossible d'allouer de la mémoire.) ».

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

  • Un hôte ESXi peut échouer avec un écran de diagnostic violet dans bora/modules/vmkernel/lsomcommon/ssdlog/ssdopslog.c:199

    Des conditions de concurrence se produisent entre plusieurs chemins de code internes LSOM. Une région est alors libérée deux fois dans le niveau de mise en cache, ce qui entraîne la création d'une arborescence des appels de procédure et l'apparition d'un message de panique du type suivant :

    PanicvPanicInt@vmkernel#nover+0x36b stack: 0x417ff6af0980, 0x4180368 2015-04-20T16:27:38.399Z cpu7:1000015002)0x439124d1a780:[0x4180368ad6b7]Panic_vPanic@vmkernel#nover+0x23 stack: 0x46a, 0x4180368d7bc1, 0x43a 2015-04-20T16:27:38.411Z cpu7:1000015002)0x439124d1a7a0:[0x4180368d7bc1]vmk_PanicWithModuleID@vmkernel#nover+0x41 stack: 0x439124d1a800, 0x4 2015-04-20T16:27:38.423Z cpu7:1000015002)0x439124d1a800:[0x418037cc6d46]SSDLOG_FreeLogEntry@LSOMCommon#1+0xb6e stack: 0x6, 0x4180368dd0f4, 0 2015-04-20T16:27:38.435Z cpu7:1000015002)0x439124d1a880:[0x418037d3c351]PLOGCommitDispatch@com.vmware.plog#0.0.0.1+0x849 stack: 0x46a7500, 0

    Les conditions de concurrence se produisent entre les workflows PLOG Relog, PLOG Probe et PLOG Decommission.

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

  • Quand la charge de travail d'E/S est importante, un processus vSAN peut occuper des cycles de CPU pour un long moment, ce qui entraîne un bref verrouillage du PCPU

    Lorsque la charge de travail d'E/S est importante, un processus vSAN peut occuper des cycles de CPU pour un long moment, ce qui entraîne un bref verrouillage du PCPU. Cela engendre une interruption non masquable et un engorgement au niveau des fichiers journaux vmkernel.

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

  • Un hôte ESXi pour lequel vSAN est activé peut échouer avec un écran PSOD (Purple Screen Of Death)

    Un hôte ESXi pour lequel vSAN est activé peut échouer avec un écran violet affichant la trace de débogage suivante :

    2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bd20:[0x418032a77f83]Panic_vPanic@vmkernel#nover+0x23 stack: 0x4313df6720ba, 0x418032a944 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bd40:[0x418032a944a9]vmk_PanicWithModuleID@vmkernel#nover+0x41 stack: 0x43911b29bda0, 0x4 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bda0:[0x41803387b46c]vs_space_mgmt_svc_start@com.vmware.virsto#0.0.0.1+0x414 stack: 0x100 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29be00:[0x41803384266d]Virsto_StartInstance@com.vmware.virsto#0.0.0.1+0x68d stack: 0x4312df 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bf00:[0x4180338f138f]LSOMMountHelper@com.vmware.lsom#0.0.0.1+0x19b stack: 0x43060d72b980, 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bf30:[0x418032a502c2]helpFunc@vmkernel#nover+0x4e6 stack: 0x0, 0x43060d6a60a0, 0x35, 0x0, 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bfd0:[0x418032c14c1e]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0, 0x0, 0x0, 0x0, 0

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

  • L'utilisation d'objtool sur un hôte témoin vSAN peut entraîner l'échec d'un hôte ESXi et l'affichage d'un écran violet

    Si vous utilisez objtool sur un hôte témoin, il effectue un appel ioctl qui entraîne un déréférencement du pointeur NULL dans l'hôte ESXi du témoin vSAN et le bloquage de l'hôte.

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

  • La désaffectation de disques sur lesquels sont activées la déduplication et la compression, et dont les commandes d'accès aux supports échouent, peut entraîner un échec et l'apparition d'un écran violet dans le nœud vSAN

    Pendant la désaffectation d'un groupe de disques vSAN sur lesquels sont activées la déduplication et la compression, les commandes d'accès de certains disques peuvent échouer. Ces pannes peuvent être vérifiées dans le journal vmkernel. Des messages semblables au suivant peuvent s'afficher :
    Partition: 914: Read of GPT header (hdrlba = 1) failed on "naa.55cd2e404c185332" : I/O error.
    Cela entraîne un échec de l'hôte vSAN au moment de la désaffectation.

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

  • Vous pouvez recevoir une fausse alarme concernant le contrôle de santé de vSAN

    L'interface utilisateur de santé de vSAN peut parfois signaler un état incorrect pour le contrôle de santé du réseau (par exemple, « Tous les hôtes d'une vmknic Virtual SAN configurée »), puis déclencher une fausse alarme vCenter Server.

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

  • Une machine virtuelle peut cesser de répondre ou un hôte peut se retrouver déconnecté de vCenter Server. Ceci s'accompagne d'un encombrement du journal (dans la version 6.0, mise à jour 2) ou d'un encombrement de la mémoire (dans la version 6.0, mise à jour 3)

    La suppression d'un composant vSAN dans un état non valide d'un cluster vSAN peut entraîner l'interruption d'une machine virtuelle ou la déconnexion d'un hôte de vCenter Server.

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

  • Un hôte ESXi peut échouer avec un écran violet

    Un hôte ESXi peut échouer avec un écran violet en raison d'une condition de concurrence entre le chemin de code de l'initialisation du client du gestionnaire d'objets distribués et celui de l'interface sysinfo VMkernel du gestionnaire d'objets distribués.

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

  • Un encombrement des SSD peut entraîner l'interruption de plusieurs machines virtuelles

    Selon la charge de travail et le nombre de machines virtuelles, l'état des groupes de disques de l'hôte peut passer à PDL (perte permanente de périphérique). Les groupes de disques n'admettent alors plus d'E/S, ce qui les rend inutilisables ; une intervention manuelle est requise pour pouvoir les réutiliser.
     

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

Problèmes connus

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

Problèmes d'installation
  • Il est possible que le suffixe DNS reste présent après modification de la configuration par défaut dans l'interface DCUI
    Il est possible que la configuration DNS par défaut et le suffixe DNS soient automatiquement attribués à un hôte ESXi lors de son premier démarrage s'il est déployé sur un réseau avec serveur DHCP. Si vous tentez de modifier le suffixe DNS, l'ancien suffixe n'est pas supprimé de l'interface DCUI ; à la place, le nouveau suffixe lui est apposé.

    Solution : Lorsque vous configurez le nom d'hôte DNS du format OVF témoin, définissez le nom de domaine complet (FQDN) dans son intégralité dans le champ Nom d'hôte DNS, de manière à lui ajouter le suffixe DNS correct. Vous pouvez alors supprimer les suffixes DNS indésirables dans le champ Suffixe DNS personnalisé.

  • Les processus utilisateur du service VMware Tools peuvent ne pas fonctionner sur le SE Linux après l'installation du dernier module de VMware Tools
    Sur le système d'exploitation Linux, vous pouvez rencontrer des problèmes d'installation ou de mise à niveau de VMware Tools ou les procédures utilisateur du service VMware Tools (vmtoolsd) peuvent ne pas s'exécuter après l'installation du module VMware Tools le plus récent. Le problème se produit si votre version de glibc est antérieure à la version 2.5, comme SLES10sp4.

    Solution : Mettez à niveau Linux glibc vers la version 2.5 ou une version ultérieure.

Problèmes de mise à niveauConsultez également la section Problèmes d'installation des notes de mise à jour. De nombreux problèmes d'installation peuvent également avoir des répercussions sur votre processus de mise à niveau.
  • Les tentatives de mise à niveau d'ESXi 6.x vers la version 6.0 Update 2 et versions ultérieures avec la commande esxcli software vib update échouent
    Les tentatives de mise à niveau d'ESXi 6.x vers la version 6.0 Update 2 avec la commande esxcli software vib update échouent avec des messages d'erreur semblables au message suivant :

    [DependencyError]
    VIB VMware_bootbank_esx-base_6.0.0-2.34.xxxxxxx requires vsan << 6.0.0-2.35, but the requirement cannot be satisfied within the ImageProfile.
    VIB VMware_bootbank_esx-base_6.0.0-2.34.xxxxxxx requires vsan >= 6.0.0-2.34, but the requirement cannot be satisfied within the ImageProfile.


    Ce problème se produit en raison de l'introduction d'un nouveau VIB Virtual SAN qui est interdépendant du VIB esx-base et la commande esxcli software vib update ne met à jour que les VIB déjà installés sur le système.

    Solution : Pour résoudre ce problème, exécutez la commande esxcli software profile update comme indiqué dans l'exemple suivant :

    esxcli software profile update -d /vmfs/volumes/datastore1/update-from-esxi6.0-6.0_update02.zip -p ESXi-6.0.0-20160302001-standard

  • SSLv3 reste activé sur Auto Deploy après une mise à niveau d'une version antérieure de vSphere 6.0 vers vSphere 6.0 Update 1 et versions ultérieures
    Lorsque vous mettez à niveau une version antérieure de vSphere 6.0 vers vSphere 6.0 Update 1 et versions ultérieures, le protocole SSLv3 reste activé sur Auto Deploy.

    Solution : Pour désactiver SSLv3 à l'aide de commandes PowerCLI, procédez comme suit :

    1. Exécutez la commande suivante pour vous connecter à vCenter Server :

      PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Connect-VIServer -Server <FQDN_hostname or IP Address of vCenter Server>

    2. Exécutez la commande suivante pour vérifier l'état actuel de sslv3 :

      PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-DeployOption

    3. Exécutez la commande suivante pour désactiver sslv3 :

      PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Set-DeployOption disable-sslv3 1

    4. Redémarrez le service Auto Deploy pour mettre à jour la modification.

  • Il est possible que le numéro de périphérique de l'adaptateur de bus hôte Fibre Channel soit modifié après la mise à niveau d'ESXi 5.5.x vers 6.0

    Durant la mise à niveau d'ESXi 5.5.x vers 6.0, le numéro de périphérique de l'adaptateur de bus hôte Fibre Channel est parfois modifié. Le numéro de périphérique est susceptible d'être modifié si vous utilisez la commande esxcli storage core adapter list.

    Par exemple, les numéros de périphérique d'un adaptateur de bus hôte Fibre Channel peuvent être semblables au suivant avant la mise à niveau d'ESXi :

    Nom HBA
    ––––––––
    vmhba3
    vmhba4
    vmhba5
    vmhba66

    Les numéros de périphérique d'un adaptateur de bus hôte Fibre Channel peuvent être semblables au suivant après la mise à niveau d'ESXi vers la version 6.0 :

    Nom HBA
    ––––––––
    vmhba64
    vmhba65
    vmhba5
    vmhba6

    L'exemple illustre la modification aléatoire pouvant se produire si vous utilisez la commande esxcli storage core adapter list : les numéros d'alias de périphérique vmhba2 et vmhba3 deviennent vmhba64 et vmhba65, alors que les numéros de périphérique vmhba5 et vmhba6 restent inchangés. Toutefois, si vous avez utilisé la commande esxcli hardware pci list, les numéros de périphérique ne sont pas modifiés après la mise à niveau.

    Il s'agit d'un problème externe à VMware qui peut ne pas vous concerner. ESXi affiche les noms d'alias de périphérique, mais il ne les utilise pour aucune opération. Vous pouvez utiliser le profil d'hôte pour réinitialiser le nom d'alias de périphérique. Consultez la documentation produit VMware et les articles de la base de connaissances.

    Solution : aucune.

  • Les paramètres d'Active Directory ne sont pas conservés après une mise à niveau
    Les paramètres d'Active Directory configurés dans l'hôtes ESXi avant la mise à niveau ne sont pas conservés lorsque l'hôte est mis à niveau vers ESXi 6.0.

    Solution : Ajoutez l'hôte au domaine Active Directory après la mise à niveau si la version d'ESXi avant la mise à niveau était 5.1 ou versions ultérieures. N'ajoutez pas l'hôte au domaine Active Directory après la mise à niveau si la version d'ESXi avant la mise à niveau était 5.0.x.

  • Après la mise à niveau d'ESXi vers la version 6.0, les hôtes qui ont été précédemment ajoutés au domaine ne sont plus joints au domaine
    Lors de la première mise à niveau de vSphere 5.5 vers vSphere 6.0, la configuration d'Active Directory n'est pas conservée.

    Solution : Après la mise à niveau, joignez de nouveau les hôtes au domaine vCenter Server :

    1. Ajoutez les hôtes à vCenter Server.

    2. Joignez les hôtes au domaine (par exemple, exemple.com)

    3. Mettez à niveau tous les hôtes vers ESXi 6.0.

    4. Joignez manuellement au domaine un hôte récemment mis à niveau.

    5. Extrayez le profil d'hôte et désactivez tous les profils, sauf Authentification.

    6. Appliquez le profil d'hôte joint manuellement aux autres hôtes mis à niveau récemment.

  • Le service VMware ESXi Dump Collector précédemment en cours d'exécution se réinitialise au paramètre Désactivé par défaut après la mise à niveau de vCenter Server pour Windows
    Le processus de mise à niveau installe VMware Vsphere ESXi Dump Collector 6.0 dans le cadre d'un groupe de services facultatifs pour vCenter Server. Vous pouvez manuellement activer le service VMware vSphere ESXi Dump Collector pour l'utiliser dans le cadre de vCenter Server 6.0 pour Windows.

    Solution : Lisez la documentation VMware ou recherchez dans la base de connaissances VMware des informations sur l'activation et l'exécution de services facultatifs dans vCenter Server 6.0 pour Windows.

    Activez le service VMware vSphere ESXi Dump Collector dans le système d'exploitation :

    1. Dans le menu du Panneau de configuration, sélectionnez Outils d'administration et double-cliquez sur Services.

    2. Cliquez avec le bouton droit sur VMware vSphere ESXi Dump Collector et sur Modifier le type de démarrage.

    3. Définissez le Type de démarrage sur Automatique.

    4. Cliquez avec le bouton droit sur VMware vSphere ESXi Dump Collector, puis cliquez sur Démarrer.

    Le Type de démarrage du service est défini sur automatique et le service est en cours d’exécution.

Problèmes de gestion des certificats et de vCenter Single Sign-On
  • Impossible de se connecter à la console de la machine virtuelle après la mise à niveau du certificat SSL de l'hôte ESXi
    Une erreur de validation de certificat peut se produire si vous mettez à jour le certificat SSL utilisé par un hôte ESXi et si vous tentez ensuite de vous connecter à la console de la machine virtuelle en cours d'exécution au moment où le certificat a été remplacé. Cela est dû au fait que l'ancien certificat est mis en cache et que chaque nouvelle connexion à la console est rejetée en raison de l'incompatibilité.
    La connexion à la console peut être réussie malgré tout, par exemple, si l'ancien certificat peut être validé par d'autres moyens, mais sans garantie de succès. Les connexions à la console de la machine virtuelle existantes ne sont pas affectées, mais il se peut que vous rencontriez ce problème si la console était en cours d'exécution au moment du remplacement du certificat, a été arrêtée, puis redémarrée.

    Solution : Placez l'hôte en mode de maintenance, ou bien interrompez ou mettez hors tension toutes les machines virtuelles. Seules les machines virtuelles en cours d'exécution sont affectées. Nous vous recommandons d'effectuer toutes les mises à niveaux du certificat SSL après avoir placé l'hôte en mode de maintenance.

Problèmes de mise en réseau

  • Certaines fonctionnalités de vSphere ne prennent pas en charge l'IPv6
    Vous pouvez activer l'IPv6 pour tous les nœuds et composants, sauf pour les fonctionnalités suivantes :

    • Adresses IPv6 pour les hôtes ESXi hosts et vCenter Server qui ne sont pas mappées à des noms de domaine complets sur le serveur DNS.
      Solution : Utilisez des noms de domaine complets ou assurez-vous que les adresses IPv6 sont mappées aux noms de domaine complets sur les serveurs DNS pour la recherche inversée de nom.

    • volumes virtuels

    • Démarrage PXE dans le cadre d'Auto Deploy et des profils d'hôte
      Solution : Démarrez avec PXE un hôte ESXi sur IPv4 et configurez l'hôte pour l'IPv6 à l'aide des profils d'hôte.

    • Connexion d'hôtes ESXi et de vCenter Server Appliance à Active Directory
      Solution : Utilisez Active Directory sur LDAP comme source d'identité dans vCenter Single Sign-On.

    • Stockage NFS 4.1 avec Kerberos
      Solution : Utilisez NFS 4.1 avec AUTH_SYS.

    • Authentication Proxy

    • Connexion de vSphere Management Assistant et de vSphere Command-Line Interface à Active Directory.
      Solution : Connectez-vous à Active Directory sur LDAP.

    • Utilisation de vSphere Client pour activer l'IPv6 sur les fonctionnalités de vSphere
      Solution : Utilisez vSphere Web Client pour activer l'IPv6 pour les fonctionnalités de vSphere.

  • Une panique récursive peut se produire lors de l'utilisation de ESXi Dump Collector
    Une kernel panic récursive peut se produire lorsque l'hôte se trouve dans un état de panique au moment où il affiche l'écran de diagnostic violet et enregistre le vidage de mémoire sur le réseau sur ESXi Dump Collector. Il se peut qu'un fichier VMkernel zdump ne soit pas disponible pour résoudre le problème survenu sur ESXi Dump Collector dans vCenter Server.

    En cas de kernel panic récursive, l'écran de diagnostic violet sur l'hôte affiche le message suivant :
    2014-09-06T01:59:13.972Z cpu6:38776)Starting network coredump from host_ip_address to esxi_dump_collector_ip_address.
    [7m2014-09-06T01:59:13.980Z cpu6:38776)WARNING: Net: 1677: Check what type of stack we are running on [0m
    Recursive panic on same CPU (cpu 6, world 38776, depth 1): ip=0x418000876a27 randomOff=0x800000:
    #GP Exception 13 in world 38776:vsish @ 0x418000f0eeec
    Secondary panic trap frame registers:
    RAX:0x0002000001230121 RCX:0x000043917bc1af80 RDX:0x00004180009d5fb8 RBX:0x000043917bc1aef0
    RSP:0x000043917bc1aee8 RBP:0x000043917bc1af70 RSI:0x0002000001230119 RDI:0x0002000001230121
    R8: 0x0000000000000038 R9: 0x0000000000000040 R10:0x0000000000010000 R11:0x0000000000000000
    R12:0x00004304f36b0260 R13:0x00004304f36add28 R14:0x000043917bc1af20 R15:0x000043917bc1afd0
    CS: 0x4010 SS: 0x0000 FS: 0x4018 GS: 0x4018 IP: 0x0000418000f0eeec RFG:0x0000000000010006
    2014-09-06T01:59:14.047Z cpu6:38776)Backtrace for current CPU #6, worldID=38776, rbp=0x43917bc1af70
    2014-09-06T01:59:14.056Z cpu6:38776)0x43917bc1aee8:[0x418000f0eeec]do_free_skb@com.vmware.driverAPI#9.2+0x4 stack: 0x0, 0x43a18b4a5880,
    2014-09-06T01:59:14.068Z cpu6:38776)Recursive panic on same CPU (cpu 6, world 38776): ip=0x418000876a27 randomOff=0x800000:
    #GP Exception 13 in world 38776:vsish @ 0x418000f0eeec
    Halt$Si0n5g# PbC8PU 7.

    La kernel panic récursive peut se produire lorsque VMkernel panique en cas de trafic volumineux dans l'adaptateur réseau physique, également configuré pour envoyer les vidages de mémoire au Collector sur vCenter Server.

    Solution : Appliquez l'une des solutions suivantes :

    • Dédiez un adaptateur réseau physique à la transmission du vidage de mémoire uniquement afin de réduire l'impact sur le trafic système et sur la machine virtuelle.

    • Désactivez ESXi Dump Collector sur l'hôte en exécutant la commande de console ESXCLI suivante :
      esxcli system coredump network set --enable false

Problèmes de stockage

    Problèmes de NFS version 4.1

    • Les machines virtuelles sur une banque de données NFS 4.1 échouent après que le partage NFS 4.1 récupère à partir d'un état Tous chemins hors service (APD)
      Lorsque le stockage NFS 4.1 passe à un état Tous chemins hors service (APD), puis le quitte après une période de grâce, les machines virtuelles sous tension s'exécutant sur la banque de données NFS 4.1 se bloquent. La période de grâce dépend du fournisseur de la baie.
      Une fois le partage NFS 4.1 récupère de l'état Tous chemins hors service (APD), le message suivant s'affiche sur la page de résumé de la machine virtuelle dans vSphere Web Client :
      Le verrou protégeant VM.vmdk a été perdu, probablement en raison de problèmes de stockage sous-jacents. Si cette machine virtuelle est configurée pour être hautement disponible, assurez-vous qu'elle s'exécute sur un hôte différent avant de cliquer sur OK.
      Après avoir cliqué sur OK, des fichiers de blocage sont générés et la machine virtuelle est mise hors tension.

      Solution : aucune.

    • Le client NFS 4.1 perd sa synchronisation avec le serveur lors de tentatives de création de nouvelles sessions
      Après une période connectivité interrompue avec le serveur, le client NFS 4.1 est susceptible de ne plus être synchronisé sur le serveur en cas de tentatives de création de nouvelles sessions. Lorsque cela se produit, le fichier vmkernel.log contient une série limitée de messages d'avertissement indiquant qu'une demande NFS41 CREATE_SESSION a échoué avec NFS4ERR_SEQ_MISORDERED.

      Solution : Procédez comme suit :

      1. Tentez de démonter les systèmes de fichiers affectés. Si aucun fichier n'est ouvert lorsque vous procédez au démontage, cette opération réussit et le module du client NFS remet son état interne au propre. Vous pouvez ensuite remonter les systèmes de fichiers démontés et reprendre les opérations normales.

      2. Démontez les cartes réseau connectées aux adresses IP des montages et laissez-les ainsi suffisamment longtemps pour que plusieurs durées de bail du serveur expirent. Cinq minutes devraient suffire. Vous pouvez ensuite remonter les cartes réseau. Le fonctionnement normal devrait reprendre.

      3. Si les instructions précédentes ne règlent pas le problème, redémarrez l'hôte ESXi.

    • Le client NFS 4.1 perd sa synchronisation avec un serveur NFS et la connexion ne peut pas être récupérée même quand une session est réinitialisée
      Après une période de connectivité interrompue avec le serveur, il se peut que le client NFS 4.1 perde sa synchronisation avec le serveur et que la connexion synchronisée avec le serveur ne puisse pas être récupérée, même si la session est réinitialisée. Ceci est dû à un problème de serveur EMC VNX. Lorsque cela se produit, le fichier vmkernel.log contient une série limitée de messages d'avertissement indiquant NFS41 : NFS41ProcessSessionUp:2111: resetting session with mismatched clientID; probable server bug.

      Solution : Pour terminer la session, démontez toutes les banques de données, puis remontez-les.

    • Les volumes ONTAP Kerberos deviennent inaccessibles ou rencontrent des pannes d'E/S
      Un serveur NetApp ne répond pas quand il reçoit des demandes RPCSEC_GSS qui arrivent dans le désordre. En conséquence, l'opération d'E/S correspondante se bloque, sauf si elle est terminée et que le système d'exploitation invité peut se bloquer ou rencontre des erreurs d'E/S. De plus, d'après la RFC 2203, le client peut avoir uniquement un certain nombre de demandes en instance égal à seq_window (32 en cas d'ONTAP) d'après le contexte RPCSEC_GSS et il doit attendre que la demande en instance dont la priorité est la plus faible soit exécutée par le serveur. En conséquence, le serveur ne répond jamais à la demande RPCSEC_GSS dans le désordre, et le client arrête d'envoyer des demandes au serveur une fois qu'il atteint le nombre seq_window maximal de demandes en instance. Cela entraîne l'inaccessibilité du volume.

      Solution : aucune. Consultez la liste de compatibilité du matériel (HCL) la plus récente pour trouver un serveur ONTAP pris en charge ayant résolu ce problème.

    • Vous ne pouvez pas créer de disque virtuel dont l'espace disque est supérieur à 1 To sur la banque de données NFS 4.1 depuis l'EMC VNX
      Le stockage NFS version 4.1 de l'EMC VNX avec la version 7.x du micrologiciel prend en charge uniquement les formats de fichiers 32 bits. Ceci vous empêche de créer des fichiers de machine virtuelle supérieurs à 1 To dans la banque de données NFS 4.1.

      Solution : Mettez à jour la baie EMC VNX vers la version 8.x.

    • Les banques de données NFS 4.1 soutenues par le stockage EMC VNX deviennent inaccessibles lors des mises à niveau du micrologiciel
      lorsque vous mettez à niveau le stockage EMC VNX avec un micrologiciel récent, les banques de données NFS 4.1 montées sur l'hôte ESXi deviennent inaccessibles. Ce problème se produit, car le serveur VNX change de numéro de périphérique principal après la mise à niveau du micrologiciel. Le client NFS 4.1 sur l'hôte n'anticipe pas le changement de numéro principal après avoir établi la connectivité avec le serveur et provoque l'inaccessibilité permanente des banques de données.

      Solution : Démontez toutes les banques de données NFS 4.1 exportées par le serveur VNX avant de mettre à niveau le micrologiciel.

    • Lorsque les hôtes ESXi utilisent des mécanismes de sécurité différents pour monter la même banque de données NFS 4.1, des pannes de machine virtuelle peuvent se produire
      Si différents hôtes ESXi montent la même banque de données NFS 4.1 à l'aide de mécanismes de sécurité différents, AUTH_SYS et Kerberos, les machines virtuelles placées sur cette banque de données peuvent rencontrer des problèmes et se bloquer. Par exemple, vos tentatives de migration de machines virtuelles de l'hôte1 à l'hôte2 peuvent échouer avec des erreurs d'autorisation refusée. Il se peut que vous observiez ces erreurs lorsque vous tentez d'accéder à une machine virtuelle de l'hôte1 depuis l'hôte2.

      Solution : Vérifiez que tous les hôtes qui montent un volume NFS 4.1 utilisez le même type de sécurité.

    • Échec des tentatives de copie de fichiers en lecture seule sur la banque de données NFS 4.1 avec Kerberos
      L'échec peut se produire lorsque vous tentez de copier des données entre un fichier source et un fichier cible. Le fichier cible reste vide.

      Solution : aucune.

    • Lorsque vous créez un cluster de banque de données, l'uniformité des types de sécurité de NFS 4.1 n'est pas garantie
      Lors de la création d'un cluster de banque de données, vSphere ne vérifie pas et n'applique pas l'uniformité des types de sécurité de NFS 4.1. En conséquence, les banques de données utilisant des types de sécurité différents, AUTH_SYS et Kerberos, peuvent faire partie du même cluster. Si vous migrez une machine virtuelle d'une banque de données avec Kerberos vers une banque de données avec AUTH_SYS, le niveau de sécurité de la machine virtuelle diminue.
      Ce problème s'applique aux fonctionnalités comme vMotion, Storage vMotion, DRS et Storage DRS.

      Solution : Si la sécurité de Kerberos est requise pour vos machines virtuelles, assurez-vous que tous les volumes NFS 4.1 qui composent le même cluster utilisent uniquement le type de sécurité de Kerberos. N'incluez pas de banques de données NFS 3, car NFS 3 ne prend en charge que AUTH_SYS.

    Problèmes de Virtual SAN

    • L'interface utilisateur de santé de Virtual SAN ne s'affiche pas en raison d'un délai d'expiration
      Lorsque vous accédez à l’interface utilisateur de santé Virtual SAN sous Cluster Virtual SAN > Surveiller > Virtual SAN > Santé, l’interface utilisateur ne s’affiche pas. Cela peut être dû à un blocage de vSphere ESX Agent Manager, qui entraîne un délai d’expiration. Pour vérifier, ouvrez le journal de santé de Virtual SAN situé dans /var/log/vmware/vsan-health/vmware-vsan-health-service.log et recherchez les appels vers le service vSphere ESX Agent Manager à l’aide de la chaîne VsanEamUtil.getClusterStatus:.

      Solution : redémarrez le service vSphere ESX Agent Manager à l’aide de vSphere Web Client et actualisez l’interface utilisateur de santé de Virtual SAN.

    • Le plug-in de facilité de maintenance du disque Virtual SAN ne fonctionne pas lorsque vous utilisez des pilotes tiers lsi_msgpt3
      Un contrôle de santé d’un cluster Virtual SAN à deux ou trois nœuds sous Cluster Virtual SAN > Surveiller > Virtual SAN > Santé > Santé de limite > après 1 autre panne d'hôte s’affiche en rouge et déclenche un faux événement ou une fausse alarme vCenter Server lorsque l’utilisation de l’espace disque du cluster dépasse 50 %.

      Solution : ajoutez un ou plusieurs hôtes au cluster Virtual SAN ou ajoutez plus de disques afin de réduire l’utilisation de l’espace disque du cluster à moins de 50 %.

    • Le contrôle de santé de limite d'un cluster Virtual SAN à deux ou trois nœuds s'affiche en rouge
      Le plug-in pour la facilité de maintenance du disque Virtual SAN, lsu-lsi-lsi-msgpt3-plugin, prend en charge l’opération pour obtenir l’emplacement du périphérique et activer ou désactiver la LED du disque. Le pilote de boîte de réception VMware lsi_msgpt3 prend en charge le plug-in de facilité de maintenance. Cependant, si vous utilisez un pilote asynchrone tiers, le plug-in ne fonctionne pas.

      Solution : utilisez le pilote de boîte de réception VMware lsi_msgpt3 version 06.255.10.00-2vmw ou ultérieure.

    Problèmes de Virtual Volumes

    • Échec de création de banques de données virtuelles en raison d'un certificat incorrect utilisé par le fournisseur Virtual Volumes VASA
      Il peut arriver qu'un certificat autosigné utilisé par le fournisseur Virtual Volumes VASA ne définisse pas correctement l'extension KeyUsage comme critique sans définir le bit keyCertSign. Dans ce cas, l'inscription du fournisseur réussit. Néanmoins, vous ne pouvez pas créer de banque de données virtuelle dans les conteneurs de stockage rapportés par le fournisseur VASA.

      Solution : Le certificat autosigné utilisé par le fournisseur VASA lors de l'inscription du fournisseur ne doit pas définir l'extension KeyUsage comme critique sans définir le bit keyCertSign.

    Problèmes de stockage généraux

    • Les hôtes ESXi 6.0 Update 2 connectés à certaines baies de stockage avec une version particulière du microprogramme peuvent rencontrer des expirations de délai d'E/S et des abandons par la suite
      Lorsque des hôtes ESXi 6.0 Update 2 connectés à des baies avec une version particulière du microprogramme envoient des requêtes de données SMART vers la baie de stockage et que la baie répond avec une erreur PDL, le comportement de la réponse PDL dans la version 6.0 Update 2 peut provoquer une condition dans laquelle ces commandes échouées sont continuellement réessayées, bloquant de la même manière les autres commandes. Cette erreur provoque des délais d'expiration d'E/S généralisés et des arrêts ultérieurs.

      De plus, la reconnexion des hôtes ESXi à vCenter Server après redémarrage peut être très longue et les hôtes peuvent passer à l'état Pas de réponse dans vCenter Server. La réalisation des tâches relatives au stockage telles que la réanalyse HBA peut être très longue.

      Solution : Afin de résoudre ce problème, consultez l'article 2133286 de la base de connaissances

    • vSphere Web Client affiche incorrectement la stratégie de stockage comme connectée lorsqu'une machine virtuelle est créée à partir d'un disque
      Lorsque vous utilisez vSphere Web Client pour créer une machine virtuelle à partir d'un disque et spécifiez une stratégie de stockage lors de la configuration du disque, l'affichage est incorrect. Le filtre apparaît connecté lorsque vous sélectionnez la nouvelle machine virtuelle --> cliquez sur Stratégies de VM --> Modifier les stratégies de stockage VM, toutefois le filtre n'est pas réellement connecté. Vous pouvez contrôler le fichier .vmdk ou le vmkfstools --iofilterslist <vmdk-file>' pour vérifier si le filtre est connecté ou pas.

      Solution : Après avoir créé la machine virtuelle, mais avant de la mettre sous tension, ajoutez le filtre au vmdk en cliquant sur Stratégies de VM --> Modifier les stratégies de stockage VM.

    • L'opération de recherche NFS renvoie des erreurs NFS STALE
      Lors du déploiement d'un grand nombre de VM dans la banque de données NFS, le déploiement de VM échoue avec un message d'erreur semblable au suivant en raison d'une condition de concurrence :

      Handle de fichier NFS périmé

      Solution : Redémarrez l'opération de recherche. Reportez-vous à l'article 2130593 de la base de connaissances pour obtenir plus de détails.

    • Les tentatives de création d'une banque de données VMFS sur des LUN Dell EqualLogic échouent lorsque des adaptateurs QLogic iSCSI sont utilisés
      Vous ne pouvez pas créer de banque de données VMFS sur un périphérique de stockage Dell EqualLogic détecté au moyen d'adaptateurs QLogic iSCSI.
      Lorsque vos tentatives échouent, le message d'erreur suivant s'affiche sur vCenter Server : Impossible de créer un système de fichiers, reportez-vous au journal VMkernel log pour en savoir plus : la connexion a expiré. Le journal VMkernel contient des messages session iscsi bloquée et session iscsi session débloquée continus. Sur la baie de stockage Dell EqualLogic, la journalisation de surveillance affiche un message erreur de protocole dans le paquet reçu de l'initiateur concernant les noms IQN de l'initiateur QLogic.

      Ce problème se produit lorsque vous utilisez les composants suivants :

      • Microprogramme de la baie Dell EqualLogic : version 6.0.7

      • Versions du microprogramme de l'adaptateur QLogic iSCSI : 3.00.01.75

      • Version du pilote : 5.01.03.2-7vmw-debug

      Solution : Activez le paramètre de l'adaptateur iSCSI ImmediateData sur l'adaptateur QLogic iSCSI. Par défaut, le paramètre est désactivé. Vous ne pouvez pas modifier ce paramètre dans vSphere Web Client ou en utilisant les commandes esxcli. Pour modifier ce paramètre, utilisez le logiciel fourni pas le fournisseur, comme l'interface de ligne de commande QConvergeConsole.

    • Échec du démarrage de l'hôte ESXi avec un HBA Emulex OneConnect
      Lorsqu'un hôte ESXi dispose d'un HBA Emulex OneConnect, le démarrage de l''hôte peut échouer. Cette panne se produit à cause d'un problème avec le micrologiciel Emulex.

      Solution : Pour le corriger, contactez Emulex pour obtenir le micrologiciel le plus récent pour votre HBA.

      Si vous continuez d'utiliser l'ancien micrologiciel, suivez ces étapes pour éviter un échec au démarrage :

      1. Pendant le chargement d'ESXi, appuyez sur Maj+O avant le démarrage du noyau ESXi.

      2. Laissez l'option de démarrage paramétrée telle quelle, et ajoutez un espace suivi de dmaMapperPolicy=false.

    • Flash Read Cache n'accélère pas les E/S à l'état Tous chemins hors service (APD)
      Lorsque le disque Flash configuré en tant que ressource Flash virtuelle pour Flash Read Cache est défaillant ou inaccessible, ou si le stockage sur disque est inaccessible depuis l'hôte, les instances de Flash Read Cache sur cet hôte sont non valides et ne fonctionnent pas pour accélérer les E/S. En conséquences, les caches ne gèrent pas les données périmées une fois la connectivité rétablie entre l'hôte et le stockage. La panne de connectivité peut être temporaire, un état Tous chemins hors service (APD), ou permanente, un état Perte permanente de périphérique (PDL). Cet état persiste jusqu'à ce que la machine virtuelle soit mise hors tension puis à nouveau sous tension.

      Solution : La machine virtuelle peut être mise hors tension puis à nouveau sous tension pour restaurer l'accélération d'E/S à l'aide de Flash Read Cache.

    • Un état Tous chemins hors service (APD) ou des basculements de chemin peuvent entraîner des pannes système
      Dans un environnement SAS, un état APD ou des situations de basculement de chemin peuvent entraîner une panne système si les disques sont réclamés par le pilote lsi_msgpt3 et qu'ils subissent une activité d'E/S importante.

      Solution : aucune

    • L'utilisation fréquente des commandes d'abandon SCSI peut entraîner des pannées système
      Avec une activité d'E/S importante, des commandes d'abandon SCSI fréquentes peuvent provoquer une réponse très lente de la part du contrôleur MegaRAID. Si une interruption inattendue se produit avec les références ressources déjà publiées dans un contexte précédent, une panne système peut se produire.

      Solution : aucune

    • Les connexions iSCSI échouent et les banques de données deviennent inaccessibles lorsque l'IQN change
      Ce problème peut se produire si vous changez l'IQN d'un adaptateur iSCSI alors que des sessions iSCSI sont encore actives sur l'adaptateur.

      Solution : Lorsque vous modifiez l'IQN d'un adaptateur iSCSI, aucune session ne doit être active sur celui-ci. Supprimez toutes les sessions iSCSI et toutes les cibles sur l'adaptateur avant de modifier l'IQN.

    • Les opérations nvmecli en ligne et hors ligne peuvent ne pas toujours prendre effet
      Lorsque vous exécutez l'opération nvmecli device online -A vmhba* pour mettre un périphérique NVMe en ligne, l'opération semble réussir. Néanmoins, le périphérique peut se trouver encore dans un état hors ligne.

      Solution : Vérifiez le statut des périphériques NVMe en exécutant la commande nvmecli device list.

    Problèmes de configuration de serveur
    • Échec de la correction lors de l'application d'un profil d'hôte d'un hôte avec état à un hôte provisionné avec Auto Deploy
      Lors de l'application d'un profil d'hôte d'un hôte déployé avec état à un hôte provisionné avec Auto Deploy (hôte sans état) sans aucun stockage local, la tentative de correction échoue et renvoie l'un des messages d'erreur suivants :

      • Le périphérique vmhba à l'adresse de bus PCI sxxxxxxxx.xx est absent de votre hôte. Vous devez arrêter l'hôte et insérer une carte à l'emplacement PCI yy. Le type de carte doit correspondre exactement à celui indiqué dans l'hôte de référence.

      • Aucune partition de coredump valide n'a été trouvée.

      Solution : Désactivez le plug-in qui provoque ce problème (par exemple, Configuration des alias de périphériques ou Configuration du vidage mémoire) du profil d'hôte, puis corrigez le profil d'hôte.

    • L'application du profil d'hôte avec IP statique à un hôte entraîne une erreur de conformité
      Si vous extrayez un profil d'hôte d'un hôte avec une configuration réseau DHCP et que vous modifiez ensuite le profil d'hôte pour qu'il dispose d'une adresse IP statique, une erreur de conformité se produit avec le message suivant lorsque vous l'appliquez à un autre hôte :

      Le nombre d'itinéraires IPv4 ne correspondait pas.

      Solution : Avant d'extraire le profil d'hôte de l'hôte DHCP, configurez l'hôte de sorte qu'il dispose d'une adresse IP statique.

    • Lorsque ajoutez à chaud un adaptateur réseau virtuel dont les ressources sont surchargées, il se peut que la machine virtuelle se mette hors tension
      Sur un vSphere Distributed Switch, sur lequel Network I/O Control est activé, une machine virtuelle sous tension est configurée avec une réservation de bande passante correspondant à la réservation du trafic système de la machine virtuelle sur l'adaptateur réseau physique de l'hôte. Vous ajoutez à chaud un adaptateur réseau à la machine virtuelle définissant une réservation de bande passante du réseau supérieure à celle disponible sur les adaptateurs réseau physiques de l'hôte.

      Lorsque vous ajoutez à chaud l'adaptateur réseau, VMkernel démarre une opération d'interruption et de reprise rapides. ///Dans la mesure où la machine virtuelle nécessite davantage de ressources réseau que celles disponibles, VMkernel recourt au processus en cas de défaillance de l'opération d'interruption et de reprise rapides. ///Une erreur de ce processus peut entraîner la mise hors tension de la machine virtuelle.

      Solution : Ne configurez pas la réservation de bande passante lorsque vous ajoutez un adaptateur réseau à une machine virtuelle sous tension.

    Problèmes avec VMware HA et Fault Tolerance
    • Valeur de Fault Tolerance (FT) héritée non prise en charge sur les plates-formes Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT et Broadwell-DE
      La fonctionnalité FT héritée n'est pas prise en charge sur les plates-formes Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT et Broadwell-DE. Les tentatives de mettre sous tension une machine virtuelle échouent après l'activation de Fault Tolerance héritée et à un seul cœur.

      Solution : aucune.

    Problèmes de système d'exploitation invité
    • Les tentatives d'activer le mode relais sur les périphériques SSD NVMe PCIe peut échouer après un ajout à chaud
      Pour activer le mode relais sur un périphérique SSD à partir de vSphere Web Client, sélectionnez un hôte, cliquez sur l'onglet Gérer, cliquez sur Paramètres, accédez à la section Matériel, cliquez sur Périphériques PCI > Modifier, sélectionnez un périphérique dans la liste des périphériques actifs pouvant être activés pour le mode relais, puis cliquez sur OK. Cependant, lorsque vous connectez à chaud un nouveau périphérique NVMe à un hôte ESXi 6.0 ne disposant pas d'un lecteur PCIe NVMe, le nouveau périphérique NVMe PCIe SSD ne peut pas être activé pour le mode relais et ne figure pas dans la liste des périphériques de relais disponibles.

      Solution : Redémarrez votre hôte. Vous pouvez également exécuter la commande sur votre hôte ESXi.

      1. Connectez-vous en tant qu'utilisateur racine.

      2. Exécutez la commande
        /etc/init.d/hostd start

    Problèmes de matériel pris en charge
    • Lorsque vous exécutez esxcli pour obtenir l'emplacement du disque, le résultat n'est pas correct pour les contrôleurs Avago sur les serveurs HP
      Lorsque vous exécutez esxcli storage core device physical get par rapport à un contrôleur Avago sur un serveur HP, le résultat est incorrect.

      Par exemple, si vous exécutez :
      esxcli storage core device physical get -d naa.5000c5004d1a0e76
      Le système renvoie :
      Physical Location: enclosure 0, slot 0

      L'étiquette réelle de ce logement du serveur physique est 1.

      Solution : Vérifiez soigneusement le logement de votre serveur HP. Étant donné que les numéros de logement du serveur HP commencent à 1, vous devez augmenter le numéro de logement renvoyé par la commande pour obtenir le résultat correct.

    Problèmes CIM et API
    • Le sfcb-vmware_raw peut échouer
      Le sfcb-vmware_raw peut échouer si le maximum de mémoire allouée par défaut au plug-in de groupe de ressources n'est pas suffisant.

      Solution : Ajoutez UserVars CIMOemPluginsRPMemMax pour les limites de mémoire des plug-ins sfcbd en utilisant la commande suivante et redémarrez le sfcbd pour appliquer la nouvelle valeur de plug-ins :

      esxcfg-advcfg -A CIMOemPluginsRPMemMax --add-desc 'Maximum Memory for plugins RP' --add-default XXX --add-type int --add-min 175 --add-max 500

      XXX correspondant à la limite de mémoire que vous souhaitez allouer. Cette valeur doit être comprise entre les valeurs minimum (175) et maximum (500).