Mises à jour le : 17 avril 2018

ESXi 6.7 | 17 avril 2018 | Build ISO 8169922

vCenter Server 6.7 | 17 avril 2018 | Build ISO 8217866

vCenter Server Appliance 6.7 | 17 avril 2018 | Build 8217866

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 de VMware vSphere 6.7 inclut ESXi 6.7 et vCenter Server 6.7. Reportez-vous à Nouveautés de VMware vSphere 6.7 pour découvrir les nouvelles fonctionnalités et améliorations de cette version.

Internationalisation

VMware vSphere 6.7 est disponible dans les langues suivantes :

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

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

Compatibilité

Compatibilité des versions d'ESXi et vCenter Server

La Matrice d'interopérabilité des produits VMware fournit des détails sur la compatibilité des versions en cours et précédentes des composants VMware vSphere, y compris ESXi, VMware vCenter Server et les produits VMware facultatifs. 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 Update Manager, vSphere Client et vSphere Web Client font partie du module vCenter Server.

Compatibilité matérielle pour ESXi

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

Compatibilité des périphériques pour ESXi

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

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

Pour déterminer les systèmes d'exploitation invités compatibles avec vSphere 6.7, consultez les informations sur ESXi 6.7 dans le Guide de compatibilité 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.7. 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.7, effectuez une mise à niveau de la compatibilité de la machine virtuelle. Reportez-vous à la documentation Mise à niveau d'ESXi.

Installation et mises à niveau de cette version

Notes d'installation de cette version

Consultez les documentations Installation et configuration d'ESXi et Installation et configuration de vCenter Server pour obtenir 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 :

VMware introduit un nouvel outil de configuration maximale pour vous aider à planifier vos déploiements vSphere. Cet outil permet d'afficher les limites recommandées par VMware pour les machines virtuelles, les instances ESXi, vCenter Server, vSAN, la mise en réseau, etc. Vous pouvez également comparer les limites pour deux versions de produit ou plus. L'outil Configurations maximales VMware s'affiche de manière optimale sur des périphériques grand format tels que les ordinateurs portables et de bureau.

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

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

Les images ISO de VMware Tools 10.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 versions ultérieures

Les images ISO de VMware Tools 10.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 :

Migration de solutions tierces

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

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

Comparé à vSphere 6.5, vSphere 6.7 ne prend plus en charge les processeurs suivants :

  • AMD Opteron 13xx Series
  • AMD Opteron 23xx Series
  • AMD Opteron 24xx Series
  • AMD Opteron 41xx Series
  • AMD Opteron 61xx Series
  • AMD Opteron 83xx Series
  • AMD Opteron 84xx Series
  • Processeur Intel Core i7-620LE
  • Intel i3/i5 Clarkdale Series
  • Intel Xeon 31xx Series
  • Intel Xeon 33xx Series
  • Intel Xeon 34xx Clarkdale Series
  • Intel Xeon 34xx Lynnfield Series
  • Intel Xeon 35xx Series
  • Intel Xeon 36xx Series
  • Intel Xeon 52xx Series
  • Intel Xeon 54xx Series
  • Intel Xeon 55xx Series
  • Intel Xeon 56xx Series
  • Intel Xeon 65xx Series
  • Intel Xeon 74xx Series
  • Intel Xeon 75xx Series

Pendant une installation ou une mise à niveau, le programme d'installation vérifie la compatibilité du CPU hôte avec vSphere 6.7. 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.7 s'interrompt.

Les CPU suivants sont pris en charge dans la version vSphere 6.7, mais ils peuvent ne pas être pris en charge dans les prochaines versions de vSphere. Prévoyez en conséquence :

  • Intel Xeon E3-1200 (BNS-DT)
  • Intel Xeon E7-2800/4800/8800 (WSM-EX)

Notes de mise à niveau de cette version

Pour obtenir des instructions sur la mise à niveau des hôtes ESXi et de vCenter Server, reportez-vous aux documentations Mise à niveau d'ESXi et Mise à niveau de vCenter Server.

Composants open source pour vSphere 6.7

