| vCenter Server 6.7 Update 3 | 20 août 2019 | ISO Build 14367737 vCenter Server Appliance 6.7 Update 3 | 20 août 2019 | Build ISO 14367737 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 Update 3 prend en charge une relation dynamique entre les paramètres d'adresse IP d'un dispositif vCenter Server Appliance et d'un serveur DNS. Les enregistrements de ressources DNS sont mis à jour dès qu'une adresse IP du dispositif vCenter Server Appliance est modifiée. Le client DDNS (Dynamic Domain Name Service) sur le dispositif vCenter Server Appliance envoie également des mises à jour sécurisées automatiques aux serveurs DNS à des intervalles planifiés. Toutefois, ces mises à jour dynamiques de DNS ne sont prises en charge que lorsque le dispositif vCenter Server Appliance est joint à un domaine Active Directory et que vous disposez des privilèges d'administrateur.
- Avec vCenter Server 6.7 Update 3, vous pouvez configurer des machines virtuelles et des modèles avec jusqu'à quatre périphériques GPU virtuels (vGPU) NVIDIA pour couvrir les cas d'utilisation nécessitant plusieurs accélérateurs GPU attachés à une machine virtuelle. Pour utiliser la fonctionnalité vGPU de vMotion, vous devez définir le paramètre avancé
vgpu.hotmigrate.enabled sur true et vous assurer que vos hôtes vCenter Server et ESXi exécutent vSphere 6.7 Update 3.
vMotion sur des machines virtuelles accélérées par plusieurs GPU peut échouer normalement sous une charge de travail GPU intense en raison du délai maximal de basculement de 100 secondes. Pour éviter cet échec, augmentez le délai maximal de basculement autorisé ou attendez que la machine virtuelle assure une charge de travail GPU moins intensive.
- Avec vCenter Server 6.7 Update 3, vous pouvez modifier l'identifiant réseau principal (PNID) de votre dispositif vCenter Server Appliance. Vous pouvez modifier le nom de domaine complet ou le nom d'hôte du dispositif vCenter Server Appliance, et modifier la configuration d'adresse IP du réseau de gestion de machines virtuelles (NIC 0). Pour plus d'informations, reportez-vous à cette publication de blog VMware.
- Avec vCenter Server 6.7 Update 3, si l'état de santé global d'un cluster vSAN est rouge, les API de configuration ou d'extension des clusters HCI lèvent l'exception
InvalidState pour empêcher une autre configuration ou extension. Ce correctif vise à résoudre les situations dans lesquelles des versions mixtes de l'hôte ESXi dans un cluster HCI peuvent entraîner la partition réseau vSAN.
- vCenter Server 6.7 ajoute un microcode SandyBridge au VIB cpu-microcode pour actualiser la sécurité SandyBridge au niveau d'autres CPU et corriger la prise en charge de la compatibilité EVC (Enhanced vMotion Compatibility) par machine virtuelle. Pour plus d'informations, reportez-vous à l'article 1003212 de la base de connaissances VMware.
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 les remarques relatives à l'internationalisation, la compatibilité, l'installation et la mise à niveau, ainsi qu'aux composants open source et avis de prise en charge des produits, consultez les Notes de mise à jour de VMware vSphere Update Manager 6.7 Update 1.
Notes de mise à niveau de cette version
La mise à niveau de vCenter Server 6.7 Update 1a vers la version 6.7 Update 3 n'est pas prise en charge. Vous devez d'abord effectuer la mise à niveau vers vCenter Server 6.7 Update 1b ou 6.7 Update 2, puis appliquer le correctif 6.7 Update 3.
Correctifs contenus dans cette version
Cette version de vCenter Server 6.7 Update 3 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 de sécurité pour VMware vCenter Server 6.7 Update 3
Correctifs de produits tiers (par exemple : JRE, tcServer). Ce correctif s'applique à vCenter Server pour Windows, Platform Services Controller pour Windows et vSphere Update Manager.
REMARQUE : Ce correctif met uniquement à jour JRE version 8U212 b31.
Pour vCenter Server et Platform Services Controller pour Windows
| Nom de fichier de téléchargement |
VMware-VIMPatch-T-6.7.0-14367737.iso |
| Build |
14367737 |
| Taille du téléchargement |
40,7 Mo |
| md5sum |
a50e2ef2b1da9eac74bf2cc12e3a7b6d |
| sha1checksum |
8d216b132b8bc1a4dc306bd4a41007b6857ed88e |
Ces composants vCenter Server dépendent de JRE et doivent être corrigés :
- vCenter Server
- Platform Services Controller
- vSphere Update Manager
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 Sélectionner un produit.
- Montez le fichier
VMware-VIMPatch-T-6.7.0-14367737.iso sur le système où le composant de vCenter Server est installé.
- Double-cliquez sur
ISO_mount_directory/autorun.exe.
- Dans l'assistant de mise à jour des composants Java de vCenter Server, cliquez sur Tout corriger.
Correctif complet pour VMware vCenter Server Appliance 6.7 Update 3
Correctif de produit pour vCenter Server Appliance contenant des correctifs logiciels et de sécurité VMware ainsi que des correctifs de produits tiers (par exemple : JRE et tcServer).
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.40000-14367737-patch-FP.iso |
| Build |
14367737 |
| Taille du téléchargement |
1 980,5 Mo |
| md5sum |
57c943bd8bfd6580a49ca1e58ecdd382 |
| sha1checksum |
7ec1ba261f7bd236803155bad1ec727fa40a63ae |
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 Sélectionner un produit.
- Attachez le fichier
VMware-vCenter-Server-Appliance-6.7.0.40000-14367737-patch-FP.iso au lecteur de CD ou de DVD de vCenter Server Appliance.
- Connectez-vous à l'interpréteur de commandes du dispositif avec vos informations d'identification d'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'utilisation des interpréteurs de commandes vCenter Server Appliance, consultez l'article 2100508 de la base de connaissances VMware.
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 obtenir des mises à jour de Photon OS, reportez-vous à la section Correctifs de sécurité de Photon OS pour VMware vCenter Server Appliance.
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.
Problèmes résolus
Les problèmes résolus sont regroupés comme suit :
Problèmes de sécurité
- Mise à jour du Spring Framework
Le Spring Framework est mis à jour vers la version 4.3.22.
- Mise à jour du serveur Apache Tomcat
Le serveur Apache Tomcat est mis à jour vers la version 8.5.38.
- Mise à niveau d'Eclipse Jetty
Eclipse Jetty est mis à niveau vers la version 9.4.15.v20190215.
- Mise à jour de PostgreSQL
PostgreSQL est mis à jour vers la version 9.6.12.
- Mise à jour du module de processeur JSON
Le module de processeur JSON est mis à jour vers la version 2.9.8.
- Vulnérabilités de sécurité avec jQuery version 2.1.4
JQuery version 2.1.4 peut présenter des vulnérabilités de sécurité lors de l'exécution d'appels AJAX à des agents Domino.
Ce problème est résolu dans cette version. Ce correctif met à niveau les versions de jQuery et de l'interface utilisateur jQuery.
- Mise à jour du serveur Apache HTTP (httpd)
Httpd a été mis à jour vers la version 2.4.39 afin de résoudre les problèmes de sécurité CVE-2019-0211, CVE-2019-2017 et CVE-2019-0215.
- Mise à jour d'Apache Struts
Apache Struts est mis à jour vers la version 2.5.20.
- Échec de la connexion de VMware OVF Tool à un système vCenter Server cible via un serveur proxy Web sécurisé
L'outil OVF prenait en charge les connexions à un système vCenter Server cible via un serveur proxy HTTP normal, mais pas via un proxy sécurisé.
Ce problème est résolu dans cette version. Vous pouvez connecter l'outil OVF à un système vCenter Server cible via un serveur proxy Web sécurisé.
- Mise à jour du Spring Framework
Le Spring Framework est mis à jour vers la version 4.3.22.
- Une fois que le serveur Active Directory est temporairement inaccessible, les autorisations d'utilisateur et de groupe du domaine Active Directory sont supprimées
vCenter Server valide régulièrement les utilisateurs et les groupes par rapport au domaine Active Directory Windows. Si une identité est supprimée, le système vCenter Server supprime les autorisations qui lui sont associées. Si le serveur Active Directory est inaccessible pendant le processus de validation, le système vCenter Server peut l'interpréter de manière incorrecte comme une suppression de tous les utilisateurs et groupes de domaine, et peut supprimer les autorisations qui leur sont associées.
Ce problème est résolu dans cette version. Le correctif fait la différence entre une identité manquante et aucune connexion.
- Mise à jour du démon Network Time Protocol (NTP)
Le démon NTP est mis à jour vers la version 4.2.8p13.
- Mise à jour d'OpenSSL
Le module OpenSSL est mis à jour vers la version openssl-1.0.2r.
- Mise à jour de la bibliothèque zlib
La bibliothèque zlib est mise à jour vers la version 1.2.11.
- Mise à jour de cURL
cURL est mis à jour vers la version 7.64.1.
- Mise à jour du noyau de Photon OS
Le noyau de Photon OS a été mis à jour vers la version 4.4.182 afin de résoudre les problèmes de sécurité CVE-2019-11477, CVE-2019-11478 et CVE-2019-11479.
- Mise à jour de JRE
Oracle (Sun) JRE est mis à jour vers la version 8U212 b31.
Problèmes de mise en réseau
- Après un appel d'API vers un hôte ESXi, si un élément de transaction n'est pas supprimé, le service vpxd peut manquer de mémoire
Dans certains cas, après un appel d'API à un hôte ESXi, si un élément de transaction n'est pas supprimé, le service vpxd peut manquer de mémoire. Ce problème se produit dans les grands déploiements avec des filtres de trafic complexes configurés sur des groupes de ports virtuels distribués.
Ce problème est résolu dans cette version.
- Une fois que vous avez rétabli un snapshot, la carte réseau de la machine virtuelle peut être incorrectement connectée au vSphere Distributed Switch (VDS)
Si vous prenez un snapshot d'une machine virtuelle lorsque la carte réseau de la machine virtuelle est déconnectée d'un VDS, le retour à ce même snapshot peut entraîner la connexion automatique de la carte réseau de la machine virtuelle au VDS.
Ce problème est résolu dans cette version.
- Dans les environnements Active Directory complexes, il se peut que vous ne parveniez pas à vous connecter au système vCenter Server avec une erreur NoPermission
Dans les environnements comportant des déploiements Active Directory complexes ou lents, les utilisateurs d'Active Directory peuvent ne pas parvenir à se connecter au système vCenter Server avec une erreur NoPermission.
Ce problème est résolu dans cette version.
- vSphere Distributed Resource Scheduler (DRS) peut déterminer de manière incorrecte qu'un cluster est déséquilibré
vSphere DRS peut déterminer de manière incorrecte qu'un cluster est sérieusement déséquilibré lorsque le nombre d'hôtes de basculement et de non-basculement est presque identique. Par conséquent, DRS déclenche fréquemment des migrations vMotion.
Ce problème est résolu dans cette version. Pour que le correctif prenne effet, vous devez activer l'option avancée ExcludeFailoverHostFromSD sur 1, afin d'exclure les hôtes de basculement des calculs effectués par DRS pour détecter si un cluster est équilibré ou non.
Problèmes avec vCenter Server, vSphere Web Client et vSphere Client
- La section Autres disques durs risque de ne plus figurer dans le volet Matériel VM de vSphere Web Client
Dans vSphere Web Client, lorsque vous sélectionnez une machine virtuelle dans l'inventaire vCenter Server, il se peut que la section Autres disques durs ne s'affiche pas dans le volet Matériel VM.
Ce problème est résolu dans cette version.
- Les capteurs de baie de disques sont classés comme Autres périphériques
Dans vSphere Client, vSphere Web Client et VMware Host Client, les capteurs de baie de disques sont classés comme Autres périphériques.
Ce problème est résolu dans cette version. Le correctif classe les capteurs de baie de disques dans la catégorie Stockage.
- La numérotation des règles de pare-feu peut changer de manière inattendue si vous réorganisez les règles
Si vous créez plus de 9 règles de pare-feu dans une instance de vCenter Server Appliance et que vous en modifiez l'ordre, en définissant une règle avec numérotation à deux chiffres parmi des règles avec numérotation à un chiffre, la numérotation peut changer. Par exemple, si vous déplacez une règle portant le numéro 10, telle que 10 RETURN all -- X.X.X.10 anywhere, en position 2, la numérotation peut devenir 2 RETURN all -- X.X.X.10 anywhere.
Ce problème est résolu dans cette version.
Problèmes de mise à niveau
- Les mises à niveau de vCenter Server vers la version 6.7 Update 2 peuvent échouer si la récupération de transaction est activée
Les mises à niveau de vCenter Server vers la version 6.7 Update 2 peuvent échouer par intermittence si la récupération des transactions est activée.
Ce problème est résolu dans cette version.
- Votre configuration SNMP peut ne pas être conservée après une mise à niveau du système vCenter Server
Votre configuration SNMP peut ne pas être conservée après une mise à niveau du système vCenter Server.
Ce problème est résolu dans cette version. Le correctif ajoute la prise en charge des exportations de la configuration SNMP lors d'une mise à niveau dans le processus upgradeRunner.
- Les mises à niveau de vCenter Server peuvent échouer en raison d'une dépendance de composant non résolue
Les mises à niveau de vCenter Server de la version 6.0.x vers la version 6.7.x peuvent échouer par intermittence en raison d'une dépendance de composant non résolue. Vous pouvez voir un message d'erreur semblable à eam:Export failed due to missing vpxd_connector.ext file.
Ce problème est résolu dans cette version.
Problèmes de gestion des machines virtuelles
- Lorsque vous activez la vérification du déséquilibre par paires, DRS peut migrer des machines virtuelles même si le cluster semble équilibré
Dans vCenter Server 6.0 Update 3 et versions ultérieures, si l'option avancée CheckPairwiseImbalance de DRS est activée, lorsque DRS détecte un déséquilibre par paires entre deux hôtes, il continue d'équilibrer la charge en migrant des machines virtuelles entre les deux hôtes, même si le cluster semble équilibré. Un déséquilibre par paires se produit lorsque deux hôtes dans le cluster ont une différence d'utilisation de CPU ou de mémoire supérieure au seuil défini, qui est de 20 % par défaut.
Ce problème est résolu dans cette version.
- Dans vSphere Web Client, vous ne pouvez pas définir la limite de CPU pour les machines virtuelles sur Illimitée
Lorsque vous déployez des machines virtuelles ou modifiez les paramètres des machines virtuelles dans vSphere Web Client, l'option Maximum: Illimitée qui définit la limite de CPU pour les machines virtuelles sur illimitée n'est pas disponible.
Ce problème est résolu dans cette version. Pour utiliser l'option Maximum: Illimitée dans vSphere Web Client, cliquez avec le bouton droit sur une machine virtuelle et cliquez sur Modifier les paramètres. Dans l'onglet Matériel virtuel, accédez à CPU > Limite et sélectionnez Maximum : Illimitée dans le menu déroulant.
Problèmes de stockage
- Les disques de première classe autonomes ne sont pas interrogés et sont pris en compte pour le recalcul de la conformité lors des modifications des associations de balises de banque de données
En cas de modification des associations de balises de banque de données, la tâche périodique de recherche des modifications de balise de banque de données interroge les entités de machines virtuelles et les entités VMDK sur une banque de données particulière. Les disques de première classe autonomes qui ne sont rattachés à aucune machine virtuelle ne sont ni interrogés ni pris en compte. Par conséquent, après des modifications d'associations de balises pour une banque de données, le nouveau calcul de conformité n'est pas déclenché pour les disques de première classe autonomes.
Ce problème est résolu dans cette version. Après une modification d'associations de balises, les disques de première classe sur une banque de données sont identifiés et la conformité est recalculée pour eux.
- Il se peut que vous ne parvienne pas à télécharger un type de fichier dans une banque de données
Lorsque vous essayez de télécharger un fichier dans une banque de données, l'opération peut échouer. Vous pouvez voir une progression de 0 % pour la tâche dans le volet Tâches récentes.
Ce problème est résolu dans cette version.
- Il se peut que vSphere Storage Distributed Resource Scheduler (vSphere Storage DRS) ne fonctionne pas correctement dans les environnements comportant des machines virtuelles de clone lié
Dans les environnements comportant des machines virtuelles de clone lié ou des machines virtuelles ayant des snapshots, vSphere Storage DRS peut ne pas fonctionner correctement. vSphere Storage DRS peut faire des recommandations incorrectes, ne pas fournir de recommandations de migration des machines virtuelles ou les migrer entre deux banques de données dans une boucle infinie. Lorsque vSphere Storage DRS migre une machine virtuelle de clone lié, un calcul incorrect de la taille du disque peut également entraîner la création d'une copie complète du disque de base.
Ce problème est résolu dans cette version.
- vSphere Storage DRS ne parvient pas à générer suffisamment de migrations avec vMotion lors des opérations ExpandDisk et la reconfiguration de la machine virtuelle peut échouer
Lors d'opérations ExpandDisk, vSphere Storage DRS recommande la migration de certaines machines virtuelles ou de certains disques existants vers une autre banque de données pour libérer des ressources pour la nouvelle capacité demandée. Toutefois, vSphere Storage DRS n'inclut pas certaines des actions Storage vMotion dans la recommandation finale. Par conséquent, seule une partie des ressources requises est libérée sur la banque de données actuelle sur laquelle le disque est développé et l'opération ExpandDisk échoue avec une erreur NoDiskSpace.
Ce problème est résolu dans cette version.
- Les rapports d'utilisation du stockage des machines virtuelles cessent de s'actualiser quelques heures après le démarrage d'un hôte ESXi
Les rapports d'utilisation du stockage des machines virtuelles peuvent cesser de s'actualiser quelques heures après le démarrage d'un hôte ESXi. Ce problème est dû à une erreur de débordement négatif dans le calcul de la durée d'actualisation du stockage, entraînant des temps d'attente inhabituellement longs au lieu de la fenêtre de 105 à 135 minutes prévue.
Ce problème est résolu dans cette version. La mise à niveau vers vCenter Server 6.7 Update 3 corrige la synchronisation et réactive les actualisations régulières des rapports d'utilisation du stockage.
Problèmes divers
- Dans un environnement avec une charge de travail importante, VMware Security Token Service (vmware-stsd) peut cesser de répondre et provoquer des échecs de connexion
Le service vmware-stsd a une quantité fixe de mémoire allouée dans le fichier setenv.sh, mais la taille de la mémoire peut être insuffisante dans un environnement avec une charge de travail importante. En conséquence, le service vmware-stsd peut cesser de répondre et provoquer des échecs de connexion.
Ce problème est résolu dans cette version. Le correctif définit dynamiquement l'allocation de mémoire pour le service vmware-stsd au moment du démarrage, en fonction de la taille du déploiement.
Problèmes relatifs au système d'exploitation invité
- L'application générant des noms d'ordinateur et des adresses IP dans un processus de personnalisation du système d'exploitation invité peut ne pas fonctionner correctement
Lorsque vous implémentez une application de génération de noms d'ordinateur et d'adresses IP dans un processus de personnalisation du système d'exploitation invité, l'opération peut échouer avec une erreur : Expiration du délai de l'opération.
Ce problème est résolu dans cette version.
- Les routes statiques des machines virtuelles Red Hat peuvent être perdues après la personnalisation du système d'exploitation invité
Si vous configurez une machine virtuelle Red Hat avec des routes statiques et effectuez une personnalisation du système d'exploitation invité, les routes peuvent être supprimées de la machine virtuelle personnalisée.
Ce problème est résolu dans cette version.
Problèmes de configuration de serveur
- Il se peut que vous ne puissiez pas ajouter un certificat auto-signé au magasin d'approbations ESXi et que vous ne parveniez pas à ajouter un hôte ESXi au système vCenter Server
Le magasin d'approbations ESXi contient une liste de certificats d'autorité de certification (CA) qui sont utilisés pour construire la chaîne d'approbation lorsqu'un hôte ESXi est le client dans une communication de canal TLS. Le bit CA doit être défini sur les certificats du magasin d'approbations : Contraintes de base X509v3 : CA: TRUE. Si ce bit n'est pas défini sur un certificat transmis au magasin d'approbation (par exemple, un certificat auto-signé), le certificat est rejeté. Par conséquent, vous risquez de ne pas pouvoir ajouter un hôte ESXi au système vCenter Server.
Ce problème est résolu dans cette version. Le correctif ajoute l'option avancée Config.HostAgent.ssl.keyStore.allowSelfSigned. Si vous êtes déjà confronté à ce problème, définissez cette option sur TRUE pour ajouter un certificat de serveur auto-signé au magasin d'approbations ESXi.
Problèmes d'interface de ligne de commande
- Si, lors de la convergence vers un vCenter Server avec une instance intégrée de Platform Services Controller, des certificats ou des clés dans le magasin de certificats VECS (VMware Endpoint Certificate Store) contiennent une barre oblique (/), l'opération converge échoue avec une erreur
Si, lors de la convergence vers un système vCenter Server comportant une instance intégrée de Platform Services Controller, les certificats ou les clés dans le VECS contiennent une barre oblique (/), l'opération converge échoue avec une erreur dans le journal converge : Operation failed with error ERROR_FILE_NOT_FOUND.
Ce problème est résolu dans cette version.
Problèmes de CIM et d'API
- Si vous supprimez un hôte ESXi faisant partie d'un cluster du système vCenter Server à l'aide d'une API REST dcli.com.vmware.vcenter.host.delete, l'hôte et le cluster parent sont supprimés
L'API REST dcli.com.vmware.vcenter.host.delete supprime un hôte ESXi autonome du système vCenter Server. Cependant, si un hôte ESXi fait partie d'un cluster et que vous supprimez l'hôte ESXi du système vCenter Server à l'aide de l'API REST dcli.com.vmware.vcenter.host.delete, le cluster parent est également supprimé du système vCenter Server.
Ce problème est résolu dans cette version. Si vous tentez de supprimer un hôte ESXi faisant partie d'un cluster en utilisant l'API REST dcli.com.vmware.vcenter.host.delete, un message d'erreur tel que ResourceInUse s'affiche.
Problèmes relatifs à VMware Tools
- L'outil OVF échoue avec une erreur lors du téléchargement de fichiers OVF ou ISO vers vCloud Director
Lors du téléchargement de fichiers OVF ou ISO vers vCloud Director, l'outil OVF envoie des demandes avec les en-têtes Transfer-Encoding et Content-Length. RFC 7230 est responsable des règles des en-têtes Transfer-Encoding et Content-Length. Selon RFC 7230, l'envoi des deux en-têtes constitue une condition d'erreur et le serveur envoie une réponse 400 : Bad Content-Length. Par conséquent, l'outil OVF échoue avec une erreur : Échec du transfert - Erreur : Échec de l'envoi des données HTTP.
Ce problème est résolu dans cette version. Le correctif ajoute un indicateur à l'outil OVF, afin que l'outil OVF n'envoie pas d'en-tête Content-Length. Lorsque l'outil OVF communique avec vCloud Director, l'indicateur --X:skipContentLength est défini sur True pour rendre l'outil OVF cohérent avec RFC 7230.
- Lorsque l'indicateur --noImageFiles est utilisé lors de l'exportation d'une machine virtuelle ou d'un modèle de machine virtuelle, l'outil OVF peut échouer avec une erreur de segmentation
Lorsque vous essayez d'exporter une machine virtuelle ou un modèle de machine virtuelle avec un fichier NVRAM à l'aide de l'outil OVF et que vous utilisez l'indicateur --noImageFile, l'outil OVF peut échouer avec une erreur de segmentation. L'outil OVF détecte que l'hôte ESXi renvoie le fichier NVRAM de la machine virtuelle ou le modèle de machine virtuelle dans le bail de copie de fichiers réseau qui contient la liste des fichiers. Par conséquent, l'outil OVF peut cesser de répondre en raison d'une différence entre l'hôte ESXi et la ligne de commande. Dans les journaux de l'outil OVF, un message d'erreur semblable à celui-ci peut s'afficher : Could not find any sha digest for ../disk-1.nvram while reading.
Ce problème est résolu dans cette version. L'erreur de segmentation ne se produit pas lorsque vous utilisez l'indicateur --noImageFiles. Un nouvel indicateur --noNvramFile est introduit pour ignorer le téléchargement des fichiers NVRAM lors d'une importation ou d'une exportation. L'indicateur --noImageFiles existant est utilisé pour ignorer le téléchargement de fichiers image tels que CD-ROM et disquette.
Problèmes connus
Les problèmes connus sont classés comme suit :
Problèmes de haute disponibilité
- Des enregistrements DNS en double après la configuration d'un environnement vCenter Server High Availability peuvent interrompre l'accès au système vCenter Server
Après la configuration ou la correction d'un environnement vCenter Server High Availability suivi d'un basculement, l'accès au système vCenter Server peut être bloqué en raison d'enregistrements DNS en double pour le dispositif vCenter Server Appliance.
Solution : Avant d'appliquer un correctif sur les environnements vCenter Server High Availability, nettoyez les enregistrements DNS en double en suivant les instructions de l'article 76406 de la base de connaissances VMware.
Problèmes de convergence
- La convergence, la redirection de domaine et une nouvelle installation de vCenter Server Appliance avec une instance intégrée de Platform Services Controller connectée en mode Embedded Linked Mode peuvent échouer avec l'erreur install.vmafd.vmdir_vdcpromo_error_21
Les opérations suivantes peuvent échouer avec une erreur semblable à : id: install.vmafd.vmdir_vdcpromo_error_21 dans le fichier /var/log/firstboot/vmafd-firstboot.py_<PID>_stderr.log :
- Convergence des instances de vCenter Server Appliance avec des instances externes de Platform Services Controller en instances de vCenter Server Appliance avec une instance intégrée de Platform Services Controller connectée en mode Embedded Linked Mode.
- Redirection d'une instance de vCenter Server avec une instance de Platform Services Controller intégrée vers un nouveau domaine.
- Ajout d'une nouvelle instance de vCenter Server Appliance avec une instance intégrée de Platform Services Controller connectée en mode Embedded Linked Mode.
Solution : pour plus d'informations, reportez-vous à l'article 74678 de la base de connaissances VMware.
Problèmes de mise à niveau
- Après une mise à niveau d'un système vCenter Server vers la version 6.7 Update 2, les disques de première classe (FCD) préalablement mis à niveau peuvent ne pas être répertoriés dans le catalogue global
Lors de la mise à niveau de votre système vCenter Server vers la version 6.7 Update 2, le catalogue global FCD peut choisir un hôte ESXi qui n'est pas encore mis à jour pour appeler une synchronisation et la synchronisation échoue. Par conséquent, l'API listVStorageObjectForSpec peut ne pas renvoyer tous les FCD créés avant la mise à niveau.
Solution : Après la mise à niveau de tous les hôtes ESXi dans l'inventaire, démarrez l'API syncDatastore avec fullSync défini sur true.
Problèmes de stockage
- Comportement incorrect des champs backingObjectId et SnapshotInfo de VStorageObjectResult
Dans les banques de données non-vSAN, les champs backingObjectId et SnapshotInfo de VStorageObjectResult pour un disque de première classe sont toujours définis sur null.
Dans les banques de données vSAN, lorsque vous créez un snapshot d'un disque de première classe, les champs backingObjectId et SnapshotInfo de VStorageObjectResult pour le premier disque de classe sont renseignés. Si le disque de première classe dispose de plusieurs snapshots, la suppression du snapshot le plus récent met à jour les champs backingObjectId et SnapshotInfo, mais la suppression des snapshots plus anciens ne met pas à jour les champs.
Solution : aucune.
Problèmes divers
- Après la mise à jour vers vCenter Server 6.7 Update 3, le service rsyslog cesse de transférer les journaux après un certain temps
Après la mise à jour d'un système vCenter Server vers la version 6.7 Update 3, le service rsyslog peut arrêter le transfert des journaux vers le système après une courte période non définie.
Solution : pour relancer le transfert des journaux vers le serveur distant configuré, redémarrez le service Syslog à l'aide de la commande systemctl restart syslog. Pour plus d'informations, reportez-vous à l'article 75088 de la base de connaissances VMware.
Problèmes détectés dans les versions antérieures
Pour afficher la liste des problèmes connus précédents, cliquez ici.
Les problèmes connus des versions antérieures sont classés comme suit :
Problèmes d'interface de ligne de commande
- L'affichage peut basculer entre l'interpréteur de commandes du dispositif et l'interface utilisateur de console directe pendant une mise à niveau de vCenter Server Appliance à l'aide du programme d'installation de ligne de commande
Pendant une mise à niveau de vCenter Server Appliance à l'aide du programme d'installation de ligne de commande, l'affichage peut basculer par intermittence entre l'interpréteur de commandes du dispositif et l'interface utilisateur de console directe. Le redémarrage du service applmgmt pendant la mise à jour provoque le problème.
Solution : Basculez vers le tty de l'interpréteur de commande du dispositif pour surveiller la progression.
Problèmes d'internationalisation
- Un réseau VMkernel qui utilise un commutateur logique NSX peut échouer pour les hôtes sans état si vous enregistrez une instance vCenter Server avec des caractères non-ASCII sur VMware NSX Manager
Si vous enregistrez une instance vCenter Server sur une instance NSX Manager avec un mot de passe qui contient des caractères provenant des codes ASCII étendus entre 128 et 255 ou des caractères non-ASCII, un réseau VMkernel qui utilise un commutateur logique NSX peut être perdu après le déploiement d'un hôte sans état.
Solution : Enregistrez une instance vCenter Server sur une instance NSX Manager avec un mot de passe contenant uniquement des caractères ASCII.
- Un hôte ESXi peut cesser de répondre si vous ajoutez un vSphere Distributed Switch nommé avec une chaîne qui contient des dizaines de caractères non-ASCII à un adaptateur physique dans un cluster d'infrastructure hyperconvergée (HCI)
Si vous nommez un VDS avec une chaîne contenant plus de 40 caractères à partir des codes ASCII étendus entre 128 et 255 ou plus de 26 caractères non-ASCII, les hôtes ESXi peuvent cesser de répondre lorsque vous tentez d'ajouter le VDS à un adaptateur physique lors de la configuration d'un cluster d'infrastructure hyperconvergée (HCI).
Solution : utilisez des chaînes avec moins de 40 caractères à partir des codes ASCII étendus et de 26 caractères non-ASCII lorsque vous nommez un VDS.
Problèmes relatifs à VMware Tools
- L'outil OVF peut échouer à vérifier l'empreinte SSL si vous utilisez la ligne de commande
Si vous définissez la valeur d'empreinte SSL à l'aide de la ligne de commande, l'outil OVF peut échouer à vérifier l'empreinte numérique. Le problème n'est pas surveillé si vous utilisez l'interface utilisateur de la console directe (DCUI).
Solution : utilisez l'une des possibilités suivantes :
- Dans l'interface DCUI, spécifiez l'empreinte numérique dans la section de
ssl_certificate_verification.
- Dans l'interface DCUI, spécifiez que vous souhaitez ignorer l'empreinte numérique du certificat pour ESXi en réglant
ssl_certificate_verification verification_mode sur False.
- Ignorez toutes les empreintes numériques de certificat globalement en utilisant le paramètre de ligne de commande :
--no-ssl-certificate-verification.
- Attendez que l'invite de ligne de commande accepte l'empreinte numérique reçue par la source.
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 vCenter Server 6.5 pour Windows vers vCenter Server 6.7 peut échouer si le service vSphere Authentication Proxy est actif
Si le service vSphere Authentication Proxy est actif lors de la mise à niveau de vCenter Server 6.5 pour Windows vers vCenter Server 6.7, l'opération peut échouer lors de la vérification préalable. Une erreur semblable à celle-ci peut s'afficher :
Le ou les ports non configurables suivants sont déjà en cours d'utilisation :
2016, 7475, 7476
Arrêtez les processus qui utilisent ces ports.
Solution : Arrêtez le service vSphere Authentication Proxy. Vous pouvez redémarrer le service après la mise à niveau vers vCenter Server 6.7.
- La mise à niveau vers le correctif vCenter Server 6.7 Update 1 à partir des versions antérieures de vCenter Server 6.7 peut échouer lorsque vCenter Server High Availability est actif
La mise à niveau vers le correctif vCenter Server 6.7 Update 1 à partir des versions antérieures de vCenter Server 6.7 peut échouer lorsque vCenter Server High Availability est actif en raison d'un changement apporté au schéma de la base de données. Pour plus d'informations, reportez-vous à l'article 55938 de la base de connaissances VMware.
Solution : pour mettre à niveau votre système vers vCenter Server 6.7 Update 1 à partir de versions antérieures de vCenter Server 6.7, vous devez supprimer vCenter Server High Availability et supprimer les nœuds passif et témoin. Après la mise à niveau, vous devez recréer les clusters vCenter Server High Availability.
- 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.
- La mise à niveau vers vCenter Server Appliance 6.7 Update 1 à partir de vCenter Server Appliance 6.5 Update 2 et versions ultérieures, à l'aide de ports HTTP et HTTPS personnalisés, peut échouer
Les mises à niveau de vCenter Server Appliance 6.5 Update 2 et versions ultérieures, à l'aide de ports HTTP et HTTPS, vers vCenter Server Appliance 6.7 Update 1 peuvent échouer. Vous pouvez rencontrer ce problème quel que soit le programme d'installation de l'interface utilisateur graphique ou de la ligne de commande.
Solution : aucune.
- La convergence d'une instance de Platform Services Controller externe vers un système vCenter Server peut échouer si l'instance de Platform Services Controller utilise un port HTTPS personnalisé
La convergence d'une instance de Platform Services Controller externe vers un système vCenter Server peut échouer si ce dernier est configuré avec le port HTTPS par défaut (443), et que le nœud Platform Services Controller est configuré avec une valeur personnalisée pour le port HTTPS. L'opération échoue lors du premier démarrage en raison de problèmes de convergence.
Solution : modifiez la valeur du port HTTPS par défaut (443) pour les nœuds Platform Services Controller avant d'exécuter l'outil vCenter External to Embedded Convergence Tool (outil de convergence vCenter d'une instance externe vers une instance intégrée). Vous pouvez exécuter les commandes suivantes pour effectuer la même opération :
/usr/lib/vmware-vmafd/bin/vmafd-cli set-dc-port --server-name localhost --dc-port 443/usr/lib/vmware-vmafd/bin/vmafd-cli set-rhttpproxy-port --server-name localhost --rhttpproxy-port 443
- 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 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 Platform Services Controller. 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.
- Il est possible que vSphere Client et vSphere Web Client ne reflètent pas la mise à jour de vCenter Server 6.7 à vCenter Server 6.7 Update 1 pour vCenter Server pour Windows
Si vous mettez à jour vCenter Server pour Windows de vCenter Server 6.7 à vCenter Server 6.7 Update 1, il se peut que les détails du numéro de build pour vpxd dans l'onglet Résumé de vSphere Client et vSphere Web Client ne reflètent pas la mise à jour et affichent la version 6.7.0.
Solution : aucune.
- 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.
- L'interface de gestion du dispositif virtuel peut afficher un message 0 ou une page vide lors de la mise à niveau de vCenter Server 6.7 vers des versions ultérieures
L'interface de gestion du dispositif virtuel peut afficher un message 0 ou une page vide lors de la mise à niveau de vCenter Server 6.7 vers des versions ultérieures, si les appels de l'interface ne parviennent pas à joindre le service applmgmt principal. Le message Impossible d'obtenir l'état d'importation des données historiques. Vérifiez l'état du serveur peut également s'afficher.
Solution : il ne s'agit pas de messages d'échec. Actualisez le navigateur et reconnectez-vous à l'interface de gestion du dispositif virtuel une fois que le redémarrage du dispositif dans le serveur principal est terminé.
- La page Prêt à terminer de l'assistant d'enregistrement de machine virtuelle n'affiche qu'une seule ligne horizontale
Il se peut que la page Prêt à terminer de l'assistant d'enregistrement de machine virtuelle affiche un contenu semblable à une ligne horizontale en raison d'un problème de rendu. Ce problème n'affecte pas le workflow de l'assistant.
Solution : aucune.
- 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.
- Vous ne pouvez pas ajouter des hôtes ESXi exécutant des charges de travail vSphere Fault Tolerance à un système vCenter Server en utilisant vSphere Client
Les tentatives d'ajout d'hôtes ESXi exécutant des charges de travail vSphere Fault Tolerance à un système vCenter Server en utilisant le vSphere Client peut échouer et provoquer l'erreur Impossible d'ajouter un hôte avec des machines virtuelles pour lesquelles Fault Tolerance est activé sur un hôte autonome.
Solution : Vous pouvez également :
- Planifier une tâche pour ajouter l'hôte et l'exécuter immédiatement.
- Dans vSphere Client, accédez à Configurer > Tâches planifiées pour un cluster sélectionné.
- Sélectionnez Nouvelle tâche planifiée > Ajouter un hôte.
- Planifiez une heure pour exécuter la tâche.
- Ajoutez un hôte et exécutez la tâche.
- Supprimez la tâche après l'ajout de l'hôte.
- Utilisez vSphere Web Client pour ajouter l'hôte. Pour cela, connectez-vous à vSphere Web Client et exécutez le workflow standard d'ajout d'un hôte.
- Désactiver temporairement les machines virtuelles de tolérance aux pannes, ajouter l'hôte au nouveau système vCenter Server, puis l'activer à nouveau.
- La configuration du cluster vCenter Server High Availability à l'aide d'un commutateur logique NSX-T peut échouer
La configuration d'un cluster vCenter Server High Availability à l'aide d'un commutateur logique NSX-T peut échouer et provoquer l'erreur Impossible de connecter le nœud de pair.
Solution : Configurez les clusters vCenter Server High Availability à l'aide d'un vSphere Distributed Switch.
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.
- L'importation d'un fichier.csv remplace l'entrée de l'utilisateur lors de la personnalisation de l'hôte
L'entrée de l'utilisateur dans le volet Personnaliser les hôtes est remplacée par le processus d'importation et les valeurs du fichier .csv.
Solution : importez le fichier .csv avant d'ajouter des modifications manuelles dans le volet Personnaliser les hôtes.
- L'outil de convergence de vCenter Server peut échouer à convertir une instance de Platform Services Controller externe en instance de Platform Services Controller intégrée en raison d'un conflit d'adresse IP et de nom de domaine complet
Si vous avez configuré une instance de Platform Services Controller externe avec une adresse IP comme champ de nom de domaine complet facultatif lors du déploiement, l'outil de convergence de vCenter Server peut échouer à convertir l'instance de Platform Services Controller externe en instance de Platform Services Contrôleur intégrée en raison d'un conflit de noms.
Solution : n'utilisez pas l'outil de convergence de vCenter Server pour les instances de Platform Services Controller installées avec une adresse IP comme une alternative ou un ajout à l'adresse de nom de domaine complet.
- Si vous redirigez et reconfigurez le paramétrage d'une instance de Platform Services Controller, le processus de restauration peut échouer
Si vous redirigez et reconfigurez le paramétrage d'une instance de Platform Services Controller, il se peut que le processus de restauration échoue en raison d'une entrée d'ID de service périmée.
Solution : Suivez les étapes décrites dans l'article 2131327 de la base de connaissances VMware pour nettoyer l'ID de service périmé avant de procéder à la restauration.
- Les tentatives de connexion à un système vCenter Server après une mise à niveau vers vCenter Server 6.7 peuvent échouer avec une erreur de validation des informations d'identification
Après une mise à niveau de votre système vers vCenter Server 6.7, si vous essayez de vous connecter au système en utilisant vSphere Web Client ou vSphere Client et un jeton de sécurité ou une carte à puce, la connexion peut échouer et donner lieu à une erreur Impossible de valider les informations d'identification soumises.
Solution : Supprimez et ajoutez à nouveau la source d'identité. Pour plus d'informations, reportez-vous à la section Ajouter ou modifier une source d'identité vCenter Single Sign-On.
- Un cluster EVC (Enhanced vMotion Compatibility) peut afficher les nouveaux ID de CPU, tels qu'IBPB, même si vous rétablissez une version antérieure d'un hôte ESXi
Si vous rétablissez un hôte ESXi vers une ancienne version d'ESXi, un cluster EVC peut présenter de nouveaux ID de CPU, tels qu'IBRS, STIBP et IBPB, même si l'hôte ne comprend aucune de ces fonctionnalités.
Solution : Ce problème est résolu dans cette version. Toutefois, un hôte qui ne répond pas aux exigences d'un cluster EVC ne se reconnecte pas automatiquement et vous devez le supprimer du cluster.
- Certains plug-ins vCenter Server peuvent ne pas restituer correctement le mode de thème sombre dans vSphere Client
Si vous modifiez les modèles de couleurs dans vSphere Client pour afficher l'interface dans un thème sombre, certains plug-ins vCenter Server peuvent ne pas rendre correctement ce mode.
Solution : aucune.
- Si vous activez l'EVC par machine virtuelle, les machines virtuelles peuvent échouer à se mettre sous tension
Si vous installez ou utilisez pour la mise à niveau uniquement VMware vCenter Server 6.7 Update 1, mais n'appliquez pas ESXi 6.7 Update 1, et si vous configurez ou reconfigurez EVC par VM, les machines virtuelles sur des hôtes non corrigés peuvent échouer à se mettre sous tension. Vous pouvez également constater le problème si vous activez l'EVC au niveau du cluster et que la dernière mise à jour n'est pas appliquée à l'un des hôtes du cluster. Les nouveaux ID de CPU du 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 échouer à se mettre sous tension.
Solution : Avant que vous configuriez ou reconfiguriez l'EVC par machine virtuelle, mettez à niveau tous les hôtes ESXi autonomes ainsi que les hôtes d'un cluster vers les mises à jour les plus récentes pour appliquer l'atténuation d'invité assistée par hyperviseur pour les systèmes d'exploitation invités.
- Les modifications apportées aux paramètres DNS peuvent entraîner la suppression de l'adresse de bouclage IPv6 à partir des fichiers /etc/resolv.conf et /etc/systemd/resolved.conf
Les modifications apportées aux paramètres DNS à l'aide de l'Interface de gestion de dispositif, de l'interpréteur de commandes ou vSphere Web Client peuvent entraîner la suppression de l'adresse de bouclage IPv6 à partir des fichiers /etc/resolv.conf et /etc/systemd/resolved.conf.
Solution : pour éviter la suppression de la modification de l'adresse de bouclage IPv6, en boucle, modifiez les fichiers resolv.conf à l'aide de l'interpréteur de commandes Bash :
- Dans le fichier
/etc/resolv.conf, définissez les paramètres suivants :nameserver: ::1
nameserver: <dnsserver 1>
nameserver: <dnsserver 2>
- Dans le fichier
/etc/systemd/resolved.conf, définissez les paramètres suivants :[Resolve]
LLMNR =false
DNS=::1 <dnsserver 1> <dnsserver 2>
- Le service SSH peut être désactivé après la conversion d'une instance de Platform Services Controller externe en instance de Platform Services Controller intégrée.
Si vous convertissez une instance de Platform Services Controller externe en instance de Platform Services Controller intégrée, le service SSH peut être désactivé en fonction des stratégies et des restrictions Active Directory.
Solution : Activez le service SSH manuellement une fois la conversion terminée.
- 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.
- 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
Pour réduire la liste des problèmes connus précédents, cliquez ici.
