- Les vérifications préalables de la mise à niveau ou de la migration vCenter échouent avec « erreur inattendue 87 ».
Les vérifications préalables de la mise à niveau ou de la migration de vCenter Server échouent lorsque le certificat du service de jetons de sécurité (STS) ne contient pas de champ Nom alternatif du sujet (SAN). Cette situation se produit lorsque vous avez remplacé le certificat vCenter 5.5 Single Sign-On par un certificat personnalisé sans champ SAN et que vous tentez d'effectuer la mise à niveau vers vCenter Server 7.0. La mise à niveau considère que le certificat STS n'est pas valide et les vérifications préalables empêchent le processus de mise à niveau de se poursuivre.
Solution : remplacez le certificat STS par un certificat valide qui contient un champ SAN, puis procédez à la mise à niveau ou à la migration de vCenter Server 7.0.
- Problèmes de mise à niveau vers vSphere 7.0 avec des fournisseurs CIM préexistants.
Après la mise à niveau, les fournisseurs CIM 32 bits précédemment installés cessent de fonctionner, car ESXi requiert des fournisseurs CIM 64 bits. Les clients peuvent perdre des fonctions d'API de gestion liées à CIMPDK, NDDK (DDK natif), HEXDK, VAIODK (filtres d'E/S) et des erreurs liées à la dépendance uwglibc peuvent s'afficher.
Le Syslog indique qu'un module est manquant, « bibliothèques 32 bits partagées non chargées ».
Solution : il n'existe pas de solution. Le correctif consiste à télécharger les nouveaux fournisseurs CIM 64 bits à partir de votre fournisseur.
- La mise à niveau vers le correctif vCenter Server 7.0 Update 1 à partir des versions antérieures de vCenter Server 7.x est bloquée lorsque vCenter Server High Availability est activé
La mise à niveau vers le correctif vCenter Server 7.0 Update 1 à partir des versions antérieures de vCenter Server 7.x est bloquée lorsque vCenter Server High Availability est actif.
Solution : pour mettre à niveau votre système vers vCenter Server 7.0 Update 1 à partir de versions antérieures de vCenter Server 7.x, 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 migration d'un système vCenter Server 6.7.x vers vCenter Server 7.x échoue avec un message UnicodeEncodeError
Si vous sélectionnez l'option permettant d'importer toutes les données pour la configuration, l'inventaire, les tâches, les événements et les mesures de performance, la migration d'un système vCenter Server 6.7.x vers vCenter Server 7.x peut échouer pour tout système vCenter Server utilisant des paramètres régionaux non anglais. À l'étape 1 de la phase 2 de la migration, dans vSphere Client, vous voyez une erreur telle que :
Erreur lors de l'exportation des données d'événements et de tâches : …ERROR UnicodeEncodeError: Traceback (most recent call last):
Solution : vous pouvez terminer l'opération de migration en effectuant l'une des opérations suivantes :
- Sélectionnez l'option par défaut Configuration et inventaire à la fin de l'étape 1 de la migration.
Cette option n'inclut pas les données de tâches et d'événements.
- Nettoyez les données dans les tables d'événements et réexécutez la migration.
- Si un système vCenter Server Windows dispose d'un mot de passe de base de données contenant des caractères non-ASCII, les vérifications préalables de l'assistant de migration VMware échouent
Si vous essayez de migrer un système vCenter Server 6.x vers vCenter Server 7.x à l'aide de l'assistant de migration VMware, et si votre système dispose d'un système d'exploitation Windows et utilise une base de données externe avec un mot de passe contenant des caractères non-ASCII, l'opération échoue. Par exemple, Admin!23迁移. Dans la console de l'assistant de migration, le message d'erreur suivant s'affiche :
Erreur : le composant com.vmware.vcdb a échoué avec une erreur interne
Résolution : mise à niveau du fichier Bugzilla PR vers VPX/VPX/vcdb
Solution : aucune.
- Lors d'une mise à jour de vCenter Server 7.x vers vCenter Server 7.0 Update 1, des messages vous invitent à fournir le mot de passe vCenter Single Sign-On
Lors d'une mise à jour de vCenter Server 7.x vers vCenter Server 7.0 Update 1, des messages vous invitent à fournir le mot de passe d'administrateur vCenter Single Sign-On.
Solution : si vous exécutez la mise à jour à l'aide de l'interface de gestion de vCenter Server, vous devez fournir le mot de passe de l'administrateur vCenter Single Sign-On.
Si vous exécutez la mise à jour à l'aide de modules logiciels ou d'une interface de ligne de commande de manière interactive, vous devez fournir de manière interactive le mot de passe de l'administrateur vCenter Single Sign-On.
Si vous exécutez la mise à jour à l'aide de modules logiciels ou d'une interface de ligne de commande en mode non interactif, vous devez fournir le mot de passe de l'administrateur de vCenter Single Sign-On par un fichier de réponses au format
{ "vmdir.password": "Mot de passe SSO de l'utilisateur Administrateur@<DOMAINE SSO>
" }
- L'authentification par carte à puce et RSA SecurID peut cesser de fonctionner après la mise à niveau vers vCenter Server 7.0.
Si vous avez configuré vCenter Server pour l'authentification par carte à puce ou RSA SecurID, consultez l'article de la base de connaissances VMware sur https://kb.vmware.com/s/article/78057 avant de démarrer le processus de mise à niveau de vSphere 7.0. Si vous n'appliquez pas la solution comme décrit dans la base de connaissances, vous pouvez voir les messages d'erreur suivants et l'authentification par carte à puce ou RSA SecurID ne fonctionne pas.
« L'authentification par carte à puce peut cesser de fonctionner. Les paramètres de carte à puce ne sont peut-être pas conservés et l'authentification par carte à puce peut cesser de fonctionner. »
ou
« L'authentification RSA SecurID peut cesser de fonctionner. Les paramètres RSA SecurID ne sont peut-être pas conservés et l'authentification RSA SecurID peut cesser de fonctionner. »
Solution : avant de procéder à la mise à niveau vers vSphere 7.0, reportez-vous à l'article de la base de connaissances VMware sur https://kb.vmware.com/s/article/78057.
- Il est possible que vous ne puissiez pas appliquer ou supprimer NSX lorsque vous ajoutez des hôtes ESXi à l'aide d'une image de vSphere Lifecycle Manager à un cluster dans lequel VMware vSphere High Availability est activé
Si vous démarrez une opération pour appliquer ou supprimer NSX lors de l'ajout de plusieurs hôtes ESXi à l'aide d'une image de vSphere Lifecycle Manager à un cluster dans lequel vSphere HA est activé, les opérations liées à NSX peuvent échouer avec une erreur dans vSphere Client, telle que :
L'agent vSphere HA sur certains hôtes du cluster <nom_cluster> n'est pas l'agent principal vSphere HA et n'est pas non plus connecté à l'agent principal vSphere HA. Vérifiez que la configuration de HA est bonne.
Ce problème se produit, car vSphere Lifecycle Manager configure vSphere HA pour les hôtes ESXi ajoutés au cluster un par un. Si vous exécutez une opération pour appliquer ou supprimer NSX tandis que des opérations de configuration de vSphere HA sont toujours en cours, il est possible que les opérations NSX soient mises en attente entre les opérations de configuration de vSphere HA pour deux hôtes ESXi différents. Dans ce cas, l'opération NSX échoue avec une erreur de contrôle de santé du cluster, car l'état du cluster à ce stade ne correspond pas à l'état attendu de tous les hôtes ESXi sur lesquels vSphere HA est configuré et s'exécute. Plus vous ajoutez d'hôtes ESXi à un cluster en même temps, plus la probabilité que le problème se produise augmente.
Solution : désactivez, puis activez vSphere HA sur le cluster. Poursuivez les opérations pour appliquer ou supprimer NSX.
- Après une mise à niveau d'un système vCenter Server 7.0, vous ne pouvez pas voir les adresses IP des espaces dans l'onglet Résumé de l'espace vSphere de vSphere Client
Si vous mettez à niveau votre système vCenter Server 7.0 vers une version ultérieure, vous ne pouvez plus voir les adresses IP des espaces dans l'onglet Résumé de l'espace vSphere de vSphere Client.
Solution : utilisez les outils de l'interface de ligne de commande Kubernetes pour vSphere afin de vérifier les détails des espaces :
- Copiez, comme condition préalable, les noms de l'espace et de l'espace de noms.
- Utilisez le plug-in de l'interface de ligne de commande pour vSphere pour vérifier les détails de l'espace.
- Connectez-vous au cluster superviseur à l'aide de la commande
kubectl vsphere login --server=https://<adresse_serveur> --vsphere-username <votre nom de compte d'utilisateur> --insecure-skip-tls-verify
- En utilisant les noms copiés à l'étape 1, exécutez les commandes pour récupérer les détails de l'espace :
kubectl config use-context <nom_espace de noms>
et
kubectl describe pod <nom_espace> -n <nom_espace de noms>
Par conséquent, vous pouvez voir l'adresse IP dans une sortie semblable à celle-ci :
$ kubectl describe pod helloworld -n my-podvm-ns ...
Statut : En cours d'exécution
Adresse IP : 10.0.0.10
Adresses IP :
Adresse IP : 10.0.0.10 ...
- La mise à niveau de vCenter Server avec une instance externe de Platform Services Controller de la version 6.7u3 vers la version 7.0 échoue avec une erreur VMAFD.
Lorsque vous mettez à niveau un déploiement de vCenter Server à l'aide d'une instance externe de Platform Services Controller, vous convergez Platform Services Controller vers vCenter Server Appliance. Si la mise à niveau échoue avec l'erreur install.vmafd.vmdir_vdcpromo_error_21, le processus de premier amorçage de VMAFD a échoué. Le processus de premier amorçage de VMAFD copie la base de données du service d'annuaire VMware (data.mdb) à partir de l'instance source de Platform Services Controller et du partenaire de réplication vCenter Server Appliance.
Solution : désactivez TSO (déchargement de segmentation TCP) et GSO (déchargement de segmentation générique) sur l'adaptateur Ethernet de l'instance source de Platform Services Controller ou de l'instance de vCenter Server Appliance du partenaire de réplication avant de mettre à niveau vCenter Server avec une instance externe de Platform Services Controller. Reportez-vous à l'article de la base de connaissances : https://kb.vmware.com/s/article/74678
- Échec des mises à niveau du système vCenter Server lors de l'étape de vérification préalable
Les mises à niveau du système vCenter Server peuvent échouer lors de l'étape de vérification préalable en raison d'une limite dans les connexions d'autorisation (Authz). Dans le fichier /var/log/vmware/vpxd-svcs/vpxd-svcs*.log, les entrées suivantes apparaissent :
Session count for user [after add]: <DOMAIN-NAME>\machine-xxxx is 200
Session limit reached for user: <DOMAIN-NAME>\machine-xxxx with 200 sessions.
La réponse de vSphere Client peut s'afficher en différé pour le chargement de l'inventaire.
Solution : Redémarrez vmware-vpxd-svcs dans votre système vCenter Server à l'aide de la commande service-control --restart vmware-vpxd-svcs. Utilisez la commande uniquement lorsqu'aucune autre activité n'est exécutée dans le système vCenter Server pour éviter toute interruption du workflow. Pour plus d'informations, reportez-vous à l'article 81953 de la base de connaissances VMware.
- La mise à niveau de vCenter Server à l'aide de l'interface de ligne de commande conserve de manière incorrecte la configuration Transport Security Layer (TLS) pour le service vSphere Authentication Proxy.
Si le service vSphere Authentication Proxy (vmcam) est configuré pour utiliser un protocole TLS particulier autre que le protocole TLS 1.2 par défaut, cette configuration est conservée pendant le processus de mise à niveau de l'interface de ligne de commande. Par défaut, vSphere prend en charge le protocole de chiffrement TLS 1.2. Si vous devez utiliser les protocoles TLS 1.0 et TLS 1.1 pour prendre en charge des produits ou des services qui ne prennent pas en charge TLS 1.2, utilisez l'utilitaire TLS Configurator pour activer ou désactiver les différentes versions du protocole TLS.
Solution : utilisez l'utilitaire TLS Configurator pour configurer le port vmcam. Pour savoir comment gérer la configuration du protocole TLS et utiliser l'utilitaire TLS Configurator la documentation Sécurité VMware.
- Les paramètres de carte à puce et de RSA SecurID peuvent ne pas être conservés lors de la mise à niveau de vCenter Server.
L'authentification à l'aide de RSA SecurID ne fonctionnera pas après la mise à niveau vers vCenter Server 7.0. Un message d'erreur vous avertit de ce problème lors de la tentative de connexion à l'aide de votre identifiant RSA SecurID.
Solution : reconfigurez la carte à puce ou RSA SecureID.
- La migration de vCenter Server pour Windows vers vCenter Server Appliance 7.0 échoue avec un message d'erreur réseau.
La migration de vCenter Server pour Windows vers vCenter Server Appliance 7.0 échoue avec le message d'erreur L'adresse IP existe déjà dans le réseau. Cela empêche le processus de migration de configurer les paramètres réseau sur le nouveau dispositif vCenter Server Appliance. Pour plus d'informations, consultez le fichier journal : /var/log/vmware/upgrade/UpgradeRunner.log
Solution :
- vérifiez que toutes les mises à jour Windows ont été effectuées sur le dispositif vCenter Server source pour l'instance de Windows, ou désactivez les mises à jour Windows automatiques jusqu'à la fin de la migration.
- Réexécutez la migration de vCenter Server pour Windows vers vCenter Server Appliance 7.0.
- Lorsque vous configurez le nombre de fonctions virtuelles pour un périphérique SR-IOV à l'aide du paramètre de module max_vfs, les modifications peuvent ne pas prendre effet.
Dans vSphere 7.0, vous pouvez configurer le nombre de fonctions virtuelles pour un périphérique SR-IOV à l'aide de l'API de gestion de l'infrastructure virtuelle (VIM), par exemple via vSphere Client. La tâche ne nécessite pas le redémarrage de l'hôte ESXi. Une fois que vous avez utilisé la configuration de l'API VIM, si vous tentez de configurer le nombre de fonctions virtuelles SR-IOV à l'aide du paramètre du module max_vfs, les modifications peuvent ne pas prendre effet, car elles sont remplacées par la configuration de l'API VIM.
Solution : aucune. Pour configurer le nombre de fonctions virtuelles pour un périphérique SR-IOV, utilisez la même méthode à chaque fois. Utilisez l'API VIM ou utilisez le paramètre du module max_vfs et redémarrez l'hôte ESXi.
- L'instance de vCenter Server Appliance mise à niveau ne conserve pas tous les réseaux secondaires (cartes réseau virtuelles) de l'instance source.
Lors d'une mise à niveau majeure, si l'instance source du dispositif vCenter Server Appliance est configurée avec plusieurs réseaux secondaires autres que les cartes réseau virtuelles VCHA, l'instance de vCenter Server cible ne conserve pas les cartes réseau virtuelles autres que la carte réseau VCHA. Si l'instance source est configurée avec plusieurs cartes réseau virtuelles faisant partie des groupes de ports DVS, la configuration de la carte réseau virtuelle ne sera pas conservée pendant la mise à niveau. Les configurations des instances de vCenter Server Appliance qui font partie du groupe de ports standard seront conservées.
Solution : aucune. Configurez manuellement le réseau secondaire dans l'instance cible de vCenter Server Appliance.
- Après la mise à niveau ou la migration d'un dispositif vCenter Server avec une instance externe de Platform Services Controller, les utilisateurs qui s'authentifient à l'aide d'Active Directory perdent l'accès à l'instance de vCenter Server récemment mise à niveau.
Après la mise à niveau ou la migration d'un dispositif vCenter Server avec une instance externe de Platform Services Controller, si le dispositif vCenter Server récemment mis à niveau n'est pas joint à un domaine Active Directory, les utilisateurs qui s'authentifient à l'aide d'Active Directory perdent l'accès à l'instance de vCenter Server.
Solution : vérifiez que la nouvelle instance de vCenter Server a été jointe à un domaine Active Directory. Reportez-vous à l'article de la base de connaissances : https://kb.vmware.com/s/article/2118543
- La migration d'une instance de vCenter Server pour Windows avec une instance externe de Platform Services Controller à l'aide d'une base de données Oracle échoue.
S'il y a des chaînes non-ASCII dans le tableau des événements et tâches Oracle, la migration peut échouer lors de l'exportation des données d'événements et de tâches. Le message d'erreur suivant s'affiche : UnicodeDecodeError
Solution : aucune.
- Après une mise à niveau de l'hôte ESXi, une vérification de conformité du profil d'hôte indique un état non conforme lorsque les tâches de correction de l'hôte échouent
Un état non conforme indique une incohérence entre le profil et l'hôte.
Cette incohérence peut se produire, car ESXi 7.0 n'autorise pas les règles de réclamation en double, mais le profil que vous utilisez contient des règles en double. Par exemple, si vous tentez d'utiliser le profil d'hôte que vous avez extrait de l'hôte avant la mise à niveau d'ESXi 6.5 ou d'ESXi 6.7 vers la version 7.0, et que le profil d'hôte contient des règles de réclamation en double de règles système par défaut, vous pouvez rencontrer des problèmes.
Solution :
- Supprimez les règles de réclamation en double des règles système par défaut dans le document Profil d'hôte.
- Vérifiez l'état de conformité.
- Corrigez l'hôte.
- Si les étapes précédentes ne vous aident pas, redémarrez l'hôte.
- Un message d'erreur s'affiche dans l'interface de gestion de vCenter Server
Après l'installation ou la mise à niveau vers vCenter Server 7.0, lorsque vous accédez au panneau Mettre à jour dans l'interface de gestion de vCenter Server, le message d'erreur « Vérifiez l'URL et réessayez » s'affiche. Ce message d'erreur ne vous empêche pas d'utiliser les fonctions du panneau Mettre à jour et vous pouvez afficher, transférer et installer les mises à jour disponibles.
Solution : aucune.
- L'application de correctifs à des nœuds témoins ou passifs d'environnements dans lesquels VMware vCenter Server High Availability est activé peut échouer
Dans les environnements dans lesquels vCenter Server High Availability est activé, le correctif d'un nœud témoin ou passif peut échouer avec un message semblable à celui-ci :
RuntimeError: unidentifiable C++ exception.
Solution : désactivez vCenter Server High Availability. Appliquez des correctifs à votre système vCenter Server. Réactivez vCenter Server High Availability.
- Après la correction de votre système vCenter Server vers vCenter Server 7.0.0a, la version par défaut de TLS des clients de stockage VC peut être rétablie
Si vous disposez d'une configuration TLS pour le service des clients de stockage VC autre que la version TLS 1.2 utilisée par défaut, cette version par défaut peut être rétablie après correction de votre système vCenter Server vers vCenter Server 7.0.0a.
Solution : utilisez l'utilitaire de configuration de TLS pour activer ou désactiver les versions de TLS sur votre système vCenter Server après la mise à jour.
- Après la mise à jour de votre système vers vCenter Server 7.0.0b, un vidage de mémoire système s'affiche dans le dossier /var/core
Après la mise à jour de votre système vers vCenter Server 7.0.0b depuis vCenter Server 7.0.0a ou vCenter Server 7.0, le dossier /var/core contient un vidage de mémoire système, tel que core.systemd-journal.393 et core.systemd-udevd.405. Le vidage de mémoire est inoffensif et peut être supprimé.
Solution : aucune.
- Après la mise à jour de votre système vCenter Server vers la version 7.0.0b, la version de vCenter Server n'est pas mise à jour dans l'interface utilisateur de la console directe (DCUI, Direct Console User Interface)
Après la mise à jour de votre système vers vCenter Server 7.0.0b depuis vCenter Server 7.0.0a ou vCenter Server 7.0, vous voyez toujours la version précédente de vCenter Server dans l'interface DCUI.
Solution : pour actualiser la version de vCenter Server après avoir effectué la mise à jour, dans l'interpréteur de commandes du dispositif, exécutez la commande /usr/lib/applmgmt/dcui/notify.
- Échec du planificateur de mise à jour avec l'erreur Le référentiel configuré n'est pas accessible en raison d'une connectivité réseau ou d'une URL incorrecte
Si vous utilisez le planificateur de mise à jour qui fait partie de vSphere Lifecycle Manager afin de faciliter les mises à jour de vCenter Server, l'erreur suivante peut s'afficher dans vSphere Client :
Le référentiel configuré n'est pas accessible en raison d'une connectivité réseau ou d'une URL incorrecte. Vérifiez les paramètres du référentiel.
Ce problème se produit lorsque vous utilisez un référentiel local personnalisé, tel que https:///uploads/dpe/ ou un chemin DBC, pour stocker l'extrait. Si le référentiel personnalisé pour les correctifs basés sur une URL dispose d'une stratégie d'authentification, le planificateur de mise à jour peut ne pas parvenir à extraire la liste des mises à jour disponibles.
Solution : configurez le référentiel personnalisé de sorte que l'authentification ne soit pas nécessaire pour accéder à l'URL du référentiel personnalisé.
- Après la mise à niveau vers vCenter Server 7.0.0b, vous constatez des erreurs vSphere HA sur les clusters basés sur l'image vSphere Lifecycle Manager
Après la mise à niveau vers vCenter Server 7.0.0b, sur les clusters basés sur l'image vSphere Lifecycle Manager configurés avec vSphere HA, des messages d'erreur relatifs à la configuration de vSphere HA s'affichent après la première connexion à l'environnement. Dans vSphere Client, vous voyez les messages :
Impossible de terminer la configuration de l'agent vSphere HA sur cet hôte. ou
Une erreur s'est produite lors de l'application de VIB HA sur le cluster.
Ce problème se produit, car les exportations du dépôt d'image peuvent prendre du temps et entraîner une expiration de la tâche. Le message suivant s'affiche dans /storage/log/vmware/vmware-updatemgr/vum-server/vmware-vum-server.log : Export taking too long (Failure case)
Solution : il s'agit d'un problème temporaire qui se résout dans les 10 minutes suivant l'exécution de l'instance de vCenter Server. Ce problème n'affecte aucune fonctionnalité et vSphere HA fonctionne comme prévu sur les clusters affectés. Toutes les opérations associées aux machines virtuelles, telles que la mise sous tension et la migration, fonctionnent sur les clusters compatibles vSphere HA alors que la récupération de l'erreur est toujours en cours.
- Débit réduit dans les performances de mise en réseau sur les cartes réseau virtuelles Intel 82599/X540/X550.
La nouvelle fonctionnalité de mise en file d'attente de la paire ajoutée au pilote ixgben pour améliorer les performances de mise en réseau sur les cartes réseau virtuelles Intel 82599EB/X540/X550 peut réduire le débit sous certaines charges de travail dans vSphere 7.0 par rapport à vSphere 6.7.
Solution : pour obtenir les mêmes performances de mise en réseau que vSphere 6.7, vous pouvez désactiver la mise en file d'attente de la paire avec un paramètre du module. Pour désactiver la mise en file d'attente de la paire, exécutez la commande suivante :
# esxcli system module parameters set -p "QPair=0,0,0,0..." -m ixgben
Une fois la commande exécutée, procédez au redémarrage.
- Si vous essayez de désactiver vSphere with Tanzu sur un cluster vSphere, l'opération s'arrête et affiche une erreur.
Si certaines machines virtuelles situées à l'extérieur d'un cluster superviseur résident sur l'un des groupes de ports de segment NSX sur le cluster, le script de nettoyage ne peut pas supprimer ces ports ni désactiver vSphere with Tanzu sur le cluster. Dans vSphere Client, vous voyez l'erreur Les demandes de nettoyage envoyées à NSX Manager ont échoué, et l'opération s'arrête à l'état Suppression. Dans le fichier /var/log/vmware/wcp/wcpsvc.log, vous voyez un message d'erreur tel que
Segment path=[...] has x VMs or VIFs attached. Disconnect all VMs and VIFs before deleting a segment.
Solution : supprimez les machines virtuelles indiquées dans le fichier /var/log/vmware/wcp/wcpsvc.log du segment. Attendez que l'opération soit restaurée.
- Après la mise à niveau vers NSX 6.4.7, lorsqu'une adresse IPv6 statique est attribuée à des machines virtuelles de charge de travail sur un réseau IPv6, les machines virtuelles ne parviennent pas à effectuer de test ping de l'interface de passerelle IPv6 du dispositif Edge.
Ce problème se produit après la mise à niveau de vSphere Distributed Switches de la version 6.x vers la version 7.0.
Solution 1 :
sélectionnez le VDS sur lequel tous les hôtes sont connectés, accédez au paramètre Modifier et sous l'option Multidiffusion, sélectionnez basic.
Solution 2 :
ajoutez les règles suivantes sur le pare-feu Edge :
Règle d'autorisation de test ping
Règle d'autorisation du protocole MLD (Multidiffusion Listener Discovery) avec icmp6, tapez 130 (v1) et 143 (v2).
- Les machines virtuelles à débit élevé peuvent subir une dégradation des performances réseau lorsque Network I/O Control (NetIOC) est activé.
Les machines virtuelles qui nécessitent un débit réseau élevé peuvent subir une dégradation du débit lors de la mise à niveau de vSphere 6.7 vers vSphere 7.0 avec NetIOC activé.
Solution : ajustez le paramètre ethernetx.ctxPerDev pour activer plusieurs mondes.
- Le trafic IPv6 ne parvient pas à traverser les ports VMkernel à l'aide d'IPsec.
Lorsque vous migrez des ports VMkernel d'un groupe de ports vers un autre, le trafic IPv6 ne traverse pas les ports VMkernel à l'aide d'IPsec.
Solution : supprimez l'Association de sécurité IPsec du serveur concerné, puis réappliquez l'association de sécurité. Pour en savoir plus sur la définition et la suppression d'une association de sécurité IPsec, reportez-vous à la documentation Sécurité vSphere.
- Les performances du réseau ESX avec une partie d'utilisation du CPU augmentent.
Les performances du réseau ESX peuvent augmenter avec une partie d'utilisation du CPU.
Solution : supprimez et ajoutez l'interface réseau avec uniquement 1 file d'attente répartie pour rx. Par exemple :
esxcli network ip interface remove --interface-name=vmk1
esxcli network ip interface add --interface-name=vmk1 --num-rxqueue=1
- La machine virtuelle peut perdre le trafic Ethernet après l'ajout à chaud, la suppression à chaud ou Storage vMotion
Une machine virtuelle peut cesser de recevoir le trafic Ethernet après un ajout à chaud, une suppression à chaud ou Storage vMotion. Ce problème affecte les machines virtuelles pour lesquelles SR-IOV est activé sur la liaison montante de la vNIC. La carte réseau virtuelle PVRDMA présente ce problème lorsque la liaison montante du réseau virtuel est une carte réseau compatible avec la fonctionnalité RDMA de Mellanox et que les espaces de noms RDMA sont configurés.
Solution : vous pouvez supprimer à chaud et ajouter à chaud les cartes réseau Ethernet affectées de la machine virtuelle pour restaurer le trafic. Sur les systèmes d'exploitation invités Linux, le redémarrage du réseau peut également résoudre le problème. Si ces solutions n'ont aucun effet, vous pouvez redémarrer la machine virtuelle pour restaurer la connectivité réseau.
- La modification de l'adresse IP d'un dispositif VCSA déployé avec une adresse IP statique nécessite que vous ayez créé les enregistrements DNS à l'avance.
Avec l'introduction du DDNS, la mise à jour de l'enregistrement DNS fonctionne uniquement pour les dispositifs VCSA déployés avec la mise en réseau DHCP configurée. Lors de la modification de l'adresse IP de vCenter Server via l'interface VAMI, l'erreur suivante s'affiche :
L'adresse IP spécifiée ne résout pas le nom d'hôte spécifié.
Solution : il existe deux solutions.
- Créez une entrée DNS supplémentaire avec le même nom de domaine complet et l'adresse IP souhaitée. Connectez-vous au interface VAMI et suivez les étapes pour modifier l'adresse IP.
- Connectez-vous au dispositif VCSA à l'aide de SSH. Exécutez le script suivant :
./opt/vmware/share/vami/vami_config_net
Utilisez l'option 6 pour modifier l'adresse IP d'eth0. Une fois les modifications apportées, exécutez le script suivant :
./opt/likewise/bin/lw-update-dns
Redémarrez tous les services sur le dispositif VCSA pour mettre à jour les informations IP sur le serveur DNS.
- La suppression du groupe de ports virtuels distribués NSX (NSX DVPG) peut prendre plusieurs secondes après la suppression du commutateur logique correspondant dans NSX Manager.
Au fur et à mesure que le nombre de commutateurs logiques augmente, la suppression du NSX DVPG dans vCenter Server peut prendre davantage de temps après la suppression du commutateur logique correspondant dans NSX Manager. Dans un environnement avec 12 000 commutateurs logiques, il faut environ 10 secondes pour qu'un NSX DVPG soit supprimé de vCenter Server.
Solution : aucune.
- Hostd manque de mémoire et échoue si de nombreux groupes de ports virtuels distribués NSX sont créés.
Dans vSphere 7.0, les groupes de ports virtuels distribués NSX consomment des quantités de mémoire beaucoup plus grandes que les réseaux opaques. Pour cette raison, les groupes de ports virtuels distribués NSX ne peuvent pas prendre en charge la même échelle qu'un réseau opaque pour une même quantité de mémoire.
Solution : pour prendre en charge l'utilisation de groupes de ports virtuels distribués NSX, augmentez la quantité de mémoire dans vos hôtes ESXi. Si vous vérifiez que votre système dispose de suffisamment de mémoire pour prendre en charge vos machines virtuelles, vous pouvez augmenter directement la mémoire de hostd à l'aide de la commande suivante.
localcli --plugin-dir /usr/lib/vmware/esxcli/int/ sched group setmemconfig --group-path host/vim/vmvisor/hostd --units mb --min 2048 --max 2048
Notez que cela entraînera l'utilisation par hostd de la mémoire normalement réservée aux machines virtuelles de votre environnement. Cela peut avoir pour effet de réduire le nombre de machines virtuelles que votre hôte ESXi peut prendre en charge.
- DRS peut lancer vMotion de manière incorrecte si la réservation réseau est configurée sur une machine virtuelle
Si la réservation réseau est configurée sur une machine virtuelle, il est prévu que DRS migre uniquement la machine virtuelle vers un hôte répondant aux exigences spécifiées. Dans un cluster incluant des nœuds de transport NSX, si certains des nœuds de transport rejoignent la zone de transport par NSX-T Virtual Distributed Switch (N-VDS) et d'autres par vSphere Distributed Switch (VDS) 7.0, DRS peut lancer vMotion de manière incorrecte. Vous pouvez rencontrer ce problème lorsque :
- La machine virtuelle se connecte à un commutateur logique NSX configuré avec une réservation de réseau.
- Certains nœuds de transport rejoignent la zone de transport à l'aide de N-VDS, d'autres par VDS 7.0 ou, les nœuds de transport rejoignent la zone de transport via différentes instances de VDS 7.0.
Solution : faites en sorte que tous les nœuds de transport rejoignent la zone de transport par N-VDS ou la même instance de VDS 7.0.
- Lors de l'ajout d'une NIC VMkernel (vmknic) à un groupe de ports NSX, vCenter Server signale l'erreur « La connexion de l'adaptateur VMKernel à un groupe de ports NSX sur un hôte sans état n'est pas une opération prise en charge. Utilisez le groupe de ports distribués à la place. »
- Pour ESXi sans état sur DVS (Distributed Virtual Switch), la vmknic d'un groupe de ports NSX est bloquée. Vous devez plutôt utiliser un groupe de ports distribués.
- Pour ESXi avec état sur DVS, vmknic sur le groupe de ports NSX est pris en charge, mais vSAN peut rencontrer un problème s'il utilise vmknic sur un groupe de ports NSX.
Solution : utilisez un groupe de ports distribués sur le même DVS.
- Échec potentiel de l'activation de SR-IOV à partir de vCenter pour QLogic 4x10GE QL41164HFCU CNA
Si vous accédez à la boîte de dialogue Modifier les paramètres pour les adaptateurs réseau physiques et que vous tentez d'activer SR-IOV, l'opération peut échouer si vous utilisez QLogic 4x10GE QL41164HFCU CNA. La tentative d'activation de SR-IOV peut entraîner une panne réseau de l'hôte ESXi.
Solution : utilisez la commande suivante sur l'hôte ESXi pour activer SR-IOV :
esxcfg-module
- Les banques de données VMFS ne sont pas montées automatiquement après la suppression à chaud du disque et l'insertion à chaud sur les serveurs HPE Gen10 avec des contrôleurs SmartPQI.
Lorsque des disques SATA sur des serveurs HPE Gen10 avec des contrôleurs SmartPQI sans développeur sont supprimés à chaud et réinsérés à chaud dans une baie de disques différente de la même machine, ou lorsque plusieurs disques sont supprimés à chaud et réinsérés à chaud dans un ordre différent, il arrive parfois qu'un nouveau nom local soit attribué au disque. La banque de données VMFS sur ce disque apparaît sous la forme d'un snapshot et ne sera pas montée automatiquement, car le nom du périphérique a changé.
Solution : aucune. Le contrôleur SmartPQI ne prend pas en charge les opérations de suppression à chaud et d'insertion à chaud non ordonnées.
- ESXi peut mettre fin aux E/S sur les périphériques NVMeOF en raison d'erreurs sur tous les chemins actifs.
Parfois, tous les chemins actifs vers le périphérique NVMeOF enregistrent des erreurs d'E/S en raison de problèmes de liaison ou de l'état du contrôleur. Si l'état de l'un des chemins devient inactif, le plug-in haute performance peut ne pas sélectionner un autre chemin si celui-ci indique un volume d'erreurs élevé. Par conséquent, l'E/S échoue.
Solution : désactivez l'option de configuration /Misc/HppManageDegradedPaths pour débloquer l'E/S.
- La vérification VOMA sur les banques de données VMFS basées sur NVMe échoue avec une erreur.
La vérification VOMA n'est pas prise en charge pour les banques de données VMFS basées sur NVMe et échoue avec l'erreur :
ERROR: Échec de réservation du périphérique. Fonction non implémentée
Exemple :
# voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>
Exécution de VMFS Checker version 2.1 en mode de vérification
Initialisation des métadonnées LVM, vérifications de base terminées
Vérification de l'activité du système de fichiers
Exécution du contrôle de réactivité du système de fichiers..|Analyse de l'activité de l'hôte VMFS-6 (4 096 octets/HB, 1 024 HB).
ERROR: Échec de réservation du périphérique. Fonction non implémentée
Abandon de la vérification du volume VMFS
VOMA n'a pas pu vérifier le périphérique : Erreur générale
Solution : aucune. Si vous devez analyser les métadonnées VMFS, collectez-les à l'aide de l'option -l et passez au support client VMware. La commande de collecte du vidage est la suivante :
voma -l -f dump -d /vmfs/devices/disks/:<partition#>
- L'utilisation de l'API de reconfiguration de machine virtuelle pour attacher un disque de première classe chiffré à une machine virtuelle chiffrée peut échouer avec une erreur.
Si un FCD et une machine virtuelle sont chiffrés avec des clés de chiffrement différentes, vos tentatives pour attacher le FCD chiffré à la machine virtuelle chiffrée à l'aide de l'API de reconfiguration de machine virtuelle peuvent échouer avec le message d'erreur suivant :
Impossible de déchiffrer le disque, car la clé ou le mot de passe est incorrect.
Solution : utilisez l'API attachDisk plutôt que l'API de reconfiguration de machine virtuelle pour attacher un FCD chiffré à une machine virtuelle chiffrée.
- L'hôte ESXi peut ne pas répondre si une extension sans tête de sa banque de données VMFS fractionnée passe à l'état de perte permanente de périphérique (PDL).
Ce problème ne se produit pas lorsqu'une extension hors tête de la banque de données VMFS fractionnée échoue avec l'extension de tête. Dans ce cas, l'intégralité de la banque de données devient inaccessible et n'autorise plus les E/S.
En revanche, lorsque seule une extension sans tête échoue, mais que l'extension de tête reste accessible, le signal de pulsation de la banque de données semble être normal, et les E/S entre l'hôte et la banque de données continuent. Toutefois, toutes les E/S qui dépendent de l'extension hors tête ayant échoué commencent à échouer également. D'autres transactions d'E/S peuvent s'accumuler en attendant la résolution des E/S ayant échoué et entraîner l'absence de réponse de l'hôte.
Solution : corrigez la condition PDL de l'extension hors tête pour résoudre ce problème.
- Après une restauration suite à une condition APD ou PDL, la banque de données VMFS avec prise en charge activée de disques virtuels en cluster reste inaccessible
Vous pouvez rencontrer ce problème uniquement sur les banques de données sur lesquelles la prise en charge des disques virtuels en cluster est activée. Lorsque la banque de données récupère suite à une condition Tous chemins hors service (All Path Down, APD) ou Perte permanente de périphérique (Permanent Device Loss, PDL), elle reste inaccessible. Le journal VMkernel peut afficher plusieurs messages de conflit de réservation SCSI3 similaires aux suivants :
2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: Reservation conflict retries 544 for command 0x45ba814b8340 (op: 0x89) to device "naa.624a9370b97601e346f64ba900024d53"
Ce problème peut se produire, car l'hôte ESXi participant au cluster perd les réservations SCSI pour la banque de données et ne peut pas toujours les acquérir de nouveau automatiquement après la restauration de la banque de données.
Solution : enregistrez manuellement la réservation à l'aide de la commande suivante :
vmkfstools -L registerkey /vmfs/devices/disks/<device name>
où <device name> est le nom du périphérique sur lequel la banque de données est créée.
- Le contrôleur NVMe virtuel est le contrôleur de disque par défaut pour les systèmes d'exploitation invités Windows 10.
Le contrôleur NVMe virtuel est le contrôleur de disque par défaut pour les systèmes d'exploitation invités suivants lors de l'utilisation de la version matérielle 15 ou ultérieure :
Windows 10
Windows Server 2016
Windows Server 2019
Certaines fonctionnalités peuvent ne pas être disponibles lors de l'utilisation d'un contrôleur NVMe virtuel. Pour plus d'informations, reportez-vous à l'article https://kb.vmware.com/s/article/2147714
Remarque : certains clients utilisent la valeur par défaut précédente de LSI Logic SAS. Cela concerne ESXi Host Client et PowerCLI.
Solution : si vous avez besoin de fonctionnalités non disponibles sur le contrôleur NVMe virtuel, basculez vers VMware Paravirtual SCSI (PVSCSI) ou LSI Logic SAS. Pour plus d'informations sur l'utilisation de VMware Paravirtual SCSI (PVSCSI), reportez-vous à https://kb.vmware.com/s/article/1010398
- Après la mise à niveau d'un hôte ESXi vers vSphere 7.0, la présence de règles de réclamation de base en double peut entraîner un comportement inattendu
Les règles de réclamation déterminent quel plug-in de gestion multivoie, tel que NMP, HPP, etc., possède des chemins d'accès à un périphérique de stockage particulier. ESXi 7.0 ne prend pas en charge les règles de réclamation en double. Toutefois, l'hôte ESXi 7.0 ne vous alerte pas si vous ajoutez des règles en double aux règles de réclamation existantes héritées via une mise à niveau d'une version héritée. Du fait de l'utilisation de règles en double, les périphériques de stockage peuvent être réclamés par des plug-ins imprévus, ce qui peut entraîner un résultat inattendu.
Solution : N'utilisez pas de règles de réclamation de base en double. Avant d'ajouter une nouvelle règle de réclamation, supprimez toute règle de réclamation correspondante existante.
- Une requête CNS avec le filtre d'état de conformité défini peut prendre un temps anormalement long.
L'API CNS QueryVolume vous permet d'obtenir des informations sur les volumes CNS, telles que l'état de conformité et de santé des volumes. Lorsque vous vérifiez l'état de conformité des volumes individuels, les résultats sont obtenus rapidement. Toutefois, lorsque vous appelez l'API CNS QueryVolume pour vérifier l'état de conformité de plusieurs volumes, plusieurs dizaines ou centaines, la requête peut s'exécuter lentement.
Solution : évitez d'utiliser les requêtes par lot. Lorsque vous devez obtenir l'état de conformité, interrogez un volume à la fois ou limitez le nombre de volumes dans l'API à 20 requêtes ou moins. Lors de l'utilisation de la requête, évitez d'exécuter d'autres opérations CNS pour obtenir les meilleures performances.
- Nouveau Des volumes CNS supprimés peuvent apparaître temporairement comme existants dans l'interface utilisateur du CNS
Après la suppression d'un disque FCD qui sauvegarde un volume de stockage cloud natif, le volume peut toujours apparaître comme existant dans l'interface utilisateur du stockage cloud natif. Cependant, vos tentatives de suppression du volume échouent. Un message d'erreur similaire au message suivant peut s'afficher :
L'objet ou l'élément indiqué est introuvable.
Solution : La synchronisation complète suivante résoudra l'incohérence et mettra correctement à jour l'interface utilisateur du stockage cloud natif.
- Nouveau Dans certaines circonstances, lorsqu'une opération CNS échoue, l'état de la tâche s'affiche comme étant Réussie dans vSphere Client
Cela peut se produire lorsque, par exemple, vous utilisez une stratégie de stockage incompatible pour créer un volume de stockage cloud natif. L'opération échoue, tandis que vSphere Client indique que l'état de la tâche est réussi.
Solution : l'état de la tâche réussie dans vSphere Client ne garantit pas que l'opération du stockage cloud natif a réussi. Pour vous assurer que l'opération a réussi, vérifiez ses résultats.
- Nouveau Une opération de suppression infructueuse pour un volume CNS persistant peut laisser ce volume non supprimé sur la banque de données vSphere
Ce problème peut se produire lorsque l'API de suppression CNS tente de supprimer un volume persistant qui est toujours attaché à un espace. Par exemple, lorsque vous supprimez l'espace de noms Kubernetes dans lequel l'espace s'exécute. Par conséquent, le volume est effacé de CNS et l'opération de requête CNS ne renvoie pas le volume. Cependant, le volume continue de résider sur la banque de données et ne peut pas être supprimé par le biais d'opérations répétées d'API de suppression CNS.
Solution : aucune.
- La page Skyline Health affiche des caractères corrompus
Dans vSphere Client, lorsque vous accédez à vCenter Server ou que vous sélectionnez un hôte ESXi dans le navigateur de vSphere Client et que vous cliquez sur Surveiller > Skyline Health, la page affiche des caractères corrompus dans les paramètres régionaux suivants : coréen, japonais, allemand et français.
Solution : Passez aux paramètres régionaux anglais.
- Les fournisseurs de distributeur se déconnectent après une modification de l'identifiant réseau principal.
Lorsque vous modifiez l'adresse IP de vCenter (modification de l'identifiant réseau principal), les fournisseurs de distributeur enregistrés se déconnectent.
Solution : réenregistrez les fournisseurs de distributeur.
- La migration entre systèmes vCenter d'une machine virtuelle échoue avec une erreur.
Lorsque vous utilisez des dispositifs vCenter vMotion croisés pour déplacer le stockage et l'hôte d'une machine virtuelle vers une autre instance de vCenter Server, vous pouvez recevoir l'erreur L'opération n'est pas autorisée dans l'état actuel.
Cette erreur apparaît dans l'assistant de l'interface utilisateur après l'étape de sélection de l'hôte et avant l'étape de sélection de la banque de données, dans les cas où la stratégie de stockage attribuée à la machine virtuelle contient des règles basées sur l'hôte, telles que le chiffrement ou toute autre règle de filtre d'E/S.
Solution : attribuez la machine virtuelle et ses disques à une stratégie de stockage sans règles basées sur l'hôte. Vous devrez peut-être déchiffrer la machine virtuelle si la machine virtuelle source est chiffrée. Réexécutez ensuite l'action entre dispositifs vCenter vMotion.
- Les informations sur les capteurs de stockage dans l'onglet santé du matériel affichent des valeurs incorrectes sur l'interface utilisateur de vCenter, l'interface utilisateur de l'hôte et le MOB.
Lorsque vous accédez à Hôte > Surveiller > Santé du matériel > Capteurs de stockage sur l'interface utilisateur vCenter, les informations de stockage affichent des valeurs incorrectes ou inconnues. Le même problème se produit également sur l'interface utilisateur de l'hôte et sur le chemin d'accès au MOB « runtime.hardwareStatusInfo.storageStatusInfo ».
Solution : aucune.
- Les paramètres avancés de l'hôte de l'interface utilisateur vSphere affichent l'emplacement actuel du casier du produit comme étant vide avec une valeur par défaut vide
Les paramètres avancés de l'hôte de l'interface utilisateur vSphere affichent l'emplacement actuel du casier du produit comme étant vide avec une valeur par défaut vide. Cela est incohérent, car l'emplacement réel du produit symlink est créé et valide, ce qui entraîne une confusion pour l'utilisateur. La valeur par défaut ne peut pas être corrigée à partir de l'interface utilisateur.
Solution : l'utilisateur peut utiliser la commande esxcli sur l'hôte pour corriger la valeur par défaut de l'emplacement actuel du casier de produit comme ci-dessous.
1. Supprimez le paramètre d'emplacement du casier de produit existant avec : « esxcli system settings advanced remove -o ProductLockerLocation »
2. Ajoutez à nouveau le paramètre d'emplacement du casier de produit avec la valeur par défaut appropriée :
2.a. Si le dispositif ESXi est une installation complète, la valeur par défaut est « /locker/packages/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/locker/packages/vmtoolsRepo »
2.b. Si le dispositif ESXi est une configuration PXEboot comme autodeploy, la valeur par défaut est : « /vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/vmtoolsRepo »
Exécutez la commande suivante pour déterminer automatiquement l'emplacement : export PRODUCT_LOCKER_DEFAULT=`readlink /productLocker`
Ajoutez le paramètre : esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s $PRODUCT_LOCKER_DEFAULT
Vous pouvez combiner toutes les étapes ci-dessus dans l'étape 2 en émettant la commande unique :
esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s `readlink /productLocker`
- Vous ne pouvez pas ajouter ou modifier un adaptateur réseau existant sur une machine virtuelle
Si vous tentez d'ajouter ou de modifier un adaptateur réseau existant sur une machine virtuelle, la tâche de reconfiguration de la machine virtuelle peut échouer avec une erreur telle que Impossible de terminer l'opération en raison d'une modification simultanée par une autre opération dans vSphere Client. Le fichier /var/log/hostd.log de l'hôte ESXi sur lequel la machine virtuelle s'exécute comporte des journaux tels que :
2020-07-28T07:47:31.621Z verbose hostd[2102259] [Originator@6876 sub=Vigor.Vmsvc.vm:/vmfs/volumes/vsan:526bc94351cf8f42-41153841cab2f9d9/bad71f5f-d85e-a276-4cf6-246e965d7154/interop_l2vpn_vmotion_VM_1.vmx] NIC: connection control message: Failed to connect virtual device 'ethernet0'.
Le fichier vpxa.log comporte des entrées telles que : 2020-07-28T07:47:31.941Z info vpxa[2101759] [Originator@6876 sub=Default opID=opId-59f15-19829-91-01-ed] [VpxLRO] -- ERROR task-138 -- vm-13 -- vim.VirtualMachine.reconfigure: vim.fault.GenericVmConfigFault:
Solution : pour chaque hôte ESXi dans votre cluster, procédez comme suit :
- Connectez-vous à l'hôte ESXi à l'aide de SSH et exécutez la commande
esxcli system module parameters set -a -p dvfiltersMaxFilters=8192 -m dvfilter
- Mettez l'hôte ESXi en mode de maintenance.
- Redémarrez l'hôte ESXi.
Pour plus d'informations, reportez-vous à l'article 80399 de la base de connaissances VMware.
- Les hôtes ESXi 6.5 avec des processeurs AMD Opteron Generation 3 (Greyhound) ne peuvent pas joindre les clusters EVC (Enhanced vMotion Compatibility) AMD REV E ou AMD REV F sur un système vCenter Server 7.0 Update 1
Dans vCenter Server 7.0 Update 1, les services de cluster vSphere, tels que vSphere DRS et vSphere HA, s'exécutent sur des machines virtuelles d'agent ESX pour rendre les services fonctionnellement indépendants de vCenter Server. Toutefois, la ligne de base de CPU pour les processeurs AMD des machines virtuelles d'agent ESX a des instructions POPCNT SSE4A, ce qui empêche les hôtes ESXi 6.5 avec des processeurs AMD Opteron Generation 3 (Greyhound) d'activer le mode EVC AMD REV E et AMD REV F sur un système vCenter Server 7.0 Update 1.
Solution : aucune.
- La section « post-personnalisation » du script de personnalisation s'exécute avant la personnalisation de l'invité.
Lorsque vous exécutez le script de personnalisation de l'invité pour un système d'exploitation invité Linux, la section pré-personnalisation du script de personnalisation qui est défini dans la spécification de personnalisation s'exécute avant la personnalisation de l'invité et la section post-personnalisation s'exécute ensuite. Si vous activez Cloud-Init dans le système d'exploitation invité d'une machine virtuelle, la section post-personnalisation s'exécute avant la personnalisation en raison d'un problème connu dans Cloud-Init.
Solution : désactivez Cloud-Init et utilisez la personnalisation de l'invité standard.
- Les opérations de migration de groupe dans vSphere vMotion, Storage vMotion et vMotion sans stockage partagé échouent avec une erreur
Lorsque vous effectuez des opérations de migration de groupe sur des machines virtuelles avec plusieurs disques et des snapshots à plusieurs niveaux, les opérations peuvent échouer avec l'erreur com.vmware.vc.GenericVmConfigFault n'a pas pu attendre les données. Erreur 195887167. Connexion fermée par l'hôte distant, probablement en raison d'une expiration du délai.
Solution : réexécutez l'opération de migration sur les machines virtuelles ayant échoué, une à la fois.
- Le déploiement d'un modèle OVF ou OVA à partir d'une URL échoue avec une erreur Interdit 403.
Les URL qui contiennent un paramètre de requête HTTP ne sont pas prises en charge. Par exemple, http://webaddress.com?file=abc.ovf ou les URL S3 pré-signées par Amazon.
Solution : téléchargez les fichiers et déployez-les à partir de votre système de fichiers local.
- L'importation ou le déploiement de fichiers OVF locaux contenant des caractères non-ASCII dans leur nom peut échouer avec une erreur.
Lorsque vous importez des fichiers .ovf locaux contenant des caractères non-ASCII dans leur nom, vous pouvez recevoir Erreur de requête incorrecte 400. Lorsque vous utilisez des fichiers .ovf pour déployer une machine virtuelle dans vSphere Client, le processus de déploiement s'arrête à 0 %. Par conséquent, vous pouvez recevoir Erreur de requête incorrecte 400 ou Erreur de serveur interne 500.
Solution :
- supprimez les caractères non-ASCII des noms de fichier
.ovf et .vmdk.
- Pour modifier le fichier
.ovf, ouvrez-le avec un éditeur de texte.
- Recherchez le nom de fichier de
.vmdk non-ASCII et remplacez-le par un nom ASCII.
- Importez ou déployez de nouveau les fichiers enregistrés.
- Nouveau Le troisième niveau d'objets imbriqués dans un dossier de machine virtuelle n'est pas visible
Procédez comme suit :
- Accédez à un centre de données et créez un dossier de machine virtuelle.
- Dans le dossier de la machine virtuelle, créez un dossier de machine virtuelle imbriqué.
- Dans le deuxième dossier, créez une autre machine virtuelle imbriquée, un dossier de machine virtuelle, un vApp ou un modèle de machine virtuelle.
Par exemple, dans l'arborescence de l'inventaire VM et modèles, vous ne pouvez pas voir les objets dans le troisième dossier imbriqué.
Solution : pour afficher les objets dans le troisième dossier imbriqué, accédez au second dossier imbriqué et sélectionnez l'onglet VM.
- Échec des opérations de services de fichiers vSAN sur les clusters compatibles vSphere Lifecycle Manager
Lors d'une modification de l'état d'un hôte ESXi, les opérations de services de fichiers vSAN peuvent échouer sur les clusters compatibles vSphere Lifecycle Manager en raison d'une condition de concurrence avec vSphere ESX Agent Manager (EAM). Le problème survient pendant les mises à niveau et certaines opérations, telles que la mise sous tension ou hors tension, le démarrage ou lorsque l'hôte quitte le mode de maintenance ou de veille. La condition de concurrence se produit lorsqu'un point de terminaison n'est pas disponible avant la modification de l'état de l'hôte ESXi. Dans ce cas, EAM démarre un processus de correction qui ne peut pas être résolu et les opérations provenant d'autres services, tels que les services de fichiers vSAN, échouent.
Solution : redémarrez vSphere ESX Agent Manager.
- Vous ne pouvez pas activer NSX-T sur un cluster déjà activé pour gérer la configuration et les mises à jour d'images sur tous les hôtes collectivement.
NSX-T n'est pas compatible avec la fonctionnalité de vSphere Lifecycle Manager pour la gestion des images. Lorsque vous activez collectivement un cluster pour la configuration et les mises à jour d'images sur tous les hôtes du cluster, vous ne pouvez pas activer NSX-T sur ce cluster. Toutefois, vous pouvez déployer des dispositifs NSX Edge sur ce cluster.
Solution : déplacez les hôtes vers un nouveau cluster que vous pouvez gérer avec des lignes de base et activez NSX-T sur ce nouveau cluster.
- vSphere Lifecycle Manager et les services de fichiers vSAN ne peuvent pas être activés simultanément sur un cluster vSAN dans vSphere 7.0
Si vSphere Lifecycle Manager est activé sur un cluster, les services de fichiers vSAN ne peuvent pas être activés sur le même cluster et vice versa. Afin d'activer vSphere Lifecycle Manager sur un cluster sur lequel les services de fichiers vSAN sont déjà activés, désactivez d'abord les services de fichiers vSAN et recommencez l'opération. Notez que si vous effectuez une transition vers un cluster géré par une seule image, vSphere Lifecycle Manager ne peut pas être désactivé sur ce cluster.
Solution : aucune.
- Lorsqu'un gestionnaire de support matériel n'est pas disponible, la fonctionnalité de vSphere High Availability (HA) est affectée
Si le gestionnaire de support matériel n'est pas disponible pour un cluster que vous gérez avec une seule image, dans laquelle un complément de microprogramme et de pilotes est sélectionné et où vSphere HA est activé, la fonctionnalité vSphere HA est affectée. Les erreurs suivantes peuvent se produire.
- Échec de la configuration de vSphere HA sur un cluster.
- Impossible de terminer la configuration de l'agent vSphere HA sur cet hôte :
Une erreur s'est produite lors de l'application de VIB HA sur le cluster.
- La correction de vSphere HA échoue :
Une erreur système générale s'est produite : impossible d'accéder à un mappage de composants effectif.
- La désactivation de vSphere HA échoue : échec de la tâche de suppression de la solution.
Une erreur système générale s'est produite : le module de support matériel est introuvable à partir du dépôt ou du gestionnaire de support matériel.
Solution :
- si le gestionnaire de support matériel est temporairement indisponible, procédez comme suit.
- Reconnectez le gestionnaire de support matériel à l'instance de vCenter Server.
- Sélectionnez un cluster dans le menu Hôtes et cluster.
- Sélectionnez l'onglet Configurer.
- Sous Services, cliquez sur Disponibilité vSphere.
- Réactivez vSphere HA.
- Si le gestionnaire de support matériel est définitivement indisponible, procédez comme suit.
- Supprimez le gestionnaire de support matériel et le module de support matériel de la spécification de l'image.
- Réactivez vSphere HA.
- Sélectionnez un cluster dans le menu Hôtes et cluster.
- Sélectionnez l'onglet Mises à jour.
- Cliquez sur Modifier.
- Supprimez le complément de microprogramme et de pilotes, puis cliquez sur Enregistrer.
- Sélectionnez l'onglet Configurer.
- Sous Services, cliquez sur Disponibilité vSphere.
- Réactivez vSphere HA.
- I/OFilter n'est pas supprimé d'un cluster après un processus de correction dans vSphere Lifecycle Manager
La suppression d'I/OFilter d'un cluster en corrigeant le cluster dans vSphere Lifecycle Manager échoue avec le message d'erreur suivant : Le filtre iofilter XXX existe déjà. Le filtre iofilter reste répertorié comme étant installé.
Solution :
- appelez l'API IOFilter
UninstallIoFilter_Task à partir de l'objet géré vCenter Server (IoFilterManager).
- Corrigez le cluster dans vSphere Lifecycle Manager.
- Appelez l'API IOFilter
ResolveInstallationErrorsOnCluster_Task à partir de l'objet géré par vCenter Server (IoFilterManager) pour mettre à jour la base de données.
- Lors de la correction d'un cluster activé pour vSphere HA dans vSphere Lifecycle Manager, la désactivation et la réactivation de vSphere HA provoquent un état d'erreur de vSphere HA
La désactivation et la réactivation de vSphere HA au cours du processus de correction d'un cluster peuvent entraîner l'échec du processus de correction en raison des rapports sur les contrôles de santé de vSphere HA signalant que les VIB vSphere HA ne sont pas installés sur les hôtes. Le message d'erreur suivant peut s'afficher : La définition de la spécification d'image souhaitée pour le cluster a échoué.
Solution : une fois l'opération de correction de cluster terminée, désactivez et réactivez vSphere HA pour le cluster.
- La vérification des images recommandées dans vSphere Lifecycle Manager présente des performances ralenties dans les clusters de grande taille.
Dans les clusters de grande taille comportant plus de 16 hôtes, la tâche de génération de recommandations peut prendre plus d'une heure pour s'achever ou sembler se bloquer. La date de fin de la tâche de la tâche de recommandation dépend du nombre de périphériques configurés sur chaque hôte et du nombre de candidats d'image du dépôt que vSphere Lifecycle Manager doit traiter avant d'obtenir une image valide à recommander.
Solution : aucune.
- La vérification de la compatibilité matérielle dans vSphere Lifecycle Manager présente des performances ralenties dans les clusters de grande taille.
Dans les clusters de grande taille comportant plus de 16 hôtes, la tâche de génération des rapports de validation peut prendre jusqu'à 30 minutes ou sembler se bloquer. La durée d'exécution dépend du nombre de périphériques configurés sur chaque hôte et du nombre d'hôtes configurés dans le cluster.
Solution : aucune.
- Des messages d'erreur incomplets dans des langues autres que l'anglais s'affichent lorsque vous corrigez un cluster dans vSphere Lifecycle Manager.
Des messages d'erreur incomplets peuvent s'afficher pour les langues localisées dans l'interface utilisateur de vCenter Server. Les messages s'affichent après l'échec d'un processus de correction de cluster dans vSphere Lifecycle Manager. Par exemple, vous pouvez observer le message d'erreur suivant.
Le message d'erreur en langue anglaise : Virtual machine 'VMC on DELL EMC -FileServer' that runs on cluster 'Cluster-1' reported an issue which prevents entering maintenance mode: Impossible d'accéder à la configuration de la machine virtuelle : Impossible d'accéder au fichier [local-0] VMC on Dell EMC-FileServer/VMC on Dell EMC-FileServer.vmx
Le message d'erreur en langue française : La VM « VMC on DELL EMC -FileServer », située sur le cluster « {Cluster-1} », a signalé un problème empêchant le passage en mode de maintenance : Impossible d'accéder à la configuration de la machine virtuelle : Impossible d'accéder au fichier [local-0] VMC on Dell EMC-FileServer/VMC on Dell EMC-FileServer.vmx
Solution : aucune.
- Lorsque vous convertissez un cluster qui utilise des lignes de base en un cluster qui utilise une seule image, un avertissement s'affiche indiquant que les VIB vSphere HA seront supprimés.
La conversion d'un cluster activé pour vSphere HA qui utilise des lignes de base en un cluster qui utilise une seule image peut entraîner l'affichage d'un message d'avertissement indiquant que le composant vmware-fdm sera supprimé.
Solution : vous pouvez ignorer ces messages. Le processus de conversion installe le composant vmware-fdm.
- Si vSphere Update Manager est configuré pour télécharger des mises à jour de correctifs à partir d'Internet via un serveur proxy, après la mise à niveau vers vSphere 7.0 qui convertit Update Manager en vSphere Lifecycle Manager, le téléchargement de correctifs à partir du référentiel de correctifs de VMware peut échouer.
Dans les versions antérieures de vCenter Server vous pouviez configurer des paramètres de proxy indépendants pour les dispositifs vCenter Server et vSphere Update Manager. Après une mise à niveau vers vSphere 7.0, vSphere Update Manager service devient partie intégrante du service Lifecycle Manager vSphere. Pour le service de vSphere Lifecycle Manager, les paramètres de proxy sont configurés à partir des paramètres de vCenter Server Appliance. Si vous avez configuré Update Manager pour télécharger des mises à jour de correctifs à partir d'Internet via un serveur proxy, mais que vCenter Server Appliance ne disposait pas d'une configuration de paramètre de proxy, après une mise à niveau de vCenter Server vers la version 7.0, vSphere Lifecycle Manager ne parvient pas à se connecter au dépôt de VMware et ne parvient pas à télécharger les correctifs ou les mises à jour.
Solution : connectez-vous à l'interface de gestion de vCenter Server Appliance, https://vcenter-server-appliance-FQDN-or-IP-address:5480, pour configurer les paramètres de proxy pour le dispositif vCenter Server Appliance et activer vSphere Lifecycle Manager pour utiliser le proxy.
- Si vous utilisez un client Java pour vérifier les tâches de correction, vous ne pouvez pas extraire les résultats des opérations de correction
Si vous utilisez un client Java pour vérifier les tâches de correction, l'extraction des résultats peut échouer avec une erreur ConstraintValidationException. Ce problème se produit lorsqu'un hôte ESXi ne parvient pas à passer en mode de maintenance lors de la correction et qu'il obtient un état IGNORÉ, mais qu'il obtient en même temps un indicateur de progression pour les opérations de correction consécutives. Cela provoque l'erreur ConstraintValidationException sur les clients Java, et vous ne pouvez pas extraire le résultat de l'opération de correction.
Solution : corrigez les problèmes sous-jacents qui empêchent les hôtes ESXi d'entrer en mode de maintenance et relancez l'opération de correction.
- Le dépôt vSphere général Lifecycle Manager général et les dépôts locaux dans les déploiements de bureaux distants et de succursales (ROBO) peuvent ne pas être synchronisés
Les clusters ROBO disposant d'un accès limité ou sans accès à Internet ou d'une connectivité limitée à vCenter Server peuvent télécharger une image à partir d'un dépôt local pour eux au lieu d'accéder au dépôt vSphere Lifecycle Manager dans vCenter Server. Toutefois, vSphere Lifecycle Manager génère des recommandations logicielles sous la forme d'images pré-validées uniquement à un niveau central et un contenu d'image recommandé peut ne pas être disponible lors d'un remplacement de dépôt.
Solution : si vous décidez d'utiliser une image recommandée, assurez-vous que le contenu entre les remplacements de dépôts et le dépôt central est synchronisé.
- La correction de cluster à l'aide de vSphere Lifecycle Manager peut échouer sur les hôtes ESXi avec le mode de verrouillage activé
Si un cluster inclut des hôtes ESXi pour lesquels le mode de verrouillage est activé, il se peut que les opérations de correction à l'aide de vSphere Lifecycle Manager ignorent ces hôtes. Dans les fichiers journaux, des erreurs semblables aux messages suivants s'affichent : Host scan task failed et com.vmware.vcIntegrity.lifecycle.EsxImage.UnknownError An unknown error occurred while performing the operation..
Solution : Ajoutez l'utilisateur racine à la liste d'exceptions pour le mode de verrouillage et procédez à une nouvelle tentative de correction du cluster.
- Après la mise à niveau vers vCenter Server 7.0.0b, dans la vue d'accueil de vSphere Lifecycle Manager dans vSphere Client, le bouton bascule Afficher uniquement les mises à jour cumulées ne s'affiche pas
Dans vCenter Server 7.0.0b, vous pouvez utiliser le bouton bascule Afficher uniquement les mises à jour cumulées pour filtrer et sélectionner les correctifs que vous souhaitez inclure dans une ligne de base lorsque vous utilisez vSphere Lifecycle Manager.
Le bouton est disponible sous l'onglet Mises à jour du volet Lifecycle Manager, Menu > Lifecycle Manager, qui est la vue d'accueil de vSphere Lifecycle Manager dans vSphere Client. Le bouton est également disponible sur la page Sélectionner les correctifs manuellement sous l'onglet Lignes de base de l'assistant Créer une ligne de base, qui s'ouvre lorsque vous sélectionnez Nouveau > Ligne de base.
Toutefois, le bouton Afficher uniquement les mises à jour cumuléespeut ne pas s'afficher après la mise à niveau vers vCenter Server 7.0.0b.
Solution : après une mise à niveau vers vCenter Server 7.0.0b, redémarrez vSphere Client. Pour plus d'informations, consultez Démarrer, arrêter et redémarrer les services.
- Le bouton bascule Afficher uniquement les mises à jour cumulées est toujours activé lorsque vous ouvrez un onglet dans la vue d'accueil de vSphere Lifecycle Manager dans vSphere Client
Dans vCenter Server 7.0.0b, vous pouvez utiliser le bouton bascule Afficher uniquement les mises à jour cumulées pour filtrer et sélectionner les correctifs que vous souhaitez inclure dans une ligne de base lorsque vous utilisez vSphere Lifecycle Manager.
Le bouton est disponible sous l'onglet Mises à jour du volet Lifecycle Manager, Menu > Lifecycle Manager, qui est la vue d'accueil de vSphere Lifecycle Manager dans vSphere Client. Le bouton est également disponible sur la page Sélectionner les correctifs manuellement sous l'onglet Lignes de base de l'assistant Créer une ligne de base, qui s'ouvre lorsque vous sélectionnez Nouveau > Ligne de base.
Cependant, ce bouton est toujours activé lorsque vous accédez à l'onglet Mises à jour ou à la page Sélectionner les correctifs manuellement. Même si vous le désactivez lorsque vous quittez l'onglet ou la page, il est toujours activé lors de l'ouverture suivante.
Solution : aucune.
- Lorsque vous utilisez le planificateur de mise à jour, dans vSphere Client, vous pouvez voir l'erreur Une erreur inattendue s'est produite lors de la récupération des mises à jour
Lorsque vous utilisez le planificateur de mise à jour qui fait partie de vSphere Lifecycle Manager afin de faciliter les mises à jour de vCenter Server, l'erreur suivante peut s'afficher dans vSphere Client :
Une erreur inattendue s'est produite lors de la récupération des mises à jour
Ce problème survient lorsque vous utilisez un port HTTPS personnalisé qui vous empêche d'exécuter des rapports d'interopérabilité à l'aide de vSphere Client.
Solution : appelez manuellement l'API. Pour plus d'informations, reportez-vous à la section API de vSphere Automation.
- Lors de l'application d'un profil d'hôte avec la version 6.5 à un hôte ESXi avec la version 7.0, la vérification de conformité échoue.
L'application d'un profil d'hôte avec la version 6.5 à un hôte ESXi avec la version 7.0 entraîne le signalement du profil de fichier coredump comme non conforme à l'hôte.
Solution : il existe deux solutions.
- Lorsque vous créez un profil d'hôte avec la version 6.5, définissez une option de configuration avancée VMkernel.Boot.autoCreateDumpFile sur false sur l'hôte ESXi.
- Lorsque vous appliquez un profil d'hôte existant avec la version 6.5, ajoutez une option de configuration avancée VMkernel.Boot.autoCreateDumpFile dans le profil d'hôte, configurez l'option sur une stratégie fixe et définissez la valeur sur false.
- Le menu déroulant Actions ne contient aucun élément lorsque votre navigateur est défini sur une langue autre que l'anglais.
Lorsque votre navigateur est défini sur la langue autre que l'anglais et que vous cliquez sur le bouton Basculer vers la nouvelle vue à partir de l'onglet Résumé de la machine virtuelle de l'inventaire vSphere Client, le menu déroulant Actions du panneau SE invité ne contient aucun articles.
Solution : sélectionnez le menu déroulant Actions en haut de la page de la machine virtuelle.
- Les pilotes ESXi natifs ConnectX-4 ou ConnectX-5 de Mellanox peuvent présenter une dégradation mineure du débit lorsque la fonctionnalité Dynamic Receive Side Scaling (DYN_RSS) ou Generic RSS (GEN_RSS) est activée.
Les pilotes ESXi natifs ConnectX-4 ou ConnectX-5 de Mellanox peuvent présenter moins de 5 % de dégradation du débit lorsque les fonctionnalités DYN_RSS et GEN_RSS sont activées, ce qui est peu susceptible d'affecter les charges de travail normales.
Solution : vous pouvez désactiver les fonctionnalités DYN_RSS et GEN_RSS à l'aide des commandes suivantes :
# esxcli system module parameters set -m nmlx5_core -p "DYN_RSS=0 GEN_RSS=0"
# reboot
- Le trafic RDMA entre deux machines virtuelles sur le même hôte peut échouer dans l'environnement PVRDMA.
Dans une implémentation vSphere 7.0 d'un environnement PVRDMA, les machines virtuelles acheminent le trafic via le HCA pour la communication locale si un HCA est présent. Toutefois, le bouclage du trafic RDMA ne fonctionne pas sur le pilote qedrntv. Par exemple, les paires RDMA mises en file d'attente exécutées sur des machines virtuelles qui sont configurées sous le même port de liaison montante ne peuvent pas communiquer entre elles.
Dans vSphere 6.7 et versions antérieures, le HCA a été utilisé pour le trafic RDMA local si le SRQ était activé. vSphere 7.0 utilise le bouclage HCA avec des machines virtuelles utilisant des versions de PVRDMA sur lesquelles SRQ est activé avec une version matérielle minimale de v14 utilisant le protocole RoCE v2.
La version actuelle du microprogramme de l'adaptateur Marvell FastLinQ ne prend pas en charge le trafic de bouclage entre les paires mises en file d'attente du même PF ou port.
Solution : la prise en charge requise est ajoutée dans le pilote prédéfini certifié pour vSphere 7.0. Si vous utilisez le pilote qedrntv de boîte de réception, vous devez utiliser une configuration à 3 hôtes et migrer les machines virtuelles vers le troisième hôte.
- Limitations des paires mises en file d'attente (QP) du trafic datagramme non fiable dans le pilote qedrntv.
Il existe des limitations avec le pilote Marvell FastLinQ qedrntv RoCE et le trafic datagramme non fiable (UD). Les applications UD qui impliquent le trafic en masse peuvent échouer avec le pilote qedrntv. En outre, les paires UD mises en file d'attente peuvent uniquement fonctionner avec des régions de mémoire (MR) DMA. Les MR ou FRMR physiques ne sont pas prises en charge. Les applications tentant d'utiliser des MR ou FRMR physiques avec des paires UD mises en file d'attente ne parviennent pas à transmettre le trafic lorsqu'elles sont utilisées avec le pilote qedrntv. Les exemples connus de ces applications de test sont ibv_ud_pingpong et ib_send_bw.
Les cas d'utilisation standard RoCE et RoCEv2 dans un environnement ESXi VMware tel que iSER, NVMe-oF (RoCE) et PVRDMA ne sont pas affectés par ce problème. Les cas d'utilisation pour le trafic UD sont limités et ce problème affecte un petit ensemble d'applications nécessitant un trafic UD en masse.
Le matériel Marvell FastLinQ ne prend pas en charge le déchargement du trafic UD RDMA. Pour répondre aux exigences de VMware PVRDMA pour la prise en charge de GSI QP, une mise en œuvre limitée par logiciel uniquement de la prise en charge de la fonction UD QP a été ajoutée au pilote qedrntv. L'objectif de la mise en œuvre est de fournir la prise en charge de la communication GSI de chemin de contrôle et n'est pas une implémentation complète d'UD QP prenant en charge le trafic en masse et les fonctionnalités avancées.
Étant donné que la prise en charge de la fonction UD est implémentée dans le logiciel, l'implémentation peut ne pas suivre le trafic intense et des paquets peuvent être abandonnés. Cela peut entraîner des échecs avec le trafic UD en masse.
Solution : le trafic UD QP en masse n'est pas pris en charge avec le pilote qedrntv et il n'existe aucune solution à ce stade. Les cas d'utilisation RDMA de VMware ESXi (RoCE), tels que iSER, NVMe, RDMA et PVRDMA, ne sont pas affectés par ce problème.
- Les serveurs équipés de la carte réseau QLogic 578xx peuvent échouer lorsque vous connectez ou déconnectez fréquemment des LUN iSCSI
Si vous déclenchez fréquemment une connexion iSCSI de carte réseau QLogic 578xx ou une déconnexion en peu de temps, le serveur peut échouer en raison d'un problème avec le pilote qfle3. Cela est dû à un défaut connu dans le microprogramme du périphérique.
Solution : aucune.
- ESXi peut échouer lors du déchargement du pilote ou de l'opération de déconnexion du contrôleur dans un environnement Broadcom NVMe over FC.
Dans l'environnement Broadcom NVMe over FC, ESXi peut échouer lors du déchargement du pilote ou de l'opération de déconnexion du contrôleur et afficher un message d'erreur tel que : @BlueScreen: #PF Exception 14 dans le monde 2098707:vmknvmeGener IP 0x4200225021cc addr 0x19
Solution : aucune.
- ESXi n'affiche pas le numéro de version du microprogramme OEM des cartes réseau i350/X550 sur certains serveurs Dell.
Le pilote ixgben de boîte de réception reconnaît uniquement la version des données de microprogramme ou la signature des cartes réseau i350/X550. Sur certains serveurs Dell, le numéro de version du microprogramme OEM est programmé dans la région de la version du module OEM et le pilote ixgben de boîte de réception ne lit pas ces informations. Seule la signature du microprogramme à 8 chiffres s'affiche.
Solution : pour afficher le numéro de version du microprogramme OEM, installez la version 1.7.15 ou ultérieure du pilote ixgben asynchrone.
- Les cartes réseau X710 ou XL710 peuvent échouer dans ESXi.
Lorsque vous lancez certaines opérations destructrices sur des cartes réseau X710 ou XL710, telles que la réinitialisation de la carte réseau ou la manipulation de l'arborescence de périphériques interne de VMKernel, le matériel de la carte réseau peut lire des données de la mémoire non constituée de paquets.
Solution : ne réinitialisez pas la carte réseau ou ne manipulez pas l'état du périphérique interne VMkernel.
- NVMe-oF ne garantit pas le nom VMHBA persistant après le redémarrage du système
NVMe-oF est une nouvelle fonctionnalité de vSphere 7.0. Si votre serveur dispose d'une installation de stockage USB qui utilise vmhba30+ et dispose également de la configuration NVMe over RDMA, le nom VMHBA peut changer après un redémarrage du système. Cela est dû au fait que l'attribution de nom VMHBA pour NVMe over RDMA est différente des périphériques PCIe. ESXi ne garantit pas la persistance.
Solution : aucune.
- Échec de la sauvegarde pour une taille de base de données vCenter de 300 Go ou plus
Si la taille de la base de données vCenter est de 300 Go ou plus, la sauvegarde basée sur fichier échoue avec un délai d'expiration. Le message d'erreur suivant s'affiche : Délai expiré ! L'opération ne s'est pas terminée dans le délai de 72 000 secondes.
Solution : aucune.
- Une restauration de vCenter Server 7.0 qui est mise à niveau depuis vCenter Server 6.x avec une instance externe de Platform Services Controller vers vCenter Server 7.0 peut échouer
Lorsque vous restaurez une instance de vCenter Server 7.0 mise à niveau de la version 6.x incluant une instance externe de Platform Services Controller vers vCenter Server 7.0, la restauration peut échouer et afficher l'erreur suivante : Échec de la récupération de la liste de stockage du dispositif.
Solution : pendant la première étape du processus de restauration, augmentez le niveau de stockage de vCenter Server 7.0. Par exemple, si le type de stockage de la configuration externe de Platform Services Controller de vCenter Server 6.7 est petit, sélectionnez le type de stockage grand pour le processus de restauration.
- Le paramètre de configuration des protocoles SSL activé n'est pas configuré lors du processus de correction d'un profil d'hôte.
Le paramètre de configuration des protocoles SSL activés ne sont pas configurés lors de la correction d'un profil d'hôte et seul le protocole par défaut du système tlsv1.2 est activé. Ce comportement est observé pour un profil d'hôte avec la version 7.0 et les versions antérieures dans un environnement vCenter Server 7.0.
Solution : pour activer les protocoles SSL TLSV 1.0 ou TLSV 1.1 pour SFCB, connectez-vous à un hôte ESXi à l'aide de SSH, puis exécutez la commande ESXCLI suivante : esxcli system wbem -P <protocol_name>
- Impossible de configurer les paramètres du mode de verrouillage à l'aide des profils d'hôte.
Le mode de verrouillage ne peut pas être configuré à l'aide d'un profil d'hôte de sécurité et ne peut pas être appliqué à plusieurs hôtes ESXi à la fois. Vous devez configurer manuellement chaque hôte.
Solution : Dans vCenter Server 7.0, vous pouvez configurer le mode de verrouillage et gérer la liste des utilisateurs avec exception en mode de verrouillage à l'aide d'un profil d'hôte de sécurité.
- Lorsqu'un profil d'hôte est appliqué à un cluster, les paramètres Enhanced vMotion Compatibility (EVC) sont manquants dans les hôtes ESXi.
Certains paramètres du fichier de configuration de VMware /etc/vmware/config ne sont pas gérés par les profils d'hôte et sont bloqués lorsque le fichier de configuration est modifié. Par conséquent, lorsque le profil d'hôte est appliqué à un cluster, les paramètres EVC sont perdus, ce qui entraîne la perte des fonctionnalités EVC. Par exemple, les CPU non masqués peuvent être exposés aux charges de travail.
Solution : reconfigurez la ligne de base EVC pertinente sur le cluster pour récupérer les paramètres EVC.
- L'utilisation d'un profil d'hôte qui définit une partition de vidage de mémoire dans vCenter Server 7.0 génère une erreur.
Dans vCenter Server 7.0, la configuration et la gestion d'une partition de vidage de mémoire dans un profil d'hôte ne sont pas disponibles. La tentative d'application d'un profil d'hôte qui définit une partition de vidage de mémoire entraîne l'erreur suivante : Aucune partition de coredump valide n'a été trouvée.
Solution : aucune. Dans vCenter Server 7.0., les profils d'hôte ne prennent en charge que les vidages de mémoire basés sur des fichiers.
- Les requêtes HTTP de certaines bibliothèques vers vSphere peuvent être rejetées.
Le proxy inverse HTTP dans vSphere 7.0 applique une conformité standard plus stricte que dans les versions précédentes. Cela peut exposer des problèmes préexistants dans certaines bibliothèques tierces utilisées par les applications pour les appels SOAP à vSphere.
Si vous développez des applications vSphere qui utilisent de telles bibliothèques ou si vous incluez des applications basées sur ces bibliothèques dans votre pile vSphere, vous pouvez rencontrer des problèmes de connexion lorsque ces bibliothèques envoient des requêtes HTTP à VMOMI. Par exemple, les requêtes HTTP émises à partir de bibliothèques vijava peuvent prendre le format suivant :
POST /sdk HTTP/1.1
SOAPAction
Content-Type: text/xml; charset=utf-8
User-Agent: Java/1.8.0_221
Dans cet exemple, la syntaxe enfreint une exigence de champ d'en-tête de protocole HTTP qui impose deux-points après SOAPAction. Par conséquent, la requête est rejetée dans Flight.
Solution : les développeurs qui exploitent des bibliothèques non conformes dans leurs applications peuvent envisager d'utiliser une bibliothèque qui suit les normes HTTP à la place. Par exemple, les développeurs qui utilisent la bibliothèque vijava peuvent envisager à la place d'utiliser la dernière version de la bibliothèque yavijava.
- L'ensemble de règles de pare-feu dynamique SNMP est modifié par les profils d'hôte lors d'un processus de correction
L'ensemble de règles de pare-feu SNMP est un état dynamique, qui est géré pendant l'exécution. Lorsqu'un profil d'hôte est appliqué, la configuration de l'ensemble de règles est gérée simultanément par les profils d'hôte et SNMP, qui peuvent modifier les paramètres de pare-feu de manière inattendue.
Solution : il existe deux solutions.
- Pour permettre à l'ensemble de règles de se gérer dynamiquement, excluez l'option de l'ensemble de règles de pare-feu SNMP dans la configuration du profil d'hôte.
- Pour poursuivre la double gestion de l'ensemble de règles, lorsque cela est nécessaire, corrigez l'état de l'ensemble de règles de pare-feu.
- Vous pouvez voir un fichier de vidage lorsque vous utilisez les pilotes Broadcom lsi_msgpt3, lsi_msgpt35 et lsi_mr3
Lors de l'utilisation des contrôleurs lsi_msgpt3, lsi_msgpt35 et lsi_mr3, vous risquez d'obtenir le fichier de vidage lsuv2-lsi-drivers-plugin-util-zdump. Un problème se produit lors de la sortie de storelib utilisé dans cet utilitaire de plug-in. Il n'y a aucun impact sur les opérations ESXi et vous pouvez ignorer le fichier de vidage.
Solution : vous pouvez ignorer ce message. Vous pouvez supprimer lsuv2-lsi-drivers-plugin à l'aide de la commande suivante :
esxcli software vib remove -n lsuv2-lsiv2-drivers-plugin
- Le redémarrage n'est peut-être pas nécessaire après la configuration de SR-IOV sur un périphérique PCI dans vCenter, mais les configurations de périphérique effectuées par des extensions tierces peuvent être perdues et le redémarrage doit être effectué.
Dans ESXi 7.0, la configuration de SR-IOV est appliquée sans redémarrage et le pilote de périphérique est rechargé. Les hôtes ESXi peuvent avoir des extensions tierces exécutant des configurations de périphérique qui doivent être exécutées après le chargement du pilote de périphérique pendant le démarrage. Un redémarrage est nécessaire pour ces extensions tierces afin de réappliquer la configuration du périphérique.
Solution : vous devez redémarrer après la configuration de SR-IOV pour appliquer les configurations de périphérique tierces.
- Vous voyez des zones noires ou grises dans l'arrière-plan d'une fenêtre parente dans l'interface utilisateur de la console directe (DCUI, Direct Console User Interface) après la fermeture d'une fenêtre enfant
Dans l'interface DCUI, lorsque vous fermez une fenêtre enfant en appuyant sur les touches Échap ou Entrée, ou en cliquant sur les boutons Annuler ou OK, l'apparence de la fenêtre parente peut changer. La couleur de l'arrière-plan s'affiche en gris ou en noir pour certaines parties de la fenêtre parente. Cependant, toutes les informations requises dans l'interface DCUI s'affichent correctement et toutes les opérations effectuées se déroulent correctement.
Solution : attendez 1 minute sans actualiser la fenêtre actuelle de l'interface DCUI ni appuyer sur une touche.
