Notes de mise à jour de VMware NSX Data Center for vSphere 6.4.7

VMware NSX Data Center for vSphere 6.4.7 | Publié le 09 juillet 2020 | Build 16509800

Consultez l'Historique de révision de ce document.

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés
Versions, configuration système et installation
Fonctionnalités obsolètes et retirées
Notes relatives aux mises à niveau
Conformité FIPS
Historique de révision
Problèmes résolus
Problèmes connus

Nouveautés de NSX Data Center for vSphere 6.4.7

Informations importantes concernant NSX for vSphere 6.4.7

Remarque : VMware a identifié un problème concernant VMware NSX for vSphere 6.4.7, susceptible d'affecter tant les nouveaux clients NSX que ceux qui mettent à niveau une version antérieure de NSX. Par conséquent, VMware a décidé d'interrompre la distribution de NSX 6.4.7. La version actuelle disponible de NSX for vSphere est 6.4.6. VMware travaille activement à la publication de la nouvelle version afin de remplacer NSX for vSphere 6.4.7.

Reportez-vous à l'article 80238 de la base de connaissances VMWare pour obtenir plus de détails.

NSX Data Center for vSphere 6.4.7 ajoute des améliorations de facilité d'utilisation et de gestion et corrige un certain nombre de bogues spécifiques des clients. Pour plus d'informations, consultez Problèmes résolus.

Modifications introduites dans NSX Data Center for vSphere 6.4.7 :

Prise en charge de vSphere 7.0
Améliorations de la multidiffusion : Ajoute la prise en charge des éléments suivants :
- PIM sur un tunnel GRE, en excluant PIM sur toutes les autres liaisons montantes en même temps.
- Routes statiques utilisées par la connectivité de monodiffusion.
- Mode Veille active.
- Pare-feu Edge pour la multidiffusion.
- Pare-feu distribué pour la multidiffusion.
VMware NSX : mises à jour des fonctionnalités de vSphere Client (HTML) : Pour voir la liste des fonctionnalités prises en charge, consultez Fonctionnalités du plug-in VMware NSX for vSphere dans vSphere Client.

Versions, configuration système et installation

Remarque :

Le tableau ci-dessous répertorie les versions recommandées du logiciel VMware. Ces recommandations sont générales et ne doivent pas remplacer des recommandations spécifiques de l'environnement. Ces informations sont à jour à la date de publication de ce document.
Pour voir les versions minimales prises en charge de NSX et d'autres produits VMware, consultez la matrice d'interopérabilité des produits VMware. VMware déclare des versions minimales prises en charge en fonction de tests internes.

Produit ou composant	Version
NSX Data Center for vSphere	VMware recommande la dernière version de NSX pour les nouveaux déploiements. Lors de la mise à niveau de déploiements existants, consultez les notes de mise à jour de NSX Data Center for vSphere ou contactez votre représentant du support technique VMware pour plus d’informations sur les problèmes spécifiques avant de planifier une mise à niveau.
vSphere	Pour vSphere 6.5 : Recommandé : 6.5 Update 3 Remarque : vSphere 6.5 Update 1 résout le problème d'EAM qui échoue avec l'erreur OutOfMemory. Consultez l'article 2135378 de la base de connaissances de VMware pour plus d'informations. Important : Si vous utilisez le routage de multidiffusion sur vSphere 6.5, il est recommandé d'utiliser vSphere 6.5 Update 2 ou une version ultérieure. Si vous utilisez NSX Guest Introspection sur vSphere 6.5, il est recommandé d'utiliser vSphere 6.5 P03 ou une version ultérieure. Pour vSphere 6.7 : Recommandé : 6.7 Update 2 Important : Si vous utilisez NSX Guest Introspection sur vSphere 6.7, reportez-vous à l'article 57248 de la base de connaissances avant l'installation de NSX 6.4.6 et, pour plus d'informations, consultez le support client VMware. Remarque : vSphere 5.5 n'est pas pris en charge avec NSX 6.4. Remarque : vSphere 6.0 a atteint la fin du support général et n'est pas pris en charge à partir de NSX 6.4.7.
Guest Introspection pour Windows	Il est recommandé de mettre à niveau VMware Tools vers la version 10.3.10 avant de procéder à la mise à niveau de NSX for vSphere.
Guest Introspection pour Linux	Assurez-vous qu'une version de Linux prise en charge est installée sur la machine virtuelle invitée. Reportez-vous à Guide d'administration de VMware NSX pour obtenir la liste des versions Linux prises en charge.

Configuration système et installation

Pour obtenir la liste complète des prérequis à l'installation de NSX, consultez la section Configuration système pour NSX dans le Guide d'installation de NSX.

Pour obtenir des instructions d'installation, consultez le Guide d'installation de NSX ou le Guide d'installation de Cross-vCenter NSX.

Fonctionnalités obsolètes et retirées

Avertissements sur la fin de vie et la fin du support

Pour plus d'informations sur NSX et d'autres produits VMware devant être mis à niveau rapidement, consultez la Matrice du cycle de vie des produits VMware.