Les déclarations de copyright et les licences applicables aux composants logiciels open source distribués dans vSphere 6.7 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 sources 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 relatives à la prise en charge du produit

  • La version vSphere 6.7 est la version finale de vCenter Server pour Windows. Après cette version, vCenter Server pour Windows ne sera plus disponible. Pour plus d'informations, reportez-vous à la section Adieu, vCenter Server pour Windows.

  • Dans vSphere 6.7, vSphere Client (HTML5) dispose de nombreuses nouvelles fonctionnalités et est proche de devenir un client entièrement fonctionnel avec toutes les fonctionnalités de vSphere Web Client (Flex). La plupart des fonctionnalités nécessaires pour gérer les opérations de vCenter Server sont disponibles dans cette version, y compris vSAN et la prise en charge initiale de vSphere Update Manager (VUM). Pour obtenir une liste actualisée des fonctionnalités non prises en charge, consultez le Guide de mise à jour des fonctionnalités de vSphere Client.

    vSphere 6.7 continue de fournir vSphere Web Client, que vous pouvez utiliser pour toutes les opérations vCenter Server avancées manquantes dans vSphere Client. Toutefois, VMware prévoit de rendre vSphere Web Client obsolète dans les futures versions. Pour plus d'informations, reportez-vous à la section Adieu, vSphere Web Client.

    VMware Host Client est une application basée sur le Web que vous pouvez utiliser pour gérer des hôtes ESXi individuels qui ne sont pas connectés à un système vCenter Server.

  • La version vSphere 6.7 est la version finale des deux ensembles d'API vSphere Client : les API vSphere Web Client (Flex) et l'ensemble actuel d'API vSphere Client (HTML5), également appelées API Bridge. Un nouvel ensemble d'API vSphere Client est inclus dans le cadre de la version vSphere 6.7. Ces nouvelles API sont conçues pour mettre à l'échelle et prendre en charge les cas d'utilisation et la sécurité, la conception et l'extensibilité améliorées de vSphere Client.

  • VMware déconseille webplatform.js, qui sera remplacée par une méthode améliorée permettant de transférer les mises à jour vers les solutions de plug-in de partenaires sans aucune dépendance de cycle de vie sur les mises à jour de vSphere Client SDK. 

    Remarque : si vous disposez d'une solution de plug-in existante pour vSphere Client, vous devez mettre à niveau le serveur Virgo. La version des plug-ins vSphere Client existante ne sera pas compatible avec la version vSphere 6.7, sauf si vous effectuez cette mise à niveau. Pour plus d'informations sur la mise à niveau du serveur Virgo, reportez-vous à Mise à niveau de votre plug-in pour conserver la compatibilité avec vSphere Client SDK 6.7.

  • Dans vSphere 6.7, seul TLS 1.2 est activé par défaut. TLS 1.0 et TLS 1.1 sont désactivés par défaut. Si vous mettez à niveau vCenter Server ou Platform Services Controller vers vSphere 6.7, et que l'instance de vCenter Server ou de Platform Services Controller se connecte aux hôtes ESXi, à d'autres instances de vCenter Server ou à d'autres services, vous pouvez rencontrer des problèmes de communication.

    Pour résoudre ces problèmes, vous pouvez utiliser l'utilitaire du programme de configuration de TLS pour activer temporairement d'anciennes versions du protocole sur les systèmes vSphere 6.7. Vous pouvez ensuite désactiver les anciennes versions moins sécurisées, une fois que toutes les connexions utilisent TLS 1.2. Pour plus d'informations, reportez-vous à Gestion de la configuration du protocole TLS avec l'utilitaire du programme de configuration de TLS dans l'ensemble de documentations vSphere 6.7.

    Dans la version vSphere 6.7, vCenter Server ne prend pas en charge la connexion TLS 1.2 pour les bases de données Oracle.

  • vSphere 6.7 est la dernière version qui prend en charge le remplacement des certificats des utilisateurs de solution publiés par VMCA par des certificats personnalisés via l'interface utilisateur. Le renouvellement des certificats des utilisateurs de solution par des certificats publiés par VMCA via l'interface utilisateur sera pris en charge dans les versions suivantes.

  • vSphere 6.7 est la dernière version nécessitant que les clients spécifient des sites SSO. Ce descripteur n'est requis pour aucune fonctionnalité vSphere et sera supprimé. Les prochaines versions de vSphere n'incluront pas de sites SSO configurables par le client.

  • Vous ne pouvez pas installer VMware vCenter Server Appliance 6.7 sur la version d'origine d'ESXi 6.0 avec un réseau IPv6. Au lieu de cela, installez vCenter Server Appliance sur ESXi 6.0 Update 1a ou versions ultérieures avec un réseau IPv6.

  • Les opérations de mise à niveau et d'application de correctif pour les dispositifs virtuels sont obsolètes dans Update Manager 6.7.

  • L'image ISO de Windows antérieure à Vista pour VMware Tools n'est plus fournie avec vSphere 6.7. L'image iso de Windows antérieure à Vista est disponible au téléchargement pour les utilisateurs qui en ont besoin. Pour plus d'informations sur le téléchargement, reportez-vous à la section Téléchargements de VMware Tools.

  • Le service TFTP inclus dans les dispositifs vCenter Server et Photon n'est pas pris en charge par VMware. Nous vous recommandons d'utiliser ce service uniquement à des fins de test et de développement, non dans un environnement de production. Si vous utilisez ce service, vous reconnaissez et convenez que vous l'utilisez exclusivement à vos propres risques. VMware se réserve le droit de le supprimer dans des versions ultérieures.

Problèmes connus

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

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
check-circle-line exclamation-circle-line close-line
Scroll to top icon