| vCenter Server 6.7.0d | 14 août 2018 | Build ISO 9451876 vCenter Server Appliance 6.7.0d | 14 août 2018 | Build 9451876 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
vCenter Server 6.7.0d inclut la liste de nouvelles fonctionnalités suivante :
- vCenter Server 6.7.0d et la version de correctif ESXi670 -201808001 d'ESXi 6.7 introduisent l'option de configuration avancée d'ESXi HyperthreadingMitigation. Cette nouvelle option atténue la vulnérabilité décrite dans le document CVE-2018-3646. Pour plus d'informations sur l'évaluation de la vulnérabilité et toutes les étapes d'atténuation pour l'environnement vSphere, consultez l'article 55636 de la base de connaissances VMware.
- vCenter Server 6.7.0d et la version de correctif ESXi670-201808001 d'ESXi 6.7 introduisent l'option de configuration avancée d'ESXi SuppressHyperthreadWarning. Après l'installation du correctif ESXi, si votre environnement comporte des hôtes exposés à la vulnérabilité CVE-2018-3646, une alerte s'affiche dans l'onglet Résumé de vSphere Web Client ou de vSphere Client. Vous pouvez utiliser SuppressHyperthreadWarning afin de supprimer cette alerte.
Versions antérieures de vCenter Server 6.7
Les fonctionnalités et problèmes connus de vCenter Server sont décrits dans les notes de mise à jour de chaque version. Notes de mise à jour des versions antérieures de vCenter Server 6.7 :
Pour plus d'informations sur l'internationalisation, la compatibilité, l'installation et les mises à niveau, les composants open source et les remarques concernant l'assistance produit, consultez les Notes de mise à jour de VMware vSphere 6.7.
Correctifs contenus dans cette version
vCenter Server 6.7.0d fournit les correctifs suivants. Pour plus d'informations sur le téléchargement des correctifs, consultez le Centre de téléchargement des correctifs de VMware.
Correctif complet pour VMware vCenter Server Appliance 6.7.0d
Correctif produit pour vCenter Server Appliance 6.7 contenant des correctifs logiciels VMware.
Ce correctif s'applique à vCenter Server Appliance et au dispositif Platform Services Controller.
Pour vCenter Server et les dispositifs Platform Services Controller
| Nom de fichier de téléchargement |
VMware-vCenter-Server-Appliance-6.7.0.14000-9451876-patch-FP.iso |
| Build |
9451876 |
| Taille du téléchargement |
2094,8 Mo |
| md5sum |
5139b76cbf31160d719a21f04b16b6e8 |
| sha1checksum |
3fcd61de56a7ecd7c2f0e41d94753fa213c6a521 |
Téléchargement et installation
Vous pouvez télécharger ce correctif en accédant au Centre de téléchargement des correctifs de VMware et en choisissant VC dans le menu déroulant Recherche par produit.
- Attachez le fichier
VMware-vCenter-Server-Appliance-6.7.0.14000-9451876-patch-FP.iso au lecteur de CD ou de DVD de vCenter Server Appliance.
- Connectez-vous à l'interpréteur de commandes du dispositif en tant qu'utilisateur racine et exécutez les commandes indiquées ci-dessous :
- Pour transférer l'image ISO :
software-packages stage --iso
- Pour voir le contenu transféré :
software-packages list --staged
- Pour installer les RPM transférés :
software-packages install --staged
Pour plus d'informations sur l'application de correctifs sur vCenter Server Appliance, consultez Correction de vCenter Server Appliance.
Pour plus d'informations sur le transfert de correctifs, consultez Transférer les correctifs vers vCenter Server Appliance.
Pour plus d'informations sur l'installation de correctifs, consultez Installation de correctifs vCenter Server Appliance.
Pour en savoir plus sur les problèmes résolus dans ce correctif, consultez la section Problèmes résolus.
Pour plus d'informations sur l'application de correctifs à l'aide de l'interface de gestion des dispositifs, consultez la section Correction de vCenter Server Appliance à l'aide de l'interface de gestion de dispositifs.
Notes de mise à niveau de cette version
Important : pour appliquer l'atténuation appropriée de la vulnérabilité CVE-2018-3646, vous devez tout d'abord procéder à la mise à jour vers vCenter Server 6.7.0d, puis appliquer l'atténuation sur chaque hôte selon la procédure décrite dans l'article 55636 de la base de connaissances VMware. Vous pouvez procéder à l'atténuation du système d'exploitation invité une fois que tous les hôtes sont sécurisés. Toute tentative de configurer ou reconfigurer Enhanced vMotion Compatibility (EVC) par machine virtuelle alors que les hôtes ne sont que partiellement atténués peut entraîner des difficultés lors du dépannage des comportements de vSphere vMotion mentionnés dans la section Problèmes connus. Effectuez la mise à niveau de tous les hôtes avant de modifier la configuration des machines virtuelles.
Les chemins de mise à niveau et de migration de vCenter Server 6.5 Update 2 et versions ultérieures vers vCenter Server 6.7 et versions ultérieures ne sont pas pris en charge.
Problèmes résolus
Les problèmes résolus sont regroupés comme suit :
Problèmes de sécurité
Problèmes connus
Les problèmes connus sont classés comme suit :
Problèmes divers
- Une application de correctifs incohérente sur vCenter Server et ESXi peut entraîner des problèmes avec EVC par machine virtuelle
Si vous procédez à la mise à niveau vers la version de correctif ESXi670-201808001 d'ESXi 6.7, mais ne mettez pas à niveau tous les hôtes ESXi, une instance d'EVC par machine virtuelle récemment configurée ou reconfigurée peut mettre sous tension de manière incorrecte une machine virtuelle sur un hôte non corrigé. Dans ce cas, certaines fonctionnalités de machine virtuelle ajoutées à un hôte corrigé peuvent être manquantes. En raison des contrôles de compatibilité, ces machines virtuelles ne peuvent pas être migrées vers des hôtes corrigés dans le même cluster EVC à l'aide de vSphere vMotion. Si les hôtes source et de destination n'appartiennent pas au même cluster EVC, ils peuvent disposer de différents ensembles de fonctionnalités et la migration peut être possible.
Solution : avant de configurer ou reconfigurer l'EVC par machine virtuelle, mettez à niveau tous les hôtes ESXi autonomes ainsi que les hôtes appartenant à un cluster vers la version de correctif ESXi670-201808001 d'ESXi 6.7.
- Si vous activez l'EVC par machine virtuelle, les machines virtuelles peuvent ne pas être mises sous tension.
Si vous activez l'EVC au niveau du cluster et que la version de correctif ESXi670-201808001 d'ESXi 6.7 n'est pas appliquée à l'un des hôtes du cluster, les nouveaux ID de CPU de ce cluster peuvent ne pas y être disponibles. Dans ce type de cluster, si vous configurez ou reconfigurez l'EVC par machine virtuelle, les machines virtuelles peuvent ne pas être mises sous tension.
Solution : avant de configurer ou reconfigurer l'EVC par machine virtuelle, mettez à niveau tous les hôtes ESXi autonomes ainsi que les hôtes appartenant à un cluster vers la version de correctif ESXi670-201808001 d'ESXi 6.7.
- Si vous désactivez l'EVC par machine virtuelle, la migration des machines virtuelles à l'aide de VMware vSphere vMotion peut échouer
Si vous activez l'EVC au niveau du cluster et que la version de correctif ESXi670-201808001 d'ESXi 6.7 n'est pas appliquée à l'un des hôtes du cluster, les nouveaux ID de CPU de ce cluster peuvent ne pas y être disponibles. Dans ce type de cluster, si vous désactivez l'EVC par machine virtuelle, la migration vers un hôte corrigé à l'aide de vSphere vMotion peut échouer pour les machines virtuelles s'exécutant sur un hôte non corrigé.
Solution : mettez à niveau tous les hôtes dans le cluster EVC vers la version de correctif ESXi670-201808001 d'ESXi 6.7. Désactivez l'EVC par machine virtuelle.
vCenter Server, vSphere Client et vSphere Web Client
- Tenter de désactiver l'utilisation de l'Hyperthreading après l'activation de l'option HyperthreadingMitigation sur un hôte ESXi peut déclencher un message incorrect dans la vue Processeurs
Lorsque vous activez l'option HyperthreadingMitigation sur un hôte ESXi, en définissant VMkernel.Boot.HyperthreadingMitigation sur True, l'utilisation de l'hyperthreading par le correctif ESXi est désactivée, quels que soient les paramètres précédents. Si vous décidez de définir le paramètre VMkernel.Boot.Hyperthreading sur False pour désactiver l'option, le message Désactivé (Activé au redémarrage) peut s'afficher dans la vue Processeurs. En réalité, l'hyperthreading n'est pas utilisé après le redémarrage.
Solution : aucune. Ignorez ce message.
Problèmes connus des versions antérieures
Pour afficher la liste des problèmes connus précédents, cliquez ici.
Les problèmes connus des versions antérieures sont classés comme suit :
Problèmes de mise à niveau
- L'historique des correctifs peut s'afficher de manière incorrecte après l'application du correctif vCenter Server Appliance 6.7.0a à l'aide de l'interface de gestion de vCenter Server Appliance
Après l'application du correctif vCenter Server Appliance 6.7.0a à l'aide de l'interface de gestion de vCenter Server Appliance et l'exécution de la commande software-packages list --history dans l'interpréteur de commandes du dispositif, le système peut ne pas afficher la liste complète des correctifs appliqués.
Solution : suivez l'historique des correctifs dans le répertoire /var/vmware/applmgmt/patch-history/.
- Lorsque vous appliquez le correctif vCenter Server Appliance 6.7.0a, vous pouvez être déconnecté de l'interface de gestion de vCenter Server Appliance
Lorsque vous appliquez le correctif vCenter Server Appliance 6.7.0a à une instance de vCenter Server Appliance 6.7 à l'aide de l'interface de gestion de vCenter Server Appliance, vous pouvez être déconnecté de l'interface et perdre la connectivité. Vous ne pouvez pas vous reconnecter avant la fin de l'opération.
Solution : attendez la fin de l'opération et connectez-vous à l'interface de gestion de vCenter Server Appliance.
- Sous Windows, l'application du correctif vCenter Server 6.7.0a à une instance de vCenter Server 6.7 peut échouer avec le code d'erreur 3010
Si vous reconfigurez un système vCenter Server 6.7 sous Windows avec une instance intégrée de Platform Services Controller et que vous le redirigez vers une instance externe de Platform Services Controller, l'application du correctif vCenter Server 6.7.0a à vCenter Server 6.7 peut échouer avec une erreur Échec de l'installation du composant du client VMware Directory Service.
Solution : après la reconfiguration du système vCenter Server 6.7 pour utiliser une instance externe de Platform Services Controller, vous devez redémarrer le système, puis lancer le processus de mise à niveau.
- L'interface de gestion de vCenter Server Appliance peut ne pas afficher le correctif vCenter Server 6.7.0a
L'interface de gestion de vCenter Server Appliance peut ne pas afficher le correctif vCenter Server 6.7.0a et vous ne pourrez peut-être pas effectuer de mise à niveau.
Solution : si vous n'effectuez pas de nouvelle installation, mais que vous utilisez l'interface de gestion de vCenter Server Appliance pour appliquer le correctif vCenter Server 6.7.0a à votre système vCenter Server, vous devez :
- Dans l'interface de gestion de vCenter Server Appliance, accédez à Mise à jour > Paramètres et configurez l'URL personnalisée pour
https://vapp-updates.vmware.com/vai-catalog/valm/vmw/8d167796-34d5-4899-be0a-6daade4005a3/6.7.0.10000.latest/.
- Retentez la mise à niveau.
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 :
- désactivez l'option Partition utilisateur intégrée dans le BIOS du serveur.
- 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 :
- 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
- 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.
-
Cliquez sur Accéder, puis sur Modifier.
-
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.
-
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.
- Accédez à la clé de registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
- Créez un dossier et nommez-le
TLS 1.2.
- Créez deux clés avec le dossier
TLS 1.2, puis nommez les clés Client et Server.
- Sous la clé Client, créez deux valeurs DWORD (32 bits) et nommez-les DisabledByDefault et Enabled.
- Sous la clé Serveur, créez deux valeurs DWORD (32 bits) et nommez-les DisabledByDefault et Enabled.
- Assurez-vous que le champ Valeur est défini sur 0 et que la base est Hexadecimal for DisabledByDefault.
- Assurez-vous que la valeur du champ est définie sur 1 et que la base est Hexadecimal for Enabled.
- 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 :
- Modifiez les paramètres du profil d'hôte.
- 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.
- 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.
- Exécutez la commande esxcli system module parameters set -m nmlx5_core -p DRSS=0 RSS=0.
- 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 :
- Extrayez un profil d'hôte depuis un hôte ESXi.
- 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.
- 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 :
- 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.
- Vérifiez la configuration du vSwitch sur la vmnic associée à l'adaptateur FCoE manquant.
- 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 :
- 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
- Dans l'interface de gestion de vCenter Server Appliance, cliquez sur Heure.
- Dans le volet Synchronisation de l'heure, cliquez sur Modifier.
- 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 :
- Définissez l'option Synchronisation de l'heure dans Étape 2 -> Configuration du dispositif sur Synchroniser sur ESX
- 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 :
- Dans le système source, créez une variable d'environnement MA_INTERACTIVE_MODE.
- Accédez à Ordinateur > Propriétés > Paramètres système avancés > Variables d'environnement > Variables système > Nouveau.
- Entrez « MA_INTERACTIVE_MODE » comme nom de la variable avec la valeur 0 ou 1.
- Démarrez l'Assistant Migration VMware et fournissez votre mot de passe.
- 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).
- REMARQUE : n'appuyez sur aucune touche, ni aucun onglet de la console de l'Assistant Migration.
- Accédez au dossier
%appdata%\vmware\migration-assistant.
- Supprimer le fichier export.zip créé par l'Assistant Migration.
- Pour continuer la migration, créez manuellement le fichier export.zip à partir du dossier d'exportation.
- 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 :
- Supprimez la vmknic de l'hôte.
- 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.
- Connectez-vous à votre hôte en tant que racine.
- 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.
- 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 :
- Extraire un profil d'hôte depuis un hôte ESXi avec la version 6.0.
- Mettre à niveau l'hôte ESXi vers la version 6.7.
- 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é :
- Connectez-vous à l'hôte ESXi et exécutez la commande suivante :
# esxcli system module set -e false -m ixgben
- 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 :
- accédez à l'interpréteur de commande du dispositif et connectez-vous en tant qu'utilisateur disposant du rôle de super administrateur.
- 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.
- 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 :
esxcli system wbem set --enable falseesxcli system wbem set --enable true
- Si vous activez Enhanced vMotion Compatibility (EVC) par machine virtuelle, les machines virtuelles peuvent ne pas être mises sous tension.
Si vous activez l'EVC au niveau du cluster et que l'atténuation d'invité assistée par hyperviseur pour les systèmes d'exploitation invités n'est pas appliquée à l'un des hôtes du cluster, les nouveaux ID de CPU de ce cluster peuvent ne pas y être disponibles. Dans ce type de cluster, si vous configurez ou reconfigurez l'EVC par machine virtuelle, les machines virtuelles peuvent ne pas être mises sous tension.
Solution : Avant de configurer ou reconfigurer l'EVC par machine virtuelle, mettez à niveau tous les hôtes ESXi autonomes, ainsi que les hôtes d'un cluster, vers les correctifs les plus récents pour appliquer l'atténuation d'invité assistée par hyperviseur pour les systèmes d'exploitation invités.
- Si vous désactivez le mode Enhanced vMotion Compatibility (EVC) au niveau de la machine virtuelle, la migration de machines virtuelles à l'aide de VMware vSphere vMotion peut échouer
Si vous activez l'EVC au niveau du cluster et que l'atténuation d'invité assistée par hyperviseur pour les systèmes d'exploitation invités n'est pas appliquée à l'un des hôtes du cluster, les nouveaux ID de CPU de ce cluster peuvent ne pas y être disponibles. Dans ce type de cluster, si vous désactivez l'EVC par machine virtuelle, la migration vers un hôte corrigé à l'aide de VMware vSphere vMotion peut échouer pour les machines virtuelles s'exécutant sur un hôte non corrigé.
Solution : Mettez à niveau tous les hôtes du cluster EVC vers le dernier correctif pour appliquer l'atténuation d'invité assistée par hyperviseur pour les systèmes d'exploitation invités. Désactivez l'EVC au niveau de la machine virtuelle.
- Une application de correctifs incohérente sur vCenter Server et ESXi peut entraîner des problèmes avec Enhanced vMotion Compatibility (EVC) par machine virtuelle
Si vous appliquez le correctif à un système vCenter Server avec l'atténuation d'invité assistée par hyperviseur pour les systèmes d'exploitation invités et que certains hôtes ESXi ont été également mis à niveau, une instance d'EVC par machine virtuelle récemment configurée ou reconfigurée peut incorrectement mettre sous tension une machine virtuelle sur un hôte non corrigé. Dans ce cas, certaines fonctionnalités de machine virtuelle ajoutées à un hôte corrigé peuvent être manquantes. En raison des contrôles de compatibilité, ces machines virtuelles ne peuvent pas être migrées vers des hôtes corrigés dans le même cluster EVC à l'aide de vSphere vMotion. Si les hôtes source et de destination n'appartiennent pas au même cluster EVC, ils peuvent disposer de différents ensembles de fonctionnalités et la migration peut être possible. Solution :
Solution : Solution : avant de configurer ou reconfigurer l'EVC par machine virtuelle, mettez à niveau tous les hôtes ESXi autonomes ainsi que les hôtes d'un cluster vers les correctifs les plus récents pour appliquer l'atténuation d'invité assistée par hyperviseur pour les systèmes d'exploitation invités.
Pour réduire la liste des problèmes connus précédents, cliquez ici.