NSX for vSphere 6.1.x est arrivé en fin de disponibilité et a atteint sa date de fin de support général le 15 janvier 2017. (Consultez également l'article 2144769 de la base de connaissances de VMware.)
Arrêt de la prise en charge des dispositifs vCNS Edge. Vous devez effectuer une mise à niveau vers un dispositif NSX Edge avant de procéder à la mise à niveau vers NSX 6.3 ou version ultérieure.
NSX for vSphere 6.2.x a atteint sa date de fin de support général le 20 août 2018.
Conformément aux recommandations de sécurité, l'algorithme de chiffrement 3DES dans le service VPN IPsec de NSX Edge n'est plus pris en charge.
Il vous est recommandé de passer à l'un des chiffrements sécurisés disponibles dans le service IPsec. Cette modification concernant l'algorithme de chiffrement est applicable à IKE SA (phase1), ainsi qu'à la négociation IPsec SA (phase2) pour un site IPsec.

Si l'algorithme de chiffrement 3DES est utilisé par le service IPsec NSX Edge lors de la mise à niveau vers la version dans laquelle sa prise en charge est supprimée, il sera remplacé par un autre chiffrement recommandé et, par conséquent, les sites IPsec qui utilisaient 3DES ne démarrent pas, sauf si la configuration sur l'homologue distant est modifiée pour correspondre à l'algorithme de chiffrement utilisé dans NSX Edge.

Si vous utilisez le chiffrement 3DES, modifiez l'algorithme de chiffrement dans la configuration de site IPsec pour remplacer 3DES par l'une des variantes AES prises en charge (AES/AES256/AES-GCM). Par exemple, pour chaque configuration de site IPsec dont l'algorithme de chiffrement est 3DES, remplacez-le par AES. Mettez à jour en conséquence la configuration IPsec sur le point de terminaison homologue.

Changements généraux du comportement

Si vous disposez de plusieurs commutateurs vSphere Distributed Switch et que VXLAN est configuré sur l'un d'entre eux, vous devez connecter n'importe laquelle des interfaces de routeur logique distribué à des groupes de ports sur ce commutateur vSphere Distributed Switch. À partir de NSX 6.4.1, cette configuration s'applique dans l'interface utilisateur et l'API. Dans les versions antérieures, rien ne vous empêchait de créer une configuration non valide. Si vous procédez à la mise à niveau vers NSX 6.4.1 ou version ultérieure et que vous avez connecté les interfaces DLR de manière incorrecte, vous devez résoudre ce problème. Pour plus de détails, consultez les Notes relatives aux mises à niveau.

Modifications et suppressions dans l'interface utilisateur

Dans NSX 6.4.1, Canevas Service Composer est supprimé.
Dans NSX 6.4.7, la fonctionnalité suivante est déconseillée dans vSphere Client 7.0 :
- NSX Edge : SSL VPN-Plus (reportez-vous à l'article 79929 de la base de connaissances pour plus d'informations)
- Outils : Surveillance du point de terminaison (toutes les fonctionnalités)
- Outils : Surveillance de flux (tableau de bord de surveillance de flux, détails par service et configuration)
- Événements système : Enregistreur automatique de ticket NSX

Modifications du comportement de l'installation

À partir de la version 6.4.2, lorsque vous installez NSX Data Center for vSphere sur des hôtes disposant de cartes réseau physiques avec des pilotes ixgbe, la mise à l'échelle côté réception (RSS, Receive Side Scaling) n'est pas activée par défaut sur les pilotes ixgbe. Vous devez activer manuellement RSS sur les hôtes avant d'installer NSX Data Center. Veillez à activer RSS uniquement sur les hôtes disposant de cartes réseau avec des pilotes ixgbe. Pour accéder aux étapes détaillées sur l'activation de RSS, consultez l'article https://kb.vmware.com/s/article/2034676 de la base de connaissance de VMware. Cet article de la base de connaissances décrit les paramètres recommandés de RSS pour améliorer le débit des paquets VXLAN.

Ce nouveau comportement s'applique uniquement lorsque vous effectuez une nouvelle installation des modules de noyau (fichiers VIB) sur les hôtes ESXi. Aucune modification n'est requise lorsque vous mettez à niveau des hôtes gérés par NSX vers 6.4.2.

Suppressions d'API et modifications de comportement

Abandons dans NSX 6.4.2

L'élément suivant est obsolète et pourra être supprimé dans une version ultérieure :

GET/POST/DELETE /api/2.0/vdn/controller/{controllerId}/syslog. Utilisez GET/PUT /api/2.0/vdn/controller/cluster/syslog à la place.

Modifications de comportement dans NSX 6.4.1

Lorsque vous créez un pool d'adresses IP avec POST /api/2.0/services/ipam/pools/scope/globalroot-0 ou lorsque vous modifiez un pool d'adresses IP existant avec PUT /api/2.0/services/ipam/pools/et que plusieurs plages d'adresses IP sont définies sur le pool, une validation est effectuée pour vérifier que les plages ne se chevauchent pas. Cette validation n'était pas réalisée auparavant.

Abandons dans NSX 6.4.0
Les éléments suivants sont obsolètes et pourront être supprimés dans une version ultérieure.

Le paramètre systemStatus dans GET /api/4.0/edges/edgeID/status est obsolète.
GET /api/2.0/services/policy/serviceprovider/firewall/ est obsolète. Utilisez GET /api/2.0/services/policy/serviceprovider/firewall/info à la place.
Le paramètre tcpStrict dans la section de configuration globale du pare-feu distribué est obsolète. À partir de NSX 6.4.0, tcpStrict est défini au niveau de la section. Remarque : si vous effectuez une mise à niveau vers NSX 6.4.0 ou une version ultérieure, le paramètre de configuration globale pour tcpStrict est utilisé pour configurer tcpStrict dans chaque section de couche 3 existante. tcpStrict est défini sur false dans les sections de couche 2 et les sections de redirection de couche 3. Reportez-vous à la section « Utilisation de la configuration du pare-feu distribué » dans le Guide de NSX API pour plus d'informations.

Changements de comportement dans NSX 6.4.0
Dans NSX 6.4.0, le paramètre <name> est requis lorsque vous créez un contrôleur avec POST /api/2.0/vdn/controller.

NSX 6.4.0 présente les modifications suivantes liées à la gestion des erreurs :

Auparavant, POST /api/2.0/vdn/controller répondait avec 201 Créé pour indiquer que le travail de création du contrôleur est créé. Toutefois, la création du contrôleur peut toujours échouer. À partir de NSX 6.4.0, la réponse est 202 Accepté.
Auparavant, si vous envoyiez une demande d'API qui n'était pas autorisée en mode autonome ou de transit, l'état de réponse était 400 Demande incorrecte. À partir de la version 6.4.0, l'état de réponse est 403 Interdit.

Suppressions de CLI et modifications de comportement

N’utilisez pas les commandes non prises en charge sur les nœuds NSX Controller
Il existe des commandes non documentées pour configurer DNS et NTP sur les nœuds NSX Controller. Ces commandes ne sont pas prises en charge et ne doivent pas être utilisées sur les nœuds NSX Controller. Vous ne devez utiliser que les commandes qui sont documentées dans ce Guide de la CLI de NSX.

Notes relatives aux mises à niveau

Remarques générales sur la mise à niveau
Notes de mise à niveau pour les composants NSX
Notes de mise à niveau pour FIPS

Remarque : Pour obtenir une liste des problèmes connus affectant l’installation et les mises à niveau, consultez la section Problèmes connus d'installation et de mise à niveau.

Remarques générales sur la mise à niveau

Pour mettre NSX à niveau, vous devez réaliser une mise à niveau complète de NSX, y compris la mise à niveau du cluster d'hôte (les VIB de l'hôte sont alors mis à niveau). Pour obtenir des instructions, consultez le Guide de mise à niveau de NSX, y compris la section Mettre à niveau des clusters d'hôte.
La mise à niveau des VIB NSX sur des clusters d'hôtes à l'aide de VUM n'est pas prise en charge. Utilisez le Coordinateur de mise à niveau, Préparation de l'hôte ou les REST API associés pour mettre à niveau des VIB NSX sur des clusters d'hôtes.
Configuration système requise : pour plus d'informations sur la configuration système requise lors de l'installation et de la mise à niveau de NSX, consultez la section Configuration système requise pour NSX dans la documentation de NSX.
Chemin de mise à niveau de NSX : La matrice d'interopérabilité des produits VMware fournit des détails sur les chemins de mise à niveau à partir de VMware NSX.
La mise à niveau de cross-vCenter NSX est abordée dans le Guide de mise à niveau de NSX.
Les rétrogradations ne sont pas prises en charge :
- Capturez toujours une sauvegarde de NSX Manager avant de procéder à une mise à niveau.
- Lorsque NSX a été mis à niveau correctement, NSX ne peut pas être rétrogradé.
Pour vérifier que la mise à niveau vers NSX 6.4.x est réussie, consultez l'article 2134525 de la base de connaissances.
Il n'existe pas de support pour les mises à niveau depuis vCloud Networking and Security vers NSX 6.4.x. Vous devez d'abord effectuer une mise à niveau vers une version 6.2.x prise en charge.
Interopérabilité : consultez la Matrice d’interopérabilité des produits VMware pour tous les produits VMware pertinents avant d’effectuer la mise à niveau.
- Mise à niveau vers NSX Data Center for vSphere 6.4.7 : VIO n'est pas compatible avec NSX 6.4.7 en raison de plusieurs problèmes de dimensionnement.
- Mise à niveau vers NSX Data Center for vSphere 6.4 : NSX 6.4 n'est pas compatible avec vSphere 5.5.
- Mise à niveau vers NSX Data Center for vSphere 6.4.5 : Si NSX est déployé avec VMware Integrated OpenStack (VIO), mettez à niveau VIO vers la version 4.1.2.2 ou 5.1.0.1, car la version 6.4.5 est incompatible avec les versions précédentes en raison de la mise à jour du module de printemps vers la version 5.0.
- Mise à niveau vers vSphere 6.5 : lors de la mise à niveau vers vSphere 6.5a ou version ultérieure à la version 6.5, vous devez d'abord effectuer la mise à niveau vers NSX 6.3.0 ou version ultérieure. NSX 6.2.x n'est pas compatible avec vSphere 6.5. Consultez Mise à niveau de vSphere dans un environnement NSX dans le Guide de mise à niveau de NSX.
- Mise à niveau vers vSphere 6.7 : lors de la mise à niveau vers vSphere 6.7, vous devez d'abord effectuer la mise à niveau vers NSX 6.4.1 ou version ultérieure. Les versions antérieures de NSX ne sont pas compatibles avec vSphere 6.7. Consultez Mise à niveau de vSphere dans un environnement NSX dans le Guide de mise à niveau de NSX.
Compatibilité des services de partenaires : si votre site utilise des services de partenaires VMware pour Guest Introspection ou Network Introspection, vous devez examiner le Guide de compatibilité VMware avant la mise à niveau, afin de vérifier que le service de votre fournisseur est compatible avec cette version de NSX.
Plug-in Networking and Security : Après la mise à niveau de NSX Manager, vous devez vous déconnecter et vous reconnecter à vSphere Web Client. Si le plug-in NSX ne s'affiche pas correctement, videz le cache du navigateur et effacez l'historique. Si le plug-in Networking and Security ne figure pas dans vSphere Web Client, réinitialisez le serveur vSphere Web Client, comme expliqué dans le Guide de mise à niveau de NSX.
Environnements sans état : pour les mises à niveau de NSX dans un environnement d'hôtes sans état, les nouveaux VIB sont pré-ajoutés au profil d'image d'hôte lors du processus de mise à niveau de NSX. Par conséquent, le processus de mise à niveau de NSX sur des hôtes sans état s'effectue selon les étapes suivantes :
Dans les versions antérieures à NSX 6.2.0, une seule URL de NSX Manager permettait de trouver les VIB pour une version spécifique de l’hôte ESX. (L'administrateur n'avait alors qu'à connaître une seule URL, quelle que soit la version de NSX.) Dans NSX 6.2.0 et versions ultérieures, les nouveaux VIB NSX sont disponibles sur plusieurs URL. Pour trouver les VIB adéquats, vous devez procéder comme suit :
1. Recherchez la nouvelle URL du VIB sur https://<nsxmanager>/bin/vdn/nwfabric.properties.
2. Récupérez les VIB pour la version de l'hôte ESX requise à partir de l'URL correspondante.
3. Ajoutez-les au profil d'image d'hôte.
La fonctionnalité Définitions de services n'est pas prise en charge dans l'interface utilisateur de NSX 6.4.7 avec vSphere Client 7.0 :
Par exemple, si vous disposez d'une ancienne définition de service Trend Micro enregistrée avec vSphere 6.5 ou 6.7, suivez l'une des deux options suivantes :
- Option 1 : avant de procéder à la mise à niveau vers vSphere 7.0, accédez à l'onglet Définition de service de vSphere Web Client, modifiez la définition de service sur 7.0, puis effectuez la mise à niveau vers vSphere 7.0.
- Option 2 : après la mise à niveau vers vSphere 7.0, exécutez la NSX API suivante pour ajouter ou modifier la définition de service sur 7.0.

POST https://<nsmanager>/api/2.0/si/service/<service-id>/servicedeploymentspec/versioneddeploymentspec

Notes de mise à niveau pour les composants NSX

Prise en charge de la version 11 matérielle de la machine virtuelle pour les composants NSX

Pour les nouvelles installations de NSX Data Center for vSphere 6.4.2, les composants de NSX (Manager, Controller, Edge, Guest Introspection) utilisent la version 11 matérielle de la machine virtuelle.
Pour les mises à niveau vers NSX Data Center for vSphere 6.4.2, les composants NSX Edge et Guest Introspection sont automatiquement mis à niveau vers la version 11 matérielle de la machine virtuelle. Les composants NSX Manager et NSX Controller utilisent la version 8 du matériel de la machine virtuelle après une mise à niveau. Les utilisateurs ont la possibilité de mettre à niveau le matériel de la machine virtuelle vers la version 11. Pour plus d'instructions sur la mise à niveau des versions matérielles de la machine virtuelle, consultez l'article (https://kb.vmware.com/s/article/1010675) de la base de connaissances.
Pour les nouvelles installations de NSX 6.3.x, 6.4.0, 6.4.1, les composants de NSX (Manager, Controller, Edge, Guest Introspection) utilisent la version 8 matérielle de la machine virtuelle.

Mise à niveau de NSX Manager

Important : Si vous mettez à niveau NSX 6.2.0, 6.2.1 ou 6.2.2 vers NSX 6.3.5 ou version ultérieure, vous devez appliquer une solution avant de démarrer la mise à niveau. Consultez l'article 000051624 de la base de connaissances de VMware pour obtenir plus de détails.
Si vous mettez NSX 6.3.3 à niveau vers NSX 6.3.4 ou version ultérieure, vous devez d'abord suivre les instructions de solution de l'article 2151719 de la base de connaissances de VMware.
Si vous utilisez SFTP lors des sauvegardes NSX, choisissez sha2-hmac-256 après la mise à niveau vers la version 6.3.0 ou version ultérieure, car il n'y a aucune prise en charge pour hmac-sha1. Consultez l’article 2149282 de la base de connaissances de VMware pour obtenir la liste des algorithmes de sécurité pris en charge.
Lorsque vous mettez NSX Manager à niveau vers NSX 6.4.1, une sauvegarde est automatiquement effectuée et enregistrée localement dans le cadre du processus de mise à niveau. Pour plus d'informations, consultez Mettre à niveau NSX Manager.
Lorsque vous effectuez la mise à niveau vers NSX 6.4.0, les paramètres TLS sont conservés. Si seul TLS 1.0 est activé, vous pourrez afficher le plug-in dans vSphere Web Client NSX, mais les instances de NSX Manager ne sont pas visibles. Cela n'a aucune incidence sur le chemin de données, mais vous ne pouvez modifier la configuration d'aucune instance de NSX Manager. Connectez-vous à l'interface utilisateur Web de gestion du dispositif NSX à l'adresse https://nsx-mgr-ip/ et activez TLS 1.1 et TLS 1.2. Cela redémarre le dispositif NSX Manager.

Mise à niveau du contrôleur

Le cluster NSX Controller doit contenir trois nœuds de contrôleur. S’il dispose de moins de trois contrôleurs, vous devez ajouter des contrôleurs avant de commencer la mise à niveau. Pour obtenir des instructions, reportez-vous à Déployer le cluster NSX Controller.
Dans NSX 6.3.3, le système d’exploitation sous-jacent de NSX Controller change. Cela signifie que lorsque vous effectuez une mise à niveau de NSX 6.3.2 ou version antérieure vers NSX 6.3.3 ou version ultérieure, au lieu d'une mise à niveau logicielle sur place, les contrôleurs existants sont supprimés un à un et les nouveaux contrôleurs basés sur Photon OS sont déployés en utilisant les mêmes adresses IP.

Lorsque les contrôleurs sont supprimés, cela supprime également les règles d'anti-affinité de DRS associées. Vous devez créer des règles d'anti-affinité dans vCenter pour empêcher les nouvelles VM de contrôleur de résider sur le même hôte.

Pour plus d'informations sur les mises à niveau du contrôleur, consultez Mettre à niveau le cluster NSX Controller.

Mise à niveau du cluster d’hôte

Si vous mettez à niveau NSX 6.3.2 ou version antérieure vers NSX 6.3.3 ou version ultérieure, les noms des VIB NSX changent.
Les VIB esx-vxlan et esx-vsip sont remplacés par esx-nsxv si vous avez installé NSX 6.3.3 ou version ultérieure sur ESXi 6.0 ou version ultérieure.
Mise à niveau et désinstallation sans redémarrage sur les hôtes : dans vSphere 6.0 et versions ultérieures, une fois que vous avez mis à niveau NSX 6.2.x vers NSX 6.3.x ou version ultérieure, toutes les modifications suivantes apportées à des VIB NSX ne requièrent pas de redémarrage. Au lieu de cela, les hôtes doivent entrer en mode de maintenance pour terminer la modification de VIB. Cela affecte la mise à niveau du cluster d'hôtes NSX et la mise à niveau d'ESXi. Consultez le Guide de mise à niveau de NSX pour plus d'informations.

Mise à niveau de NSX Edge

Ajout d'une validation dans NSX 6.4.1 permettant d'interdire les configurations de routeur logique distribué non valides : dans les environnements où VXLAN est configuré et qui comportent plusieurs commutateurs vSphere Distributed Switch, les interfaces de routeur logique distribué doivent être connectées au commutateur vSphere Distributed Switch configuré pour VXLAN uniquement. La mise à niveau d'un DLR vers NSX 6.4.1 ou version ultérieure échoue dans les environnements où le DLR possède des interfaces connectées au commutateur vSphere Distributed Switch qui n'est pas configuré pour VXLAN. Utilisez l'API pour connecter les interfaces incorrectement configurées aux groupes de ports sur le commutateur vSphere Distributed Switch configuré pour VXLAN. Une fois la configuration valide, réessayez la mise à niveau. Vous pouvez modifier la configuration de l'interface à l'aide de PUT /api/4.0/edges/{edgeId} ou PUT /api/4.0/edges/{edgeId}/interfaces/{index}. Pour plus d'informations, consultez le Guide de NSX API.

Supprimez la VM de contrôle UDLR de vCenter Server associée à une instance secondaire de NSX Manager avant de mettre à niveau UDLR de la version 6.2.7 vers la version 6.4.5 :
Dans un environnement multivCenter, lorsque vous mettez à niveau des UDLR NSX de la version 6.2.7 vers la version 6.4.5, la mise à niveau du dispositif virtuel UDLR (VM de contrôle UDLR) échoue sur l'instance secondaire de NSX Manager, si HA est activé sur la VM de contrôle UDLR. Pendant la mise à niveau, la VM avec l'index ha n° 0 dans la paire HA est supprimée de la base de données NSX. Toutefois, cette VM continue d'exister sur le serveur vCenter Server. Par conséquent, lorsque la VM de contrôle UDLR est mise à niveau sur l'instance secondaire de NSX Manager, la mise à niveau échoue, car le nom de la VM est en conflit avec une VM existante sur le serveur vCenter Server. Pour résoudre ce problème, supprimez la VM de contrôle du serveur vCenter Server associé à l'UDLR sur l'instance secondaire de NSX Manager, puis mettez à niveau l'UDLR de la version 6.2.7 vers la version 6.4.5.
Les clusters d'hôtes doivent être préparés pour NSX avant la mise à niveau des dispositifs NSX Edge : La communication au niveau du plan de gestion entre les dispositifs NSX Manager et Edge via le canal VIX n'est plus prise en charge à partir de la version 6.3.0. Seul le canal de bus de messages est pris en charge. Lorsque vous effectuez une mise à niveau à partir de NSX 6.2.x ou version antérieure vers NSX 6.3.0 ou version ultérieure, vous devez vérifier que les clusters d'hôtes où sont déployés les dispositifs NSX Edge sont préparés pour NSX, et que l'état de l'infrastructure de messagerie s'affiche en VERT. Si les clusters d'hôtes ne sont pas préparés pour NSX, la mise à niveau du dispositif NSX Edge échouera. Reportez-vous à Mise à niveau de NSX Edge dans le Guide de mise à niveau de NSX pour plus de détails.

Mise à niveau d'Edge Services Gateway (ESG) :
À partir de NSX 6.2.5, la réservation de ressources est réalisée au moment de la mise à niveau de NSX Edge. Lorsque vSphere HA est activé sur un cluster disposant de ressources insuffisantes, l'opération de mise à niveau peut échouer en raison de contraintes vSphere HA non respectées.

Pour éviter de tels échecs de mise à niveau, procédez comme suit avant de mettre une passerelle ESG à niveau :

Les réservations de ressources suivantes sont utilisées par NSX Manager si vous n’avez pas explicitement défini des valeurs lors de l’installation ou de la mise à niveau.

NSX Edge Facteur de forme	Réservation de CPU	Réservation de mémoire
COMPACTE	1 000 MHz	512 Mo
GRANDE	2 000 MHz	1 024 Mo
SUPER GRANDE	4 000 MHz	2 048 Mo
EXTRA GRANDE	6 000 MHz	8 192 Mo

Veillez toujours à ce que votre installation suive les meilleures pratiques établies pour vSphere HA. Consultez l'article 1002080 de la base de connaissances.
Utilisez l'API de configuration de réglage NSX :
PUT https://<nsxmanager>/api/4.0/edgePublish/tuningConfiguration
en veillant à ce que les valeurs de edgeVCpuReservationPercentage et edgeMemoryReservationPercentage respectent les ressources disponibles pour le facteur de forme (voir les valeurs par défaut dans le tableau ci-dessus).

Désactiver l'option de démarrage de machine virtuelle de vSphere lorsque vSphere HA est activé et que des dispositifs Edge sont déployés. Après avoir mis à niveau vos dispositifs NSX Edge de la version 6.2.4 ou antérieure vers la version 6.2.5 ou ultérieure, vous devez désactiver l'option de démarrage de machine virtuelle de vSphere pour chaque dispositif NSX Edge dans un cluster dans lequel vSphere HA est activé et des dispositifs Edge sont déployés. Pour cela, ouvrez vSphere Web Client, recherchez l'hôte ESXi sur lequel réside la machine virtuelle NSX Edge, cliquez sur Gérer > Paramètres et, sous Machines virtuelles, sélectionnez Démarrage/Arrêt de la VM, cliquez sur Modifier et vérifiez que la machine virtuelle est en mode Manuel (c'est-à-dire qu'elle n'est pas ajoutée à la liste Démarrage/Arrêt automatique).
Avant de procéder à la mise à niveau vers NSX 6.2.5 ou version ultérieure, vérifiez que toutes les listes de chiffrement d'équilibrage de charge sont séparées par un signe deux-points. Si votre liste de chiffrement utilise un autre séparateur (par exemple, des virgules), effectuez un appel PUT à https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles et remplacez chaque liste <ciphers> </ciphers> dans <clientssl> </clientssl> et <serverssl> </serverssl> par une liste séparée par des deux-points. Par exemple, le segment pertinent du corps de demande peut ressembler à ce qui suit. Répétez cette procédure pour tous les profils d'application :
```
<applicationProfile>
  <name>https-profile</name>
  <insertXForwardedFor>false</insertXForwardedFor>
  <sslPassthrough>false</sslPassthrough>
  <template>HTTPS</template>
  <serverSslEnabled>true</serverSslEnabled>
  <clientSsl>
    <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
    <clientAuth>ignore</clientAuth>
    <serviceCertificate>certificate-4</serviceCertificate>
  </clientSsl>
  <serverSsl>
    <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
    <serviceCertificate>certificate-4</serviceCertificate>
  </serverSsl>
  ...
</applicationProfile>
```
Définir la version de chiffrement correcte pour les clients d'équilibrage de charge sur des versions de vROPs antérieures à la version 6.2.0 : les membres de pool vROPs sur des versions de vROPs antérieures à la version 6.2.0 utilisent TLS version 1.0 et, par conséquent, vous devez définir explicitement une valeur d'extension de moniteur en définissant "ssl-version=10" dans la configuration de l'équilibrage de charge NSX. Consultez Créer un contrôle de service dans le Guide d'administration de NSX pour plus d'informations.
```
{
                "expected" : null,
                "extension" : "ssl-version=10",
                "send" : null,
                "maxRetries" : 2,
              "name" : "sm_vrops",
              "url" : "/suite-api/api/deployment/node/status",
              "timeout" : 5,
              "type" : "https",
              "receive" : null,
              "interval" : 60,
              "method" : "GET"
           }
```
Après la mise à niveau vers NSX 6.4.6, les ponts et interfaces L2 sur un DLR ne peuvent pas se connecter à des commutateurs logiques appartenant à différentes zones de transport : Dans NSX 6.4.5 ou version antérieure, les instances et les interfaces de pont L2 sur un routeur logique distribué (DLR) utilisaient la prise en charge de commutateurs logiques qui appartenaient à des zones de transport différentes. À partir de NSX 6.4.6, cette configuration n'est pas prise en charge. Les instances et les interfaces de pont L2 sur un DLR doivent se connecter à des commutateurs logiques qui se trouvent dans une zone de transport unique. Si des commutateurs logiques de plusieurs zones de transport sont utilisés, la mise à niveau du dispositif Edge est bloquée lors des vérifications de validation préalables à la mise à niveau lorsque vous mettez à niveau NSX vers 6.4.6. Pour résoudre ce problème de mise à niveau Edge, assurez-vous que les instances et les interfaces de pont sur un DLR sont connectées à des commutateurs logiques dans une zone de transport unique.
Après la mise à niveau vers NSX 6.4.7, les ponts et interfaces sur un DLR ne peuvent pas se connecter à des dvPortGroups appartenant à différents VDS : si une telle configuration est présente, la mise à niveau de NSX Manager vers 6.4.7 est bloquée lors des vérifications de validation préalables à la mise à niveau. Pour résoudre ce problème, assurez-vous que les interfaces et les ponts L2 d'un DLR sont connectés à un seul VDS.
Après la mise à niveau vers NSX 6.4.7, le DLR ne peut pas être connecté à des groupes de ports reposant sur un VLAN si la zone de transport du commutateur logique auquel il est connecté s'étend sur plusieurs VDS : cela permet d'assurer un alignement correct des instances de DLR avec des dvPortgroups de commutateur logique entre les hôtes. Si une telle configuration est présente, la mise à niveau de NSX Manager vers 6.4.7 est bloquée lors des vérifications de validation préalables à la mise à niveau. Pour résoudre ce problème, assurez-vous qu'aucune interface logique n'est connectée à des groupes de ports reposant sur VLAN, si une interface logique existe avec un commutateur logique appartenant à une zone de transport couvrant plusieurs VDS.
Après la mise à niveau vers NSX 6.4.7, différents DLR ne peuvent pas disposer de leurs interfaces et ponts L2 sur un même réseau : si une telle configuration est présente, la mise à niveau de NSX Manager vers 6.4.7 est bloquée lors des vérifications de validation préalables à la mise à niveau. Pour résoudre ce problème, assurez-vous qu'un réseau est utilisé dans un seul DLR.

Notes de mise à niveau pour FIPS

Lorsque vous effectuez la mise à niveau depuis une version de NSX antérieure à NSX 6.3.0 vers NSX 6.3.0 ou version ultérieure, vous ne devez pas activer le mode FIPS avant la fin de la mise à niveau. L'activation du mode FIPS avant la fin de la mise à niveau interrompra la communication entre les composants mis à niveau et les composants non mis à niveau. Consultez Comprendre le mode FIPS et la mise à niveau de NSX dans le Guide de mise à niveau de NSX pour plus d'informations.

Chiffrements pris en charge sous OS X Yosemite et OS X El Capitan : Si vous utilisez le client VPN SSL sous OS X 10.11 (El Capitan), vous pourrez vous connecter à l'aide des chiffrements AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA38, AES256-SHA et AES128-SHA et, si vous utilisez OS X 10.10 (Yosemite), vous pourrez vous connecter à l'aide des chiffrements AES256-SHA et AES128-SHA uniquement.
N'activez pas FIPS avant la fin de la mise à niveau vers NSX 6.3.x. Consultez Comprendre le mode FIPS et la mise à niveau de NSX dans le Guide de mise à niveau de NSX pour plus d'informations.
Avant d'activer FIPS, vérifiez que les solutions de partenaire sont certifiées pour le mode FIPS. Consultez le Guide de compatibilité VMware et la documentation de partenaire correspondante.

Conformité FIPS

NSX 6.4 utilise des modules de chiffrement validés pour FIPS 140-2 pour la cryptographie liée à la sécurité lorsqu'ils sont correctement configurés.

Remarque :

Contrôleur et VPN de mise en cluster : NSX Controller utilise le VPN IPsec pour connecter des clusters de contrôleur. Le VPN IPsec utilise le module de chiffrement du noyau VMware Linux (environnement VMware Photon OS 1.0), qui est en cours de validation CMVP.
VPN IPsec Edge : Le VPN IPsec NSX Edge utilise le module de chiffrement du noyau VMware Linux (environnement VMware NSX OS 4.4), qui est en cours de validation CMVP.

Historique de révision du document

9 juillet 2020 : Première édition.
4 août 2020 : Deuxième édition. Ajout du problème connu 2614777.
17 août 2020 : Troisième édition. Ajout du problème résolu 2306230.

Problèmes résolus

Problème résolu 2445396 : les ports de pool d'équilibreur de charge sont effacés lors de la modification du pool d'équilibreur de charge suivie de « Enregistrer ».
Lors de la modification du pool d'équilibreur de charge et de l'enregistrement de la configuration, les numéros de port sur chaque membre sont effacés.
Problème résolu 2448235 : après la mise à niveau vers NSX-v 6.4.6, il est possible que vous ne puissiez pas filtrer les règles de pare-feu en utilisant le protocole, le port source et le port de destination.
Vous ne pourrez pas filtrer les règles de pare-feu en utilisant le filtre de protocole, de port source et de port de destination.
Problème résolu 2306230 : l'infrastructure de messagerie tombe en panne pour les hôtes en raison du délai de pulsation.
Les mots de passe des hôtes sont réinitialisés. Il se peut que les utilisateurs ne puissent pas configurer sur les hôtes pendant le temps de connexion.
Problème résolu 1859572 : lors de la désinstallation des VIB NSX version 6.3.x sur des hôtes ESXi gérés par vCenter 6.0.0, l'hôte reste en mode de maintenance.
Si vous désinstallez des VIB NSX version 6.3.x sur un cluster, le workflow implique de mettre les hôtes en mode de maintenance, de désinstaller les VIB et de retirer les hôtes du mode de maintenance par le service EAM. Toutefois, si ces hôtes sont gérés par vCenter Server 6.0.0, cela bloque l’hôte en mode de maintenance après la désinstallation des VIB. Le service EAM responsable de la désinstallation des VIB met l’hôte en mode de maintenance, mais ne parvient pas à l'en sortir.
Problème résolu 2006028 : la mise à niveau de l'hôte peut échouer si le système vCenter Server redémarre au cours de la mise à niveau.
Si le système vCenter Server associé est redémarré au cours de la mise à niveau d'un hôte, cette dernière peut échouer et laisser l'hôte en mode de maintenance. Le fait de cliquer sur Résoudre ne sort pas l'hôte du mode de maintenance. L'état du cluster est « Non prêt ».
Problème résolu 2233029 : ESX ne prend pas en charge 10 000 routes.
ESX n'a pas besoin de prendre en charge 10 000 itinéraires. Par conception, la limite maximale sur ESX est de 2 000 itinéraires.
Problème résolu 2391153 : NSX Manager ne met pas à jour le groupe vdn_vmknic_portgroup ni la table vdn_cluster lorsque les opérations vCenter sont effectuées sur le dvportgroup de la vmknic.
Lorsque vous exécutez la requête API PUT https://nsx_manager_ip/api/2.0/nwfabric/configure, NSX Manager ne met pas à jour le groupe vdn_vmknic_portgroup ni la table vdn_cluster lorsque les opérations vCenter sont effectuées sur le groupe de ports virtuels distribués de la vmknic. L'interface utilisateur de vCenter continue d'afficher l'ancien ID de VLAN.
Problème résolu 2367906 : l'utilisation du CPU sur le dispositif NSX Edge atteint 100 % lorsque le moniteur de service HTTP est configuré sur l'équilibrage de charge avec l'extension « no-body ».
Ce problème se produit lorsque vous configurez le moniteur de service HTTP avec l'extension « no-body » lors de l'utilisation du plug-in « nagios » dans l'équilibrage de charge. L'équilibrage de charge perd la connexion à tous les serveurs principaux, et la demande de l'utilisateur est interrompue.
Problème résolu 2449643 : vSphere Web Client affiche l'erreur « Aucune instance de NSX Manager disponible » après la mise à niveau de NSX de 6.4.1 vers 6.4.6.
Dans vSphere Web Client, les pages Pare-feu et Commutateur logique affichent le message d'erreur suivant :
« Aucune instance de NSX Manager disponible. Vérifiez que l'utilisateur actuel a un rôle attribué sur NSX Manager. »

Comme les pages Pare-feu et Commutateur logique ne sont pas disponibles dans l'interface utilisateur, il est possible que les utilisateurs ne puissent pas configurer des règles de pare-feu ou créer des commutateurs logiques. NSX API met également beaucoup de temps à répondre.

Dans le fichier /usr/nsx-webserver/logs/localhost_access_log, des entrées similaires aux suivantes s'affichent :
127.0.0.1 - - [27/Oct/2019:08:38:22 +0100] "GET /api/4.0/firewall/globalroot-0/config HTTP/1.1" 200 1514314 91262
127.0.0.1 - - [27/Oct/2019:08:43:21 +0100] "GET /api/4.0/firewall/globalroot-0/config HTTP/1.1" 200 1514314 90832

127.0.0.1 - - [27/Oct/2019:11:07:39 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 264142
127.0.0.1 - - [27/Oct/2019:11:07:40 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 265023
127.0.0.1 - - [27/Oct/2019:11:07:40 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 265265
Problème résolu 2551523 : la publication d'une nouvelle règle peut échouer si la règle contient une adresse IP à quatre zéros (0.0.0.0/0) après la mise à niveau de NSX 6.3.6 vers NSX 6.4.6.
Les règles de pare-feu avec l'adresse IP 0.0.0.0/0 dans la source ou la destination ne peuvent pas être publiées.
Problème résolu 2536058 : temps de réponse élevé de l'API depuis NSX Manager pour obtenir des API flowstats.
Lors de l'interrogation de la configuration du pare-feu et des IPSets, le temps de réponse de ces API est élevé.
Problème résolu 2513773 : les règles IDFW ne sont pas appliquées aux VDI après la suppression en milieu de session de leurs groupes de sécurité respectifs.
Les sessions VDI sont abandonnées de manière aléatoire en raison de la suppression des groupes de sécurité attachés aux règles IDFW.
Problème résolu 2509224 : un tableau de flux excessivement volumineux sur NSX Edge en HA entraîne des abandons de connexion.
Une synchronisation excessive du tableau de suivi des connexions du dispositif NSX Edge en veille au dispositif NSX Edge actif entraîne l'abandon de nouvelles connexions.
Problème résolu 2502739 : temps de réponse élevé de l'API de NSX Manager pour les API FW et IPSet.
Lors de l'interrogation de la configuration du pare-feu et des IPSets, le temps de réponse de ces API est élevé.
Problème résolu 2498988 : le temps de réponse est élevé lors de l'interrogation d'objets de regroupement.
Lors de l'interrogation d'objets de regroupement, le temps de réponse de ces API est élevé.
Problème résolu 2458746 : les configurations de LIF non prises en charge ont généré des PSOD sur plusieurs hôtes.
Les validations d'hôte ont été mises en œuvre pour éviter d'ajouter des LIF en double sur différents DLR.
Problème résolu 2452833 : un hôte ESXi effectuant la maintenance d'une VM de contrôle du DLR peut rencontrer un PSOD si le même VXLAN est consommé dans le pontage et dans un LIF dans deux DLR différents.
Un ESXi effectuant la maintenance de la VM de contrôle du DLR peut rencontrer un PSOD si le même câble virtuel est consommé dans le pontage et dans un LIF.
Problème résolu 2451586 : les règles d'application LB ne fonctionnent pas après la mise à niveau de NSX vers 6.4.6.
Lorsque des serveurs back-end HTTP(s) se trouvent derrière un équilibreur de charge NSX en tant que partie intégrante du dispositif NSX Edge, les clients communiquent avec les serveurs back-end via l'équilibreur de charge. L'équilibreur de charge envoie des en-têtes en minuscules, alors que les serveurs les ont envoyés en casse mixte.
Problème résolu 2448449 : les règles d'application configurées avec req_ssl_sni peuvent échouer avec une erreur d'analyse lors de la mise à niveau vers NSX for vSphere 6.4.6.
Lors de la mise à niveau vers NSX for vSphere 6.4.6, si un équilibreur de charge est configuré avec une règle liée à une SNI ou lorsque vous créez ou configurez une nouvelle règle associée à une SNI dans cette version, vous pouvez rencontrer un problème au cours duquel la mise à niveau ou la création de la règle associée échoue.
Problème résolu 2444275 : l'hôte rencontrera un PSOD lorsque la fonctionnalité de latence de l'infrastructure virtuelle est activée.
L'hôte ESXi rencontre un PSOD lorsque la fonctionnalité de latence de l'infrastructure virtuelle est activée sur VRNI dans un environnement composé de plus de 975 tunnels BFD par hôte. Dans un environnement d'échelle, l'hôte ESXi rencontre un PSOD si la latence est activée.
Problème résolu 2493095 : prise en charge des listes d'adresses IP séparées par des virgules dans DFW supprimée de l'interface utilisateur et de la base de données.
Lors de la mise à niveau de versions antérieures de NSX-v vers NSX-v 6.4.6, des adresses IP séparées par des virgules dans DFW ont été supprimées. Les utilisateurs disposant d'une configuration de pare-feu existante qui ont des adresses IP séparées par des virgules n'ont pas pu mettre à jour la configuration.
Problème résolu 2459936 : impossible de diviser le réseau en deux parties à l'aide de routes statiques avec réseau (0.0.0.0/1 et 128.0.0.0/1).
NSX 6.4.0 vers 6.4.6 a autorisé l'itinéraire statique avec un réseau 0.0.0.0/0 uniquement. À partir de NSX 6.4.7, l'ajout d'une route statique avec un réseau 0.0.0.0/x est autorisé, où 0 <= x <= 32.
Problème résolu 2430886 : état d'hôte incorrect affiché dans la base de données NSX Manager pour les clusters désactivés.
La page Préparation de l'hôte affiche une erreur pour l'état du pare-feu même lorsqu'il est activé sur le cluster.
Problème résolu 2383382 : dans la liste des commandes par défaut de l'interface de ligne de commande NSX Manager, la commande Supprimer affiche des informations d'aide incorrectes.
Les informations d'aide pour la commande Suppression s'affichent en tant que « Afficher les informations système en cours d'exécution ».
Problème résolu 2407662 : le service Guest Introspection ne fonctionne pas lorsque l'hôte ESXi et vCenter Server redémarrent simultanément.
L'état du service Guest Introspection n'est pas vert après le redémarrage de l'hôte ESXi ou lorsque la machine virtuelle GI est mise sous tension manuellement alors que vCenter n'était pas en cours d'exécution.

Le message d'erreur suivant s'affiche dans « /usr/local/usvmmgmt/logs/eventmanager.log » :
```
ERREUR taskScheduler-4 PasswordChangeHelper:139 - Cmd ne se ferme pas normalement, valeur de sortie = 1
```
Problème résolu 2410743 : la connexion des interfaces logiques d'un DLR aux dvPorGgroups de plusieurs commutateurs vSphere Distributed Switch entraîne une interruption du trafic sur certaines interfaces logiques.
Le trafic sur certaines interfaces logiques ne fonctionne pas correctement. Les hôtes indiquent que des interfaces logiques sont attachées à des commutateurs vSphere Distributed Switch incorrects.
Problème résolu 2413213 : les tâches de maintenance ne sont pas planifiées et la table ai_useripmap augmente.
La table « ai_useripmap » n'est pas nettoyée.
Problème résolu 2430753 : lors de la création d'un pool d'adresses IP, si de l'espace est ajouté dans l'adresse IP de la passerelle, l'hôte ESXi ne crée pas l'adresse IP de la passerelle pour le VTEP.
La connectivité VTEP à VTEP est interrompue en raison d'une passerelle manquante dans la configuration du pool d'adresses IP.
Problème résolu 2438649 : certains routeurs logiques distribués sur l'hôte perdent toutes leurs interfaces logiques.
Les machines virtuelles perdent la connectivité avec le DLR en raison d'interfaces logiques manquantes sur le DLR.
Problème résolu 2439627 : impossible d'obtenir le fichier muxconfig.xml sur l'hôte ESXi après la mise à niveau de NSX Manager.
Le service Guest Introspection n'est pas disponible. L'état du service GI affiche le message d'avertissement suivant pour tous les hôtes :
```
Le service Guest Introspection n'est pas prêt.
```
Problème résolu 2440903 : l'utilisation de l'interface de ligne de commande centralisée NSX pour NSX Edge affiche les données du dispositif Edge passif.
La sortie de l'interface de ligne de commande centralisée de NSX pour NSX Edge peut provenir d'une machine virtuelle Edge incorrecte.
Problèmes résolus 2445183, 2454653 : après le remplacement du certificat SSL du dispositif NSX Manager, il n'est pas disponible dans l'inventaire vSphere.
Le message d'erreur suivant s'affiche dans vSphere Client :
```
Aucune instance de NSX Manager disponible. Vérifiez que l'utilisateur actuel a un rôle attribué sur NSX Manager.
```
Problème résolu 2446265 : vSphere Web Client envoie le GUID de vCenter comme NULL dans l'appel d'API lors de la récupération de la liste des machines virtuelles exclues.
Dans vSphere Web Client, lorsque vous cliquez sur le bouton Ajouter pour ajouter de nouveaux membres (machines virtuelles) à la liste d'exclusion, le message d'erreur suivant s'affiche avant que toutes les données soient chargées dans l'interface utilisateur :
```
Échec de communication avec vCenter Server.
```
La boîte de dialogue Ajouter des membres exclus ne s'affiche pas correctement.
Problème résolu 2447697 : NSX Edge passe à un état incorrect en raison d'une panne de configuration et d'un échec de restauration.
Le dispositif Edge devient gérable après l'échec de la configuration.
Problème résolu 2453083 : une entrée périmée dans la table vnvp_vdr_instance provoque l'échec des mises à jour de la configuration du DLR et n'entraîne pas d'interfaces logiques sur l'hôte.
Le flux de trafic est interrompu. La tentative de redéploiement, de synchronisation ou de mise à niveau du DLR échoue.
Problème résolu 2460987 : la VM de service obtient des trames balisées par priorité.
Les trames encapsulées VXLAN sur les liaisons montantes avec dot1p bit défini entraînent la réception par SVM des trames balisées de priorité. Les paquets sont abandonnés sur les ports SVM.
Problème résolu 2461125 : sur la page Tableau de bord du système NSX, le nombre de voisins BGP incorrect s'affiche pour UDLR.
Un problème se produit en raison de plusieurs entrées pour la fonctionnalité de routage dans la table edge_service_config.
Problème résolu 2465697 : le déploiement du contrôleur échoue lorsque la version de NSX Manager est 6.4.x et que celle des contrôleurs NSX est 6.3.x
Lorsque NSX Manager est mis à niveau de la version 6.3.x vers 6.4.x, avant que les contrôleurs NSX soient mis à niveau vers la version 6.4.x, si vous déployez des contrôleurs NSX 6.3.x, le déploiement échoue, car le serveur Syslog n'est pas pris en charge dans la version 6.3.x.
Problème résolu 2465720 : lors de la mise à jour des dispositifs virtuels Edge pour Edge-A, involontairement, les dispositifs virtuels Edge-B sont également mis à jour.
Edge-A et Edge-B entrent dans l'état de redéploiement. En raison de modifications non souhaitées ou involontaires apportées à d'autres dispositifs Edge, plusieurs problèmes peuvent se produire, tels que la latence du réseau, l'impact sur les services d'entreprise, etc.
Problème résolu 2467360 : le service Guest Introspection est bloqué dans un état d'avertissement, car une machine virtuelle n'est pas présente dans l'inventaire NSX.
Le service Guest Introspection est bloqué dans un état d'avertissement, car une VM est introuvable pendant la surveillance de l'état de santé du point de terminaison. Le XML d'état de santé envoyé par Mux contient une machine virtuelle qui n'est pas présente dans l'inventaire de NSX.
Problème résolu 2468786 : le suspect interrompu avant la synchronisation d'Active Directory provoque l'intégrité de la base de données (ai_group avec primary_id null) et empêche toute future synchronisation d'Active Directory, ce qui entraîne des mises à jour futures non visibles dans NSX.
La synchronisation d'Active Directory continue d'échouer et les futures modifications d'Active Directory ne sont pas visibles par NSX. Tandis que les règles de pare-feu existantes fonctionnent pour les utilisateurs et les groupes existants, les modifications d'Active Directory ne sont pas visibles par NSX. Les utilisateurs ne peuvent pas voir les nouveaux groupes Active Directory ou les autres modifications d'Active Directory (nouveaux utilisateurs, utilisateurs supprimés, utilisateurs ajoutés ou supprimés des groupes Active Directory, etc.).
Problème résolu 2470918 : les commandes CLI associées à « show ip bgp * » génèrent un vidage de mémoire.
Les routes sont supprimées jusqu'au redémarrage du démon de routage. Cela entraîne une interruption de service jusqu'à ce que les routes soient rajoutées.
Problème résolu 2475392 : lorsque le même commutateur logique est utilisé en tant que pont et interface logique dans deux DLR différents, un PSOD peut se produire sur l'hôte où se trouve la VM de contrôle du DLR avec le pont.
Une telle configuration peut se produire lorsque la configuration est effectuée sur le deuxième DLR avant la fin du travail en attente sur le premier DLR. Avant le PSOD (Purple Screen of Death), le message d'erreur suivant s'affiche dans le fichier vsm.log :
```
Impossible de connecter deux routeurs Edge distribués edge-A et edge-B sur le même réseau virtualwire-x.
```
Problème résolu 2478262 : la commande « show host <host-id> health-status » affiche l'état critique même lorsque la communication entre les contrôleurs est saine.
L'état de santé indiqué par cette commande est un faux positif. Il n'y a aucun impact sur la fonctionnalité.
Problème résolu 2479599 : le processus vserrdd sature l'utilisation du CPU.
Le CPU est saturé, ce qui affecte probablement les autres processus.
Problème résolu 2480450 : bogue dans le chemin d'erreur lorsque l'hôte ESXi n'a plus de mémoire de segment.
Un PSOD peut se produire lorsque l'hôte ESXi manque de mémoire dans le segment de mémoire à un moment inopportun.
Problème résolu 2488759 : chemin de banque de données incorrect dans la base de données NSX Manager dans Storage vMotion.
Le MUX se bloque à plusieurs reprises et le système d'exploitation invité s'arrête fréquemment.
Problème résolu 2491042 : charge de CPU élevée sur NSX Manager causée par le processus postgres.
Les processus postgres consomment presque toute la ressource de CPU, comme vu par la commande Top.
Problème résolu 2491749 : le paquet SYN retransmis n'est pas toujours géré correctement dans le code de suivi de machine de l'état TCP.
En fonction des numéros de séquence, un paquet SYN retransmis peut provoquer une perte de paquets ultérieure.
Problème résolu 2491914 : lors de l'utilisation de l'extensibilité réseau (NetX), après vMotion, les sessions TCP établies ne respectent pas le délai d'expiration de l'état.
Après la migration par vMotion des états avec NetX, bien que la session TCP se poursuive, le temporisateur d'inactivité démarre et se termine après 12 heures. La session TCP se termine de manière inattendue et les flux sont perturbés.
Problème résolu 2499225 : le relais DHCP sur un routeur logique distribué ne transmet pas correctement la diffusion.
Lorsqu'une machine cliente envoie un message de détection ou de demande DHCP avec le bit de diffusion défini, le relais DHCP sur le DLR n'envoie pas de paquet de réponse comme diffusion. Cela peut amener certaines machines clientes à ne pas recevoir le paquet de réponse.
Problème résolu 2503002 : l'opération de publication de DFW arrive à expiration, mais les règles sont toujours publiées.
Ce problème se produit dans un environnement à grande échelle avec un grand nombre de règles DFW. La page DFW se charge lentement dans l'interface utilisateur. Le fichier localhost_access_log.txt indique que l'API de publication du pare-feu prend plus de 2 minutes. L'API publie la configuration de la règle DFW. Cependant, dans l'interface utilisateur, le message d'expiration de délai d'attente s'affiche.
Problème résolu 2506402 : l'interface utilisateur Edge et l'interface de ligne de commande sur la machine virtuelle indiquent des divergences pour les connexions simultanées.
À partir de NSX 6.4.0, une amélioration du basculement rapide de HA a synchronisé les flux du nœud Edge actif vers le nœud Edge en veille. Cela a entraîné l'affichage en double des données de statistiques dans l'interface Edge.
Problème résolu 2510798 : le champ Description du dispositif NSX Edge ne peut pas être modifié après le déploiement.
Le champ Description ne peut pas être modifié à partir de l'interface utilisateur et de l'API après le déploiement du dispositif Edge.
Problème résolu 2524239 : le journal des modifications d'état de BFD ne peut pas être imprimé sur le serveur Syslog.
Le journal des modifications d'état de BFD est imprimé en tant que message incomplet et le serveur Syslog ne peut pas le recevoir.
Problème résolu 2531966 : l'opération de publication de la règle de pare-feu entraîne un délai d'expiration de vCenter.
Lorsque la configuration du pare-feu atteint 7 000 règles, l'ajout ou la suppression de la section de règles de pare-feu entraîne un délai d'expiration de communication de vCenter et de NSX Manager.
Problème résolu 2541643 : la tâche de purge ne gère pas les tâches avec le type de planification FIXED_DATE.
Le système peut ralentir en raison d'un espace disque faible ou d'une consommation de mémoire élevée. Les tables associées aux tâches contiennent un grand nombre d'enregistrements.
Problème résolu 2544344 : impossible de créer un tunnel GRE avec des utilisateurs non-administrateurs auxquels des privilèges d'administrateur sont attribués.
Les utilisateurs non-administrateurs disposant de privilèges d'administrateur d'entreprise complets ne peuvent pas créer de tunnels GRE. Cependant, l'administrateur peut créer des tunnels GRE.
Problème résolu 2554069 : l'équilibrage de charge sur NSX Edge se bloque dans NSX 6.4.6.
Les erreurs de segmentation suivies par le service HAProxy redémarrent fréquemment.
Problème résolu 2556706 : impossible de spécifier un nom de domaine complet local pour certaines configurations sur le NSX Controller.
Dans l'API Syslog de NSX Controller, lorsque l'adresse locale est spécifiée en tant que nom de domaine complet, la configuration échoue.
Problème résolu 2560152 : un PSOD se produit sur l'hôte ESXi lors de l'exportation des bundles de journaux de l'hôte dans le cluster NSX préparé.
Ce problème se produit lorsqu'il y a plus de 100 VTEP sur un commutateur logique. Vmkernel zdumps générés sur /var/core.
Problème 2560422 : l'interface utilisateur n'affiche pas les données correctes sur la page Liste d'exclusion de machines virtuelles.
Plusieurs appels d'API sont effectués par l'interface utilisateur pour récupérer la liste d'exclusion. Les données se chargent lentement sur la page Liste d'exclusion dans l'interface utilisateur. La page peut afficher uniquement une partie de la liste d'exclusion dans la grille.
Problème résolu 2561009 : le démon du serveur VPN SSL se bloque lorsqu'un grand nombre d'utilisateurs essayent de se connecter avec des informations d'identification d'utilisateur uniques.
Le démon VPN SSL se bloque et redémarre.
Problème résolu 2566512 : le pare-feu NSX Edge ne prend pas en charge les règles de pare-feu configurées avec une requête d'appartenance IGMP, de rapport et de sortie.
Le dispositif NSX Edge ne prend pas encore en charge les services de sortie et d'appartenance IGMP.
Problème résolu 2567085 : le processus VSFWD peut se bloquer en raison d'un traitement du nombre de correspondances de règles.
Fichier de base VSFWD visible sur l'hôte avec suivi arrière pointant vers le traitement des correspondances de règles. La surveillance VSFWD redémarre automatiquement le processus après le blocage.
Problèmes résolus 2444941, 2574374 : dans un environnement NSX à grande échelle, un PSOD se produit sur les hôtes ESXi lorsque la latence est activée.
Lorsque BFD est activé, la mesure de latence du réseau est activée. Un PSOD peut se produire lorsque le nombre de sessions BFD est supérieur à 975.
Problème résolu 2586872 : le démon du serveur VPN SSL se bloque lorsque l'utilisateur tente de modifier le mot de passe du client VPN SSL et que la session est introuvable.
Le démon VPN SSL se bloque et redémarre. Toutes les sessions VPN SSL existantes sont terminées et doivent être redémarrées. Tous les clients VPN SSL vont perdre leur session et devront se reconnecter au serveur VPN SSL.
Problème résolu 2358130 : lorsque des ensembles d'adresses globaux sont activés et qu'une exportation vMotion se produit, les tables ne sont pas migrées vers l'hôte de destination.
vMotion peut se terminer correctement, mais les tables n'existent pas sur l'hôte de destination tant que la configuration n'est pas publiée à partir du plan de gestion.

Dans le fichier vmkernel.log sur l'hôte source, le message suivant s'affiche :
```
Échec de la création de tbl : -1
```
Problème résolu 2382346 : lorsque le serveur de journaux des événements WIN2K8 est ajouté à l'aide de l'interface utilisateur, il est détecté de manière incorrecte comme WIN2K3.
L'identification de la fonctionnalité de pare-feu (IDFW) s'interrompt.
Problème résolu 2397810 : lorsque les paramètres régionaux de l'interface utilisateur de NSX Manager sont définis sur l'anglais des États-Unis (en_US) et que les paramètres régionaux du navigateur sont définis sur le français, certains champs de Syslog ne sont pas correctement journalisés en français.
Les modifications apportées aux règles de pare-feu sont journalisées en français sur le serveur Syslog au lieu d'être journalisées en anglais.
Problème résolu 2417536 : la translation IP des groupes de sécurité avec des pools de ressources en tant que membres consomme beaucoup de mémoire et de CPU lorsqu'il y a plusieurs vNIC par machine virtuelle dans le système.
Une utilisation élevée du CPU entraîne le redémarrage fréquent de NSX Manager.
Problème résolu 2449644 : la file d'attente des tâches de NSX Manager est surchargée.
Les actions du plan de gestion ne sont pas réalisées sur l'hyperviseur.

Problème résolu 2459817 : la synchronisation de l'inventaire NSX échoue à plusieurs reprises.

Des UUID d'instance similaires sont détectés dans vCenter pour différentes machines virtuelles. Les mêmes ID de vNIC sont alors générés pour différentes vNIC. Les utilisateurs doivent détecter ce problème dans le fichier vsm.log.

Par exemple, les messages d'informations suivants s'affichent dans le fichier vsm.log :

INFO ViInventoryThread VimVnic:159 - - [nsxv@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Existing portgroupId : null , New portgroupId : dvportgroup-40  << indicate network change INFO ViInventoryThread VimVnic:217 - - [nsxv@6876 comp="nsx-manager" level="INFO" subcomp="manager"] network id : dvportgroup-40 , vnic id : 501c0ab1-e03c-b3ee-b662-9fd4649005d4.000 <= vnic id derived from instance uuid 501c0ab1-e03c-b3ee-b662-9fd4649005d4.

Problème résolu 2462523 : latence élevée observée dans le trafic de la machine virtuelle.
Un nombre élevé d'évolutions de la configuration NSX entraîne une latence sur la machine virtuelle. Lorsqu'un grand nombre de configurations atteignent l'hyperviseur, le plan de contrôle local tente de configurer le chemin d'accès aux données, ce qui bloque momentanément le trafic et entraîne une latence. L'évolution de la configuration peut être créée par des machines virtuelles mises continuellement sous tension ou hors tension dans un centre de données où ces machines virtuelles sont utilisées dans des groupes.

Pour atténuer ce problème, activez l'ensemble d'adresses globales qui réduira la configuration à une seule instance plutôt qu'une instance par filtre sur l'hyperviseur. Vous pouvez également laisser le nombre de filtres à environ 25 à 40.
Problème résolu 2535292 : un CIDR IPv6 supérieur à /64 n'est pas accepté en raison de la validation du plan de gestion.
La règle de pare-feu échoue lorsqu'elle contient un CIDR IPv6 avec un préfixe supérieur à /64 dans la source ou la destination de la définition de la règle.
Problème résolu 2214872 : dans le cadre de l'intégration de vSphere Update Manager et d'ESX Agent Manager, EAM appelle l'API VUM ImportFile avec l'URL http et le bundle de téléchargement VUM à partir de cette URL.
L'API VUM FileUploadManagerImpl::ImportFile() est conçue pour fonctionner uniquement avec des URL qui contiennent une extension ou au moins ".". Si cette condition n'est pas satisfaite, la méthode GetUrlFileNameExtension() génère une exception. Les agences vSphere EAM correspondant aux clusters de l'onglet Préparation de l'hôte NSX-V sont affichées comme ayant échoué.

Problèmes connus

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

Problèmes connus de mise à niveau et d'installation
Problèmes connus généraux
Problèmes connus liés à la mise en réseau logique et à NSX Edge
Problèmes d'interopérabilité

Problèmes connus de mise à niveau et d'installation

Avant d'effectuer la mise à niveau, lisez la section antérieure Notes relatives aux mises à niveau.

Problème 1263858 : le VPN SSL n'envoie aucune notification de mise à niveau au client distant.
La passerelle VPN SSL n'envoie pas de notification de mise à niveau aux utilisateurs. L'administrateur doit informer manuellement les utilisateurs distants que la passerelle VPN SSL (serveur) est mise à jour et qu'ils doivent mettre à jour leurs clients.

Solution : les utilisateurs doivent désinstaller l'ancienne version du client et installer la dernière version manuellement.
Problème 2429861 : la latence end2end ne s'affichera pas sur l'interface utilisateur vRNI après la mise à niveau vers NSX-v 6.4.6.
La latence end2end est interrompue avec vRNI Interop pour vRNI 4.2 et vRNI 5.0.

Solution : mettez à niveau vRNI vers 5.0.0-P2.
Problème 2417029 : chemin d'accès incorrect pour les objets de domaine dans la base de données de NSX Manager.
- La mise à niveau ou le redéploiement de NSX Edge échoue avec le message d'erreur suivant :
```
Cluster/ResourcePool resgroup-XXX doit être préparé pour que l'infrastructure réseau puisse mettre à niveau edge edge-XX.
```
- La liste déroulante des dossiers n'affiche pas tous les dossiers de machine virtuelle dans la boîte de dialogue Ajouter un contrôleur.
- Un ou plusieurs clusters peuvent entraîner un état Non prêt.
Solution : contactez le Support VMware pour résoudre ce problème.
Problème 2238989 : après la mise à niveau de vSphere Distributed Switch sur l'hôte ESXi, la fonctionnalité RSS du logiciel du VDS ne prend pas effet.
Dans les hôtes disposant d'une mise à l'échelle côté réception de logiciel (SoftRSS) activée, la propriété VDS com.vmware.net.vdr.softrss ne peut pas être restaurée après la mise à niveau de VDS. Cela entraîne la désactivation de SoftRSS. Le fichier /var/run/log/vmkernel.log affiche les erreurs liées à la configuration de la propriété softrss.

Solution :

avant de procéder à la mise à niveau de VDS, supprimez la propriété SoftRSS et reconfigurez-la après la mise à niveau de VDS.
Problème 2107188 : lorsque le nom d'un commutateur VDS contient des caractères non-ASCII, la mise à niveau des VIB de NSX échoue sur les hôtes ESXi.
Le fichier /var/run/log/esxupdate.log affiche l'état de la mise à niveau.

Solution :

modifiez le nom du VDS pour utiliser des caractères ASCII et effectuez une nouvelle mise à niveau.
Problème 2590902 : après la mise à niveau vers NSX 6.4.7, lorsqu'une adresse IPv6 statique est attribuée à des machines virtuelles de charge de travail sur un réseau IPv6, elles ne parviennent pas à effectuer un test Ping de l'interface de passerelle IPv6 du dispositif Edge.
Ce problème se produit après la mise à niveau des vSphere Distributed Switches de la version 6.x vers la version 7.0.

Solution 1 :

Sélectionnez le VDS où tous les hôtes sont connectés, accédez au paramètre Modifier et, sous Option de multidiffusion, basculez vers De base.

Solution 2 :

Ajoutez les règles suivantes sur le pare-feu Edge :
- Règle d'autorisation de test Ping.
- Règle d'autorisation MLD (Multidiffusion Listener Discovery) : il s'agit d'icmp6 types 130 (v1) et 143 (v2).

Problèmes connus généraux

Dans vSphere Web Client, lorsque vous ouvrez un composant Flex qui chevauche une vue HTML, la vue devient invisible.
Lorsque vous ouvrez un composant Flex, par exemple un menu ou une boîte de dialogue, qui chevauche une vue HTML, la vue est temporairement masquée.
(Référence : http://pubs.vmware.com/Release_Notes/en/developer/webclient/60/vwcsdk_600_releasenotes.html#issues)

Solution : aucune.
Problème 2543977 : le collecteur IPFIX de pare-feu distribué ne parvient pas à afficher les flux des ports UDP 137 ou 138.
Lorsqu'IPFIX est activé sur le DFW, les flux NetBIOS avec les ports 137 ou 138 ne sont pas envoyés par l'hôte.

Solution :

Utilisez vSphere Client ou NSX REST API pour supprimer les ports exclus 137 ou 138 des exclusions de flux.
Problème 2302171, 2590010 : lorsqu'IPFIX est activé sur un vSphere Distributed Switch avec un taux d'échantillonnage de 100 %, le débit chute.
La dégradation des performances du chemin de données survient et le débit sur ce dernier se réduit à la moitié de la limite de bande passante du canal réseau.

Solution : définissez le taux d'échantillonnage sur une valeur inférieure à 10 %.
Problème 2574333 : la configuration de vNIC Edge prend plus de deux minutes lorsque NAT est configurée avec 8 000 règles.
vSphere Client indique que NSX Manager n'est pas disponible. L'interface utilisateur expire au bout de deux minutes. La configuration de vNIC se termine correctement au bout de 2-3 minutes.

Solution : Aucune
Problème 2443830 : une dégradation des performances des chemins de données se produit sur le réseau VXLAN lors de l'utilisation du pilote de carte réseau ixgben.
Le débit sur le réseau VXLAN est réduit.

Solution :
- exécutez la commande suivante sur l'hôte ESXi :
```
esxcli system module parameters set -p "RSS=1,1" -m ixgben
```
- Redémarrez l'hôte.
Problème 2547022 : lorsqu'un nouvel utilisateur Active Directory est ajouté dans le groupe Active Directory enfant, l'utilisateur n'est pas inclus dans le groupe de sécurité basé sur le groupe Active Directory parent.
Le groupe de sécurité basé sur l'Active Directory parent ne contient pas l'utilisateur.

Solution :

ajoutez des groupes de sécurité basés sur le groupe Active Directory enfant.
Problème 2614777 : la publication de la règle DFW échoue si une règle se compose de deux services avec un port de service ou une plage de ports de service qui se chevauchent.
Échec de la publication de la règle DFW.

Solution : Pour plus d'informations, consultez l'article 80238 de la base de connaissances VMware.

Problèmes connus liés à la mise en réseau logique et à NSX Edge

Problème 1993241 : la redondance du tunnel IPsec utilisant le routage statique n'est pas prise en charge
Le trafic IPsec échouera si le tunnel principal tombe en panne. Une interruption du trafic s'ensuivra. Ce problème est connu depuis NSX 6.4.2.

Solution : désactivez et activez le service.
Problème 2430805, 2576416 : Les instances du DLR sont envoyées à tous les hôtes NSX préparés qui sont connectés à VDS.
Les problèmes impliquant une instance de VLAN désignée sont affichés. Le trafic VLAN est perturbé lorsque l'instance de VLAN désignée se trouve sur un hôte non valide.

Solution :
- Configurez VXLAN sur les hôtes NSX préparés avec le même VDS.
- Redémarrez l'hôte afin qu'il obtienne la nouvelle configuration.
Problème 2576294 : lorsque les interfaces logiques d'un DLR sont connectées à plusieurs VDS, elles sont attachées à un VDS incorrect sur l'hôte lorsque celui-ci fait partie de deux VDS VXLAN.
Si le DLR est synchronisé ou redéployé dans un état mal configuré, toutes les interfaces logiques du DLR sont attachées au VDS incorrect. En outre, les interfaces logiques de tous les nouveaux DLR sont attachées à un VDS incorrect sur l'hôte. Le trafic du chemin de données est perturbé.

Solution :
- supprimez le deuxième VDS qui n'est pas utilisé pour la préparation VXLAN du cluster.
- Selon l'état actuel de la configuration de l'hôte, redéployez/forcez la synchronisation ou synchronisez le service de route pour corriger la configuration sur l'hôte.
Problème 2582197 : lorsqu'une interface NSX Edge est configurée avec le masque de sous-réseau /32, la route connectée n'est pas visible dans la table de routage ou de transfert.
Le trafic vers cette interface peut toujours fonctionner, mais une route statique serait nécessaire pour atteindre des homologues. Les utilisateurs ne peuvent pas utiliser les interfaces avec le masque de sous-réseau /32. Il n'y a aucun problème si un autre masque de sous-réseau est utilisé.

Solution : utilisez n'importe quel autre masque de sous-réseau, à l'exception du masque de sous-réseau /32.
Problème 2594802 : dans Service Composer, les utilisateurs ne peuvent pas déplacer une stratégie de sécurité au-delà du 200^e emplacement à l'aide de la boîte de dialogue Gérer la priorité.
Ce problème est observé dans NSX 6.4.3 et versions ultérieures, et il se produit uniquement lorsqu'il existe plus de 200 stratégies de sécurité. La boîte de dialogue Gérer la priorité affiche uniquement les 200 premières stratégies. Par conséquent, les utilisateurs ne peuvent pas déplacer une stratégie de sécurité au-delà de la position 200.

Solution :

identifiez la pondération de votre stratégie de sécurité afin qu'elle puisse être déplacée vers ce classement particulier. Par exemple, supposons que le classement 300 présente la pondération 1 000 et le classement 301 la pondération 1 200. Pour passer votre stratégie de sécurité à 301, fournissez la pondération 1 100 (c'est-à-dire un nombre compris entre 1 200 et 1 100).

Suivez la procédure :
1. Ouvrez la boîte de dialogue Modifier une stratégie de sécurité.
2. Modifiez la pondération de votre stratégie de sécurité sur 1 100 pour qu'elle puisse être déplacée vers la position 301.
3. Cliquez sur Terminer.
4. Notez que la stratégie est déplacée vers la position 301.
Problème 2395158 : la section de pare-feu est grisée lorsque le rôle d'administrateur d'entreprise est attribué à un groupe Active Directory.
Le rôle d'administrateur d'entreprise est attribué à un groupe Active Directory en accédant à Utilisateurs et domaines > Utilisateurs > Utilisateur d'identité > Spécifier un groupe vCenter. Lorsque des utilisateurs appartenant à un groupe Active Directory se connectent et verrouillent une section de pare-feu, la section verrouillée est grisée pour ces utilisateurs une fois que la page est actualisée.

Solution :

au lieu d'attribuer le rôle d'administrateur d'entreprise au groupe Active Directory, attribuez ce rôle directement aux utilisateurs en accédant à Utilisateurs et domaines > Utilisateurs > Utilisateur d'identité > Spécifier un utilisateur vCenter.
Problème 2444677 : une erreur de panique du noyau se produit sur le dispositif NSX Edge lorsque des fichiers volumineux sont transférés via un VPN L2 sur des tunnels VPN IPSec.
Cette erreur se produit lorsque le MTU est défini sur 1 500 octets.

Solution :

définissez le MTU sur 1 600 octets.
Problème 2574260 : la mise à jour d'une configuration de commutateur logique existante pour activer l'utilisation de VLAN invités (balisage d'invité virtuel ou balisage VLAN 802.1q) ne produit pas le résultat attendu.
Le ports VDS associé au commutateur logique n'est pas mis à jour en conséquence.

Solution : Aucune
Problème 2562965 : lorsqu'une configuration de règle DFW est enregistrée, le bouton Enregistrer tourne pendant quelques minutes puis l'interface utilisateur génère une erreur.
Le message d'erreur suivant s'affiche dans vSphere Client :
```
Aucune instance de NSX Manager disponible. Vérifiez que l'utilisateur actuel a un rôle attribué sur NSX Manager.
```
Ce problème se produit uniquement lors de l'enregistrement de la configuration de la règle DFW. Il n'y a aucun impact sur la publication de la règle DFW.

Solution : Aucune
Problème 2595144 : dans NSX 6.4.6, l'utilisation de la mémoire de super grands dispositifs Edge dépasse 90 % lorsque le nombre d'interfaces actives est supérieur ou égal à 6.
Ce problème se produit dans NSX 6.4.6 et versions ultérieures en raison de la modification apportée à la taille du tampon d'anneau RX (4096) pour les super grands dispositifs Edge.
- NSX Edge signale une utilisation élevée de la mémoire lorsque le nombre d'interfaces est supérieur ou égal à 6.
- Sur la machine virtuelle NSX Edge, la sortie de la commande top -H affiche une utilisation normale de l'espace utilisateur.
- La sortie de la commande slabtop -o affiche un nombre d'objets supérieur à 100 000 pour skbuff_head_cache.
Solution : contactez le Support VMware pour résoudre ce problème.

Problèmes d'interopérabilité

Problème 2586381 : VMware Integrated Openstack (VIO) n'est pas compatible avec NSX 6.4.7 en raison de plusieurs problèmes de dimensionnement.
NSX 6.4.7 ne prend pas en charge l'interopérabilité avec VIO.

Solution : Aucune