| vCenter Server 6.7 Update 2 | 11 avril 2019 | Build ISO 13010631 vCenter Server Appliance 6.7 Update 2 | 11 avril 2019 | Build 13010631 |
Contenu des notes de mise à jour
Les notes de mise à jour couvrent les sujets suivants :
Nouveautés
- Avec vCenter Server 6.7 Update 2, vous pouvez configurer la propriété
config.vpxd.macAllocScheme.method dans le fichier de configuration de vCenter Server, vpxd.cfg, pour permettre la sélection séquentielle d'adresses MAC à partir de pools d'adresses MAC. L'option par défaut de sélection aléatoire ne change pas. La modification de la stratégie d'allocation d'adresse MAC n'affecte pas les adresses MAC pour les machines virtuelles existantes.
- vCenter Server 6.7 Update 2 ajoute une API REST que vous pouvez exécuter depuis vSphere Client pour la convergence d'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. Pour plus d'informations, reportez-vous au guide Installation et configuration de vCenter Server.
- vCenter Server 6.7 Update 2 intègre le programme d'amélioration du produit VMware (CEIP) dans l'utilitaire de convergence.
- vCenter Server 6.7 Update 2 ajoute une API SOAP pour suivre l'état des clés de chiffrement. Avec l'API, vous pouvez voir si la clé de chiffrement est disponible dans un système vCenter Server ou si elle est utilisée par des machines virtuelles, comme clé d'hôte ou par des programmes tiers.
- Pré-vérification pour la mise à niveau de systèmes vCenter Server : vCenter Server 6.7 Update 2 active une pré-vérification lors de la mise à niveau d'un système vCenter Server pour garantir la compatibilité de la mise à niveau des points de terminaison d'enregistrement du service VMware vCenter Single Sign-on. Cette vérification indique une éventuelle discordance avec les certificats de machine vCenter Single Sign-on existants avant le démarrage d'une mise à niveau et empêche les interruptions de mise à niveau qui nécessitent une solution manuelle et entraînent une interruption de service.
- Améliorations de l'audit vSphere : vCenter Server 6.7 Update 2 améliore l'audit de VMware vCenter Single Sign-on en ajoutant des événements aux opérations suivantes : gestion des utilisateurs, connexion, création de groupe, source d'identité et mises à jour de stratégie. La nouvelle fonctionnalité est disponible uniquement pour vCenter Server Appliance avec instance intégrée de Platform Services Controller et non pour vCenter Server pour Windows ou vCenter Server Appliance avec instance externe de Platform Services Controller. Les sources d'identité prises en charge sont vsphere.local, Integrated Windows Authentication (IWA) et Active Directory sur LDAP.
- Version 15 du matériel virtuel : vCenter Server 6.7 Update 2 introduit la version 15 du matériel virtuel qui ajoute la prise en charge de la création de machines virtuelles avec jusqu'à 256 CPU virtuels. Pour plus d'informations, reportez-vous aux articles 1003746 et 2007240 de la base de connaissances VMware.
- Restauration simplifiée des fichiers de sauvegarde : si vous ne trouvez pas la build appropriée pour restaurer un fichier de sauvegarde et que vous entrez des détails de sauvegarde incorrects, l'interface de gestion de vCenter Server Appliance dans vCenter Server 6.7 Update 2 ajoute un message d'erreur dans la page Entrer les détails de la sauvegarde, indiquant les détails de la version correspondante qui vous aident à choisir la build appropriée. Vous pouvez également trouver les détails de la version sous Sauvegarde > Activité.
- Avec vCenter Server 6.7 Update 2, vous pouvez utiliser les protocoles NFS (Network File System) et SMB (Server Message Block) pour les opérations de sauvegarde et de restauration basées sur des fichiers sur vCenter Server Appliance. L'utilisation des protocoles NFS et SMB pour les opérations de restauration est prise en charge uniquement à l'aide du programme d'installation de l'interface de ligne de commande de vCenter Server Appliance.
- vCenter Server 6.7 Update 2 ajoute des événements pour les modifications d'autorisations sur balises et catégories, les objets vCenter Server et les autorisations globales. Les événements spécifient l'utilisateur qui initie les modifications.
- Avec vCenter Server 6.7 Update 2, vous pouvez créer des définitions d'alarme pour surveiller l'état de sauvegarde de votre système. En définissant une alarme d'état de sauvegarde, vous pouvez recevoir des notifications par e-mail, envoyer des interruptions SNMP et exécuter des scripts déclenchés par des événements tels qu'
Échec de la tâche de sauvegarde et Tâche de sauvegarde terminée correctement. Un événement Échec de la tâche de sauvegarde définit l'état de l'alarme sur ROUGE et Tâche de sauvegarde terminée correctement réinitialise l'alarme sur VERT.
- Avec vCenter Server 6.7 Update 2, dans les clusters utilisant l'édition Enterprise de VMware vSphere Remote Office Branch Office, configurés pour prendre en charge vSphere Distributed Resource Scheduler en mode de maintenance, lorsqu'un hôte ESXi passe en mode de maintenance, toutes les machines virtuelles en cours d'exécution sur l'hôte sont déplacées vers d'autres hôtes du cluster. Les règles d'affinité VM-hôte automatiques garantissent que les machines virtuelles déplacées reviennent aux mêmes hôtes ESXi lorsqu'elles quittent le mode de maintenance.
- Avec vCenter Server 6.7 Update 2, les événements liés à l'ajout, la suppression ou la modification de rôles d'utilisateur affichent l'utilisateur qui initie les modifications.
- Avec vCenter Server 6.7 Update 2, vous pouvez publier vos modèles .vmtx directement à partir d'une bibliothèque publiée sur plusieurs abonnés dans une seule action plutôt que d'effectuer une synchronisation à partir de chaque bibliothèque abonnée individuellement. Les bibliothèques publiées et abonnées doivent se trouver dans le même système vCenter Server lié, qu'il soit sur site, dans le cloud ou hybride. L'utilisation d'autres modèles dans des bibliothèques de contenu ne change pas.
- vCenter Server 6.7 Update 2 ajoute une alerte pour spécifier la version du programme d'installation dans l'étape Entrer les détails de la sauvegarde d'une opération de restauration. Si les versions du programme d'installation et de la sauvegarde ne sont pas identiques, une invite indique la build correspondante à télécharger, telle que
Lancez le programme d'installation correspondant à la version 6.8.2 GA.
- vCenter Server 6.7 Update 2 ajoute la prise en charge d'un clavier suédois dans vSphere Client et VMware Host Client. Pour connaître les problèmes connus liés au mappage du clavier, consultez l'article 2149039 de la base de connaissances VMware.
- Avec vCenter Server 6.7 Update 2, vSphere Client fournit une case à cocher Vérifier la santé de l'hôte après l'installation qui vous permet d'exclure les contrôles de santé de vSAN lors de la mise à niveau d'un hôte ESXi à l'aide de la vSphere Update Manager. Avant d'introduire cette option, si des problèmes vSAN étaient détectés lors d'une mise à niveau, l'intégralité de la correction du cluster échouait et l'hôte ESXi qui était mis à niveau restait en mode de maintenance.
- Alarm et catégories de santé vSphere : vCenter Server 6.7 Update 2 ajoute une alarme dans vSphere Client lorsque la santé vSphere détecte un nouveau problème dans votre environnement et vous invite à résoudre le problème. Les résultats du contrôle de santé sont maintenant groupés en catégories pour une meilleure visibilité.
- Avec vCenter 6.7 Update 2, vous pouvez désormais publier vos modèles de machine virtuelle gérés par la bibliothèque de contenu à partir d'une bibliothèque publiée vers plusieurs abonnés. Vous pouvez déclencher cette action à partir de la bibliothèque publiée, ce qui vous permet de mieux contrôler la répartition des modèles de machines virtuelles. Les bibliothèques publiées et abonnées doivent se trouver dans le même système vCenter Server lié, qu'il soit sur site, dans le cloud ou hybride. L'utilisation d'autres modèles dans des bibliothèques de contenu ne change pas.
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.
Remarques relatives à la prise en charge du produit
- VMware vSphere Flash Read Cache devient obsolète. Bien que cette fonctionnalité soit toujours prise en charge dans la génération vSphere 6.7, elle sera supprimée dans une version ultérieure de vSphere. Vous pouvez également utiliser le mécanisme de mise en cache vSAN ou tout logiciel d'accélération d'E/S tiers certifié par VMware répertorié dans le Guide de compatibilité VMware.
- vCenter Server 6.7 Update 2 ne prend pas en charge Digest Algorithm 5 (MD5) et vous ne pouvez pas définir l'option d'authentification MD5 à l'aide de la commande
snmp.set.
Notes de mise à niveau de cette version
IMPORTANT : si vous utilisez la fonctionnalité Hybrid Linked Mode (HLM), contactez l'équipe de support de VMware (équipe d'ingénierie de service cloud) avant d'effectuer la mise à niveau vers vCenter Server 6.7 Update 2.
Pour plus d'informations sur les versions de vCenter Server qui prennent en charge la mise à niveau vers vCenter Server 6.7 Update 2, consultez l'article 67077 de la base de connaissances VMware.
Correctifs contenus dans cette version
Cette version de vCenter Server 6.7 Update 2 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 2
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 à jour uniquement le JRE version 1.8.0_202.
Pour vCenter Server et Platform Services Controller pour Windows
| Nom de fichier de téléchargement |
VMware-VIMPatch-T-6.7.0-13010631.iso |
| Build |
13010631 |
| Taille du téléchargement |
40,7 Mo |
| md5sum |
edcd2f2a9294fffcbec32150f10a0005 |
| sha1checksum |
a66c23f958a83542e2bd33681d838b22630ed953 |
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-13010631.iso sur le système sur lequel 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 2
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.30000-13010631-patch-FP.iso |
| Build |
13010631 |
| Taille du téléchargement |
1 996,6 Mo |
| md5sum |
2f09c95d416c7d2ba6d94b032b240ef9 |
| sha1checksum |
dd8053b955093cd512408099d4d9ac618668e28c |
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.30000-13010631-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.
Journal des modifications de notes de mise à jour
Cette section décrit les mises à jour opérées sur les notes de mise à jour.
Problèmes résolus
Les problèmes résolus sont regroupés comme suit :
Problèmes de vMotion
- Les opérations vSphere vMotion pour les machines virtuelles chiffrées peuvent échouer après un redémarrage du système vCenter Server
Après un redémarrage d'un système vCenter Server, des erreurs de vérification de compatibilité peuvent faire échouer les opérations de vSphere vMotion pour les machines virtuelles chiffrées. Des entrées de journal semblables à celles-ci peuvent s'afficher :
RuntimeFault.summary Session does not have Cryptographer.RegisterHost privilege.
Ce problème est résolu dans cette version.
- Les opérations de mise sous tension ou vSphere vMotion avec des machines virtuelles peuvent échouer avec une erreur de boucle infinie
La mise sous tension ou les opérations vSphere vMotion avec des machines virtuelles peuvent échouer avec une erreur de boucle infinie si le fichier de configuration .vmx est endommagé.
Ce problème est résolu dans cette version.
- Le mode de disque d'une machine virtuelle peut changer après une migration à l'aide de vSphere Storage vMotion
Si vous migrez une machine virtuelle à l'aide de Storage vMotion, le mode de disque de cette machine virtuelle peut changer sans avertissement. Par exemple, il peut changer d'Indépendant - Permanent à Dépendant.
Ce problème est résolu dans cette version.
- La migration d'une machine virtuelle peut échouer en raison de l'impossibilité d'accéder au disque parent
La migration d'une machine virtuelle peut échouer avec l'erreur FileNotFound pendant le processus de copie de fichiers réseau lorsque l'hôte de destination a accès au disque enfant partagé de l'hôte source et ne peut pas accéder au disque parent.
Ce problème est résolu dans cette version.
- Les opérations de migration de machine virtuelle telles que le provisionnement d'Instant Clone peuvent échouer en raison d'une condition de concurrence
En raison d'une condition rare entre opérations qui créent une base de données d'espaces de noms avec des solutions telles que VMware AppDefense et la migration de machines virtuelles à l'aide de Storage vMotion ou de la compatibilité améliorée de vMotion, la migration peut échouer.
Ce problème est résolu dans cette version.
Problèmes de sauvegarde et de restauration
- La sauvegarde de VMware vCenter Server Appliance peut ne pas démarrer si le service vmonapi ne parvient pas à démarrer lorsqu'un proxy est configuré ou ne répond pas
Pendant la configuration d'un proxy ou si un proxy ne répond pas, le service vmonapi, qui fournit une API pour démarrer et arrêter les services vCenter Server, n'est pas en cours d'exécution. Cela bloque les sauvegardes de vCenter Server Appliance.
Ce problème est résolu dans cette version.
Problèmes liés à Auto Deploy
- L'onglet Hôtes découverts de VMware vSphere Auto Deploy peut afficher une erreur après la création ou la modification d'une règle de déploiement
Lorsque vous préparez votre système pour provisionner des hôtes ESXi avec vSphere Auto Deploy au démarrage du réseau, si un hôte ne correspond à aucune règle de déploiement lors de la configuration, une erreur peut se déclencher lorsque vous créez une règle ultérieurement. Par conséquent, il se peut que l'hôte ne s'affiche pas sur l'onglet Hôtes découverts et que l'erreur Impossible de récupérer les hôtes déployés : le nom « élément » n'est pas défini. s'affiche.
Ce problème est résolu dans cette version.
Problèmes relatifs au système d'exploitation invité
- Vous ne pouvez pas définir une carte réseau virtuelle principale
Vous ne pouvez pas personnaliser le système d'exploitation invité de vCenter Server Appliance pour définir une carte réseau virtuelle comme principale.
Ce problème est résolu dans cette version. Avec ce correctif, vous pouvez personnaliser une carte réseau virtuelle en tant que carte réseau virtuelle principale, lorsque la carte réseau virtuelle est la première carte réseau, et dispose également d'une adresse IPv4 statique et d'une passerelle configurée.
- La personnalisation des machines virtuelles à l'aide de Microsoft Sysprep sur vSphere 6.7 peut échouer et les machines virtuelles restent dans l'état de personnalisation
La personnalisation des machines virtuelles à l'aide de Microsoft Sysprep sur vSphere 6.7 peut échouer si les machines virtuelles Windows utilisent des disques amovibles. Sysprep peut modifier la lettre de lecteur des disques amovibles lors de la personnalisation. Par conséquent, les machines virtuelles restent dans l'état de personnalisation et cessent de répondre.
Ce problème est résolu dans cette version.
Problèmes relatifs à VMware Tools
- Le répertoire c:\sysprep risque de ne pas être supprimé après la personnalisation de l'invité Windows
Le répertoire temporaire c:\sysprep peut ne pas être supprimé après l'exécution de la personnalisation de l'invité Windows.
Ce problème est résolu dans cette version. Avec ce correctif, tous les fichiers et dossiers temporaires sont supprimés en tirant parti de l'API Windows et après le redémarrage de la machine virtuelle.
- L'outil OVF (Open Virtualization Format) de VMware peut ne pas remplacer tous les fichiers d'un dossier de destination
Même lorsque vous utilisez l'option --overwrite de l'outil OVF, les fichiers existants dans le dossier de destination peuvent ne pas être supprimés ou remplacés, et seule la suppression manuelle fonctionne.
Ce problème est résolu dans cette version.
- Vous ne verrez peut-être pas les partages de CPU configurés lors de l'exportation d'une machine virtuelle vers OVF
Lorsque vous exportez une machine virtuelle vers OVF à l'aide de l'outil OVF, les partages de CPU configurés peuvent ne pas être exportés.
Ce problème est résolu dans cette version.
Problèmes de stockage
- Les demandes de provisionnement de machine virtuelle en bloc avec le paramètre ResourceLeaseDurationSec transmises via VMware vSphere Storage DRS peuvent échouer
Lorsque plusieurs demandes de provisionnement de machines virtuelles sont transmises via vSphere Storage DRS avec le paramètre ResourceLeaseDurationSec spécifié comme placement, vSphere Storage DRS fournit des recommandations de placement initial et alloue de l'espace pour chacun d'entre eux, en bloquant l'utilisation d'espace de banque de données. Cela peut entraîner des échecs de provisionnement.
Ce problème est résolu dans cette version.
- vCenter Server peut cesser de répondre lors de l'ajout d'un message de panne dans vSphere Storage DRS
vCenter Server peut cesser de répondre lors d'une tentative d'accès du service vpxd et d'ajout d'un message d'erreur concernant une banque de données désaffectée ou supprimée dans vSphere Storage DRS.
Ce problème est résolu dans cette version.
- Une vague d'événements de mise à jour de configuration déclenchée par un appel vSphere API for Storage Awareness peut entraîner une erreur d'insuffisance de mémoire ou des appels d'API irréguliers
Chaque événement de mise à jour de la configuration déclenche une synchronisation complète avec un fournisseur vSphere API for Storage Awareness. En conséquence, les threads synchronisés s'accumulent. Si le nombre d'événements de mise à jour de configuration est important, cela entraîne une erreur d'insuffisance de mémoire ou des déclenchements irréguliers d'appels d'API getEvents.
Ce problème est résolu dans cette version.
- Le service vpxd peut échouer lorsque vSphere Storage DRS fournit une opération de placement initiale
L'une des structures de données internes du workflow de placement initial de vSphere Storage DRS peut être remplacée par une valeur NULL, ce qui peut entraîner une référence de pointeur null et un échec du service vpxd.
Ce problème est résolu dans cette version.
- Les hôtes ESXi ayant une visibilité sur les LUN RDM peuvent prendre beaucoup de temps pour démarrer ou rencontrer des retards lors des réanalyses des LUN
Un grand nombre de LUN RDM peut ralentir le démarrage d'un hôte ESXi ou provoquer un retard lors de l'exécution d'une réanalyse de LUN. Si vous utilisez des API, telles que MarkPerenniallyReserved ou MarkPerenniallyReservedEx, vous pouvez marquer un LUN spécifique comme étant réservé de façon permanente, ce qui améliore la rapidité de démarrage et de réanalyse des hôtes ESXi.
Ce problème est résolu dans cette version.
- L'extension du disque d'une machine virtuelle à l'aide de VMware vRealize Automation peut échouer avec une erreur d'espace disque insuffisant sur une banque de données
Si vSphere Storage DRS ne fournit pas de recommandation pendant que l'exécution d'un développement de disque d'une machine virtuelle à l'aide de VMware vRealize Automation, l'opération peut échouer en raison d'un espace insuffisant sur la banque de données actuelle. Ce problème se produit lorsque vSphere Storage DRS choisit un disque ne correspondant pas à l'opération. Par conséquent, vous pouvez voir l'erreur Espace disque insuffisant sur la banque de données.
Ce problème est résolu dans cette version.
- Des tâches vSphere Storage DRS peuvent se prolonger ou dépasser le délai d'attente
Des tâches vSphere Storage DRS peuvent se prolonger ou dépasser le délai d'attente en raison d'une réponse lente ou différée de vSphere Replication Management Server.
Ce problème est résolu dans cette version.
- Le provisionnement de machines virtuelles peut échouer si le même groupe de réplication est utilisé pour une partie ou la totalité des fichiers et des disques de la machine virtuelle
VMware vSphere Storage Policy Based Management (SPBM) peut ne pas filtrer l'ID de groupe de réplication unique lors d'un appel queryReplicationGroup à un fournisseur VASA (API for Storage Awareness). Par conséquent, le provisionnement de machines virtuelles peut échouer si le même groupe de réplication est utilisé pour une partie ou la totalité des fichiers de machine virtuelle et des disques virtuels.
Ce problème est résolu dans cette version.
- La publication d'alarmes de conformité de VMware vSphere Virtual Volumes pour un type de StorageObject sur un système vCenter Server peut échouer
Si vous utilisez un fournisseur VASA (API for Storage Awareness), la publication d'alarmes de conformité de vSphere Virtual Volumes pour un type StorageObject sur un système vCenter Server peut échouer en raison d'une incompatibilité de mappage.
Ce problème est résolu dans cette version.
Problèmes avec vCenter Server, vSphere Web Client et vSphere Client
- Vous ne pouvez pas ajouter d'autorisations pour un utilisateur ou un groupe au-delà des 200 premiers principaux de sécurité dans un domaine Active Directory via vSphere Client
Si vous accordez des autorisations à un utilisateur ou un groupe à partir d'un domaine Active Directory à l'aide de vSphere Client, la recherche de principaux de sécurité est limitée à 200 et vous ne pouvez pas ajouter d'utilisateurs à un principal au-delà de cette liste.
Ce problème est résolu dans cette version.
- Le service vpxd peut ne pas démarrer si le nombre de certificats du magasin TRUSTED_ROOTS est supérieur à 20
Lorsque le nombre de certificats dans le magasin TRUSTED_ROOTS sur un système vCenter Server est supérieur à 20, le démarrage du service vpxd peut échouer. vSphere Web Client et vSphere Client affichent l'erreur suivante :
[400] Une erreur s'est produite lors de l'envoi d'une demande d'authentification vers le serveur vCenter Single Sign-On.
Ce problème est résolu dans cette version. Avec ce correctif, le magasin TRUSTED_ROOTS peut prendre en charge jusqu'à 30 certificats dans vCenter Server pour Windows et vCenter Server Appliance.
- Le premier démarrage peut échouer lors du déploiement de vCenter Server Appliance à l'aide d'une instance externe de Platform Services Controller en raison d'un retard de synchronisation de l'heure
Le premier démarrage peut échouer lors du déploiement de vCenter Server Appliance à l'aide d'un instance externe de Platform Services Controller si l'heure entre le nœud Platform Services Controller et le système vCenter Server n'est pas synchronisée.
Ce problème est résolu dans cette version.
- Les événements de connexion et de déconnexion de l'utilisateur peuvent ne pas contenir l'adresse IP de l'utilisateur
Si vous vous connectez à un système vCenter Server à l'aide de vSphere Web Client ou de vSphere Client, l'événement de connexion peut afficher 127.0.0.1 au lieu de l'adresse IP de l'utilisateur. De plus, il se peut que vous ne voyez pas le suivi des modifications de configuration de vCenter Single Sign-on dans la vue Événements.
Ce problème est résolu dans cette version. Le correctif ajoute un nouveau fichier journal d'audit dans les journaux de vCenter Single Sign-on. Vous pouvez également voir les nouveaux événements dans la vue Surveiller> Événements de vSphere Web Client et de vSphere Client.
- Le démarrage du service démon vpxd de vCenter Server peut échouer avec une erreur d'index de descripteur non valide
Le démarrage du service vpxd peut échouer avec une erreur d'index du descripteur non valide dans le paramètre VPX_HCI_CONFIG_INFO. LOCKDOWN_MODE.
Ce problème concerne les environnements sur vCenter Server pour Windows 6.7 Update 1 ou version ultérieure qui utilisent un serveur de base de données MS SQL. Si vous créez un cluster d'infrastructure hyperconvergé à l'aide du workflow de démarrage rapide et que vous redémarrez le système vCenter Server, vpxd peut ne pas démarrer en raison d'un échec de traitement des données par le serveur de base de données SQL.
Vous pouvez voir des journaux similaires dans vpxd. Log :
[VdbStatement::ResultValue:GetValue] Error to get value at pos: 1, ctype: 4 for SQL "VPX_HCI_CONFIG_INFO.LOCKDOWN_MODE" Init failed. VdbError: Error[VdbODBCError] (-1) ODBC error: (07009) - [Microsoft][SQL Server Native Client 11.0]Invalid Descriptor Index Failed to intialize VMware VirtualCenter. Shutting down
Ce problème est résolu dans cette version.
Problèmes de gestion des machines virtuelles
- Le clonage d'une machine virtuelle à partir d'un snapshot d'un modèle peut échouer avec une erreur
L'erreur Une erreur système générale s'est produite : fichier vmsn manquant s'affiche lorsque vous clonez une machine virtuelle à partir d'un snapshot d'un modèle.
Ce problème est résolu dans cette version.
- Une erreur interne peut se produire dans les définitions d'alarme de vSphere Web Client
Une erreur interne peut se produire lorsque vous tentez de modifier l'alarme prédéfinie contenant xxx Exhaustion on xxx, par exemple Autodeploy Disk Exhaustion on xxx et ajoutez ou modifiez les actions d'alarme.
Ce problème est résolu dans cette version.
Problèmes de sécurité
- Mise à jour vers VMware Postgres
VMware Postgres est mis à jour vers la version 9.6.11.
- 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.
- Mise à jour de JRE
Oracle (Sun) JRE est mis à jour vers la version 1.8.202
- Une URL composée peut afficher les détails du serveur Apache
Si vous composez une URL telle que https://:9443/vsphere-client/inventory-viewer/locales/help
, vous pouvez voir des détails sur le serveur Apache, tels que la version.
Ce problème est résolu dans cette version.
- Mise à niveau d'Apache httpd
Apache httpd est mis jour vers la version 2.4.37 pour résoudre le problème de sécurité ayant l'identifiant CVE-2018-11763.
- Mise à jour d'OpenSSL
Le module OpenSSL est mis à jour vers la version openssl-1.0.2q.
- Mise à jour de la bibliothèque libxml2
La bibliothèque ESXi userworld libxml2 a été mise à jour vers la version 2.9.8.
- Mise à jour d'OpenSSH
OpenSSL est mis à jour vers la version 7.4p1-7.
Problèmes divers
- 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.
Ce problème est résolu dans cette version.
- Le service de démon vpxd de vCenter Server peut ne pas réussir à démarrer après un redémarrage du serveur
Après le redémarrage d'un serveur, lorsque vpxd charge l'inventaire à partir de la base de données, il calcule la charge de travail à partir de la taille de l'inventaire et du nombre de cœurs de CPU disponibles. Certaines combinaisons exceptionnelles de ces entrées peuvent entraîner une erreur de calcul, ce qui provoque une erreur qui empêche le démarrage du service. L'erreur suivante peut s'afficher :
Échec de l'initialisation : les données extraites sont NULL à la position de colonne 0
Ce problème est résolu dans cette version. Une solution précédente impliquait la désactivation d'un ou de plusieurs cœurs de CPU dans vCenter Server Appliance afin de corriger le calcul. Vous pouvez annuler cette solution après l'application de cette mise à jour.
- Le fichier vmdir-syslog.log est saturé de messages de journal lors de la migration d'un système vCenter Server ou d'une instance de Platform Services Controller de Windows vers vCenter Server Appliance
Lors de la migration d'un système vCenter Server ou d'une instance de Platform Services Controller de Windows vers vCenter Server Appliance, l'entrée cn=DSE root est répliquée sans descripteur de sécurité. Par conséquent, le fichier vmdird-syslog.log est saturé par des messages No SD found for cn=DSE Root.
Ce problème est résolu dans cette version. Ce correctif remplace le niveau de journalisation par « détaillé » et supprime les messages de journal après la migration de Windows vers vCenter Server Appliance.
- Le service de démon vpxd de vCenter Server peut échouer si vous vous déconnectez immédiatement après le lancement d'une opération FileManager
Si vous vous déconnectez immédiatement après le lancement d'une opération FileManager, comme delete, move ou copy, le service vpxd peut échouer, car la tâche ne peut pas être prélevée pour exécution à partir de la file d'attente de la tâche.
Ce problème est résolu dans cette version.
Problèmes de CIM et d'API
- Les requêtes d'API peuvent expirer lorsque de nombreux objets sont associés à des balises
Les appels d'API, tels que listAttachedObjects, listAttachedObjectsOnTags, et listAllAttachedObjectsOnTags, peuvent prendre beaucoup de temps et finir par expirer, lorsque de nombreux objets sont associés à chaque balise. Cela est dû au fait que des appels de procédure distante séparés ont été envoyés au service vmware-vpxd pour effectuer des vérifications d'autorisation sur chaque objet vCenter Server.
Ce problème est résolu dans cette version. Avec ce correctif, les API de balisage effectuent des appels AuthZ par lot à vmware-vpxd pour effectuer des vérifications d'autorisation sur tous les objets associés.
Problèmes d'installation, de mise à niveau et de migration
- La migration de vCenter Server pour Windows vers vCenter Server Appliance peut s'arrêter à 75 % si l'heure système n'est pas synchronisée avec un serveur NTP
Pendant la phase 2 d'une migration de vCenter Server pour Windows vers vCenter Server Appliance, si l'heure système de vCenter Server n'est pas synchronisée avec un serveur NTP, la session peut expirer et la migration s'arrête sans avertissement. L'interface du programme d'installation peut afficher indéfiniment une progression de 75 %.
Ce problème est résolu dans cette version.
- La mise à niveau de vCenter Server pour Windows vers la version 6.7 Update 2 à partir de versions antérieures de la gamme 6.7 peut échouer
Si vous tentez de mettre à niveau un système vCenter Server pour Windows, avec un serveur SQL Server externe qui utilise l'authentification Windows, vers la version 6.7 Update 2 à partir d'une version antérieure de la gamme 6.7, l'opération peut échouer.
Ce problème est résolu pour les mises à niveau de vCenter Server 6.7 Update 1 vers la version 6.7 Update 2. Pour les mises à niveau de la version 6.7.0 ou 6.7.0.x vers la version 6.7 Update 2, consultez l'article 67561 de la base de connaissances VMware.
- Les mises à niveau de vCenter Server peuvent échouer en raison du problème de compatibilité entre VMware Tools 10.2 et versions ultérieures, et ESXi 6.0 et versions antérieures
VMware Tools 10.2 et versions ultérieures peuvent ne pas être compatibles avec ESXi 6.0 et versions antérieures. En conséquence, les mises à niveau des systèmes vCenter Server peuvent échouer.
Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème, mettez à jour le conteneur ESXi vers la version 6.7 ou restaurez la version 10.1.5 de VMware Tools. Lorsque la mise à niveau du système vCenter Server est terminée, mettez à niveau VMware Tools et le conteneur ESX.
Problèmes de convergence
- Des certificats peuvent être perdus après une convergence d'une instance de vCenter Server avec une instance externe de Platform Services Controller en une instance de vCenter Server avec une instance intégrée de Platform Services Controller
Des certificats de serveur de gestion de clés (KMS) et d'autorité de certification (CA) peuvent être perdus après la convergence d'une instance de vCenter Server avec une instance externe de Platform Services Controller en une instance de vCenter Server avec une instance intégrée de Platform Services Controller. Un avertissement similaire au suivant peut s'afficher :
Non connecté (Approbation non établie. Afficher les détails)
Ce problème est résolu dans cette version.
- L'outil de convergence de vCenter Server peut ne pas parvenir à convertir une instance de Platform Services Controller externe en une instance intégrée de Platform Services Controller 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.
Ce problème est résolu dans cette version.
- La convergence d'une instance de vCenter Server avec une instance externe de Platform Services Controller en une instance de vCenter Server avec une instance intégrée de Platform Services Controller peut échouer avec une erreur de certificats manquants
La convergence d'une instance de vCenter Server avec une instance externe de Platform Services Controller en une instance de vCenter Server avec une instance intégrée de Platform Services Controller peut échouer avec une erreur telle que Certificat introuvable pour l'entrée [location_password_default ] de type [clé secrète].
Ce problème est résolu dans cette version.
- Le fichier converge.log risque de ne pas inclure de journaux de niveau débogage lors de la convergence d'une instance de vCenter Server avec une instance externe de Platform Services Controller en une instance de vCenter Server avec une instance intégrée de Platform Services Controller
Lorsque vous exécutez la commande vscaConvergeCli avec le niveau de journalisation défini sur « détaillé », le niveau de journalisation de l'utilitaire converge-util est défini sur « débogage », mais le fichier converge.log peut ne pas enregistrer les messages du journal de débogage. Par conséquent, lors du dépannage, vous ne pouvez pas voir le niveau attendu de détails dans le fichier journal.
Ce problème est résolu dans cette version.
Problèmes de mise en réseau
- Un message indiquant qu'une mise à niveau de VMware vSphere Distributed Switch est en cours d'exécution peut s'afficher, même après la fin de la mise à niveau
Vous pouvez voir un message Une mise à niveau de vSphere Distributed Switch dans le centre de données est en cours, même après la fin de la mise à niveau. Cela se produit si aucun membre hôte n'est disponible dans la configuration de vSphere Distributed Switch ou si un membre hôte n'a pas pu être mis à niveau plusieurs fois.
Ce problème est résolu dans cette version. Si vous êtes déjà confronté à ce problème de non-disponibilité de membre hôte dans VDS, exécutez les commandes suivantes :
update vpx_dvs upgrade_status set upgrade_status=0
vmon-cli -r vpxd
- vSphere Distributed Switch peut devenir désynchronisé pour certains hôtes ESXi après la mise à niveau vers vSphere Distributed Switch 6.6
Lorsque vous migrez une machine virtuelle qui utilise une banque de données vSAN depuis un hôte ESXi dans un centre de données vers un hôte ESXi d'un autre centre de données, le port sur le commutateur distribué source peut ne pas être libéré dans le système vCenter Server. Par conséquent, vSphere Distributed Switch peut être désynchronisé lors de la mise à niveau vers vSphere Distributed Switch 6.6.
Ce problème est résolu dans cette version.
- Vous ne pouvez pas migrer des machines virtuelles à l'aide de vSphere vMotion entre des hôtes ESXi avec des commutateurs virtuel distribués NSX (N-VDS) gérés et des commutateurs vSphere Standard
Avec vCenter Server 6.7 Update 2, vous pouvez migrer des machines virtuelles à l'aide de vSphere vMotion entre des hôtes ESXi avec des commutateurs N-VDS et des commutateurs vSphere Standard. Pour activer la fonctionnalité, vous devez mettre à niveau le système vCenter Server vers vCenter Server 6.7 Update 2 et ESXi 6.7 Update 2 sur les sites sources et de destination.
Ce problème est résolu dans cette version.
Problèmes de configuration de serveur
- Vous ne pouvez pas redémarrer le service vpxd lorsque le certificat KMS a expiré ou est proche de la date d'expiration
Lorsque le certificat KMS a expiré ou est proche de la date d'expiration, vous ne pouvez pas redémarrer le service vpxd et la mise à niveau du système vCenter Server peut échouer.
Ce problème est résolu dans cette version.
Problèmes connus
Les problèmes connus sont classés comme suit :
Problèmes avec vCenter Server, vSphere Web Client et vSphere Client
- Connexion potentiellement impossible à un système vCenter Server en raison d'une panne du service VMware Security Token Service (vmware-stsd)
Le service vmware-stsd échoue dans certains environnements client si vous ajoutez l'authentification Windows intégrée (IWA) d'Active Directory en tant que source d'identité. L'ajout d'IWA en tant que source d'identité peut entraîner des vidages de mémoire qui remplissent le répertoire /storage/core et peut éventuellement provoquer l'échec de la connexion au système vCenter Server.
Le journal vmware-sts-idmd.log peut contenir des entrées semblables aux entrées suivantes :
[2018-11-02T13:28:42.168-07:00 IDM Shutdown INFO ] [IdmServer] Stopping IDM Server...
[2018-11-02T13:28:42.523-07:00 IDM Shutdown INFO ] [IdmServer] IDM Server has stopped
[2018-11-02T13:29:38.270-07:00 IDM Startup INFO ] [IdmServer] Starting IDM Server...
[2018-11-02T13:29:38.272-07:00 IDM Startup INFO ] [IdmServer] IDM Server has started
[2018-11-02T13:39:40.913-07:00 IDM Shutdown INFO ] [IdmServer] Stopping IDM Server...
[2018-11-02T13:39:40.913-07:00 IDM Shutdown INFO ] [IdmServer] IDM Server has stopped
Le journal /var/log/vmware/sso/utils/vmware-stsds.err peut contenir des entrées semblables aux entrées suivantes :
Nov 02, 2018 1:29:40 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 663 ms
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/usr/lib/vmware-sso/vmware-sts/webapps/ROOT/WEB-INF/lib/log4j-slf4jimpl-
2.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/usr/lib/vmware-sso/vmware-sts/webapps/ROOT/WEB-INF/lib/slf4j-log4j12-
1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
Nov 02, 2018 1:29:50 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 10097 ms
Service killed by signal 11
Solution : supprimez le système vCenter Server du domaine Active Directory et ajoutez le serveur LDAP en tant que source d'identité. Pour plus d'informations, reportez-vous à l'article 60161 de la base de connaissances VMware.
Problèmes de convergence
- Il se peut que les détails de l'équilibrage de charge ne s'affichent pas après la convergence du système vCenter Server
Si vous convergez votre système existant avec un équilibrage de charge configuré pour plusieurs instances externes de Platform Service Controller en modèle de déploiement intégré, il se peut que vous ne voyiez pas les détails de l'équilibrage de charge dans l'onglet Configuration système de vSphere Client. Par conséquent, vous ne pouvez pas désaffecter l'équilibrage de charge.
Solution : Désaffectez manuellement chaque instance externe de Platform Services Controller.
Problèmes de vMotion
Problèmes de mise à niveau et d'installation
- La mise à niveau vers vCenter Server 6.7 échoue lors du premier démarrage en raison d'une erreur de propriétaire de séquence PostgreSQL
La mise à niveau vers vCenter Server 6.7 échoue pendant le premier démarrage, car le propriétaire de séquence est postgres et non VC. Vous pouvez voir cette erreur :
Échec du premier démarrage de vCenter Server – doit être propriétaire de la relation vpx_sn_vdevice_backing_rel_seq.
Solution : Dans vCenter Server 6.7 Update 2, le message doit être propriétaire de la relation vpx_sn_vdevice_backing_rel_seq est remplacé par le message La validation du schéma de l'instance source de vCenter Server a détecté un problème de séquences. et pour fournir plus d'informations pointe vers l'article 55747 de la base de connaissances VMware.
- La mise à niveau de vCenter Server pour Windows peut échouer avec une erreur indiquant que la désinstallation de produits 5.5 a échoué
Si vous reconfigurez un nœud de déploiement intégré de vCenter Server pour Windows vers un modèle de déploiement externe et que vous redirigez vers la nouvelle instance externe de Platform Services Controller, la mise à niveau de votre système vCenter Server de vCenter Server 6.5 Update 2d vers la version 6.7 Update 2 peut échouer avec une erreur semblable à Échec de la désinstallation des produits 5.5 avec le code d'erreur « 1603 ».
Solution : Redémarrez votre système vCenter Server après la reconfiguration et réessayez la mise à niveau.
- Vous ne pouvez pas utiliser le programme d'installation de l'interface utilisateur graphique de vSphere 6.7 Update 2 sur des machines virtuelles disposant du système d'exploitation Ubuntu 14.04
Vous ne pouvez pas utiliser le programme d'installation de l'interface utilisateur graphique de vSphere 6.7 Update 2 sur des machines virtuelles disposant du système d'exploitation Ubuntu 14.04, car le module libnss3 n'est pas installé par défaut.
Solution : Installez la dernière version de libnss3 en exécutant la commande sudo apt-get install libnss3.
- Après la mise à niveau vers vCenter Server 6.7 Update 2 à partir de la version 6.0.x, l'onglet État du matériel de vSphere Web Client peut ne pas afficher de données d'hôte
Après une mise à niveau vers vCenter Server 6.7 Update 2 à partir de vCenter Server 6.0.x, il se peut que vous ne puissiez pas voir les détails matériels des hôtes ESXi dans l'onglet État du matériel de vSphere Web Client. À la place, une erreur Aucune donnée d'hôte disponible s'affiche.
Solution : Pour plus d'informations sur ce problème, reportez-vous à l'article 2148520 de la base de connaissances VMware.
Problèmes relatifs à VMware Tools
Problèmes de sauvegarde et de restauration
- Les sauvegardes avec du logiciel tiers peuvent échouer en raison de caractères non alphanumériques dans les noms de banques de données ou de centres de données sources
Dans les systèmes vCenter Server 6.7, les sauvegardes avec du logiciel tiers peuvent échouer si le nom de la banque de données ou du centre de données source contient des caractères non alphanumériques. Les modifications apportées au codage provoquent l'échec du téléchargement de fichiers.
Solution : Renommez les banques de données et les centres de données dont le nom contient des caractères non alphanumériques.
Problèmes de mise en réseau
- La carte réseau d'une machine virtuelle reçoit une liste non séquentielle des adresses MAC, même lorsque vous autorisez la sélection séquentielle d'adresses MAC à partir de pools d'adresses MAC
Si vous créez une machine virtuelle de base avec la sélection séquentielle d'adresses MAC, après un redémarrage de vCenter Server, l'ordre des adaptateurs réseau peut être non séquentiel. Si vous créez un clone à partir de la machine virtuelle de base, les adresses MAC du clone peuvent également être non séquentielles.
Solution : Vous devez ouvrir le menu Modifier de la machine virtuelle de base et cliquer sur OK pour vous assurer que les adaptateurs réseau sont triés comme prévu avant le clonage d'autres machines virtuelles.
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.
- 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.
