Résolvez les problèmes liés aux profils d'hôte et aux TNP lorsqu'ils sont utilisés pour déployer automatiquement les clusters sans état.
| Scénario | Description |
|---|---|
| Lorsque plusieurs adaptateurs VMkernel sont activés pour prendre en charge le trafic de gestion, le trafic de vMotion et d'autres trafics sont migrés vers le même commutateur logique, les adaptateurs VMkernel sont migrés vers le commutateur logique après le redémarrage. Mais le service sur un adaptateur VMkernel est activé sur un adaptateur différent. |
Par exemple, avant la migration, vmk0 est activé pour prendre en charge le trafic de gestion et vmk1 est activé pour le trafic vMotion. Après le redémarrage de l'hôte, vmk0 prend en charge le trafic vMotion et vmk1 prend en charge le trafic de gestion. Cela entraîne une erreur non conforme après le redémarrage. Solution : aucune. Il n'y a aucun impact, car les deux adaptateurs VMkernel se trouvent sur le même commutateur logique. |
| La progression de la préparation de l'hôte est bloquée à 60 %, tandis que l'état du nœud affiche ACTIF. | Problème : lorsqu'un TNP est appliqué à un cluster, NSX-T est correctement installé sur l'hôte et l'état du nœud affiche ACTIF, mais l'interface utilisateur graphique affiche toujours une progression de 60 %. Solution : appliquez de nouveau la configuration TNP ou TN sans modification dans la configuration. L'état sera corrigé sur 100 % sur l'interface utilisateur graphique. |
| Même si la migration de VMkernel est réussie, une erreur de validation s'est produite sur le TN avant la suppression des commutateurs d'hôte. |
Problème : lorsque vous migrez l'interface de gestion vmk0 de vSwitch vers un commutateur logique, NSX-T est correctement installé sur l'hôte. La migration de VMkernel a réussi, mais l'état de TN indique une réussite partielle avec une erreur. Échec de la validation avant la suppression des commutateurs d'hôte : [erreur : aucune VMK de gestion ne disposera de PNIC après que ['vmk1'] dans ['9a bb eb c1 04 81 40 e2-bc 3f 3e aa bd 14 62 1e'] perd tous les PNIC.]; LogicalSwitch full-sync : requête réalisation de synchronisation complète LogicalSwitch ignorée. Solution : aucune. Ignorez le message d'erreur, car la migration de VMkernel a réussi. |
| La réapplication d'un TNP dans lequel le mappage réseau pour l'installation répertorie vmk0 entraîne la perte de connectivité de l'hôte. | Problème : lorsqu'une configuration TNP se compose de vmk0 dans le mappage réseau pour l'installation, les hôtes perdent la connectivité. Solution : au lieu de réappliquer le TNP, redémarrez l'hôte avec les configurations nécessaires dans TNP. |
| Impossible d'appliquer le profil d'hôte, car la stratégie de mot de passe utilisateur MUX et le mot de passe n'ont pas été réinitialisés. | Problème : survient uniquement sur les hôtes exécutant des versions antérieures à vSphere 6.7 U3. La correction de l'hôte et l'application du profil d'hôte sur les hôtes peuvent échouer sauf si le mot de passe mux_user est réinitialisé. Solution : sous Stratégies et profils, modifiez le profil d'hôte afin de modifier la stratégie de mot de passe mux_user, puis réinitialisez le mot de passe mux_user. |
| Le profil d'hôte n'est pas portable. | Problème : aucune des instances de vCenter Server ne peut utiliser le profil d'hôte contenant la configuration de NSX-T. Solution : aucune. |
| Moteur de règles de déploiement automatique | Problème : le profil d'hôte ne peut pas être utilisé dans les règles de déploiement automatique pour déployer de nouveaux clusters. Si de nouveaux clusters sont déployés, les hôtes sont déployés avec une mise en réseau de base et restent en mode de maintenance. Solution : préparez chaque cluster à partir de l'interface utilisateur graphique de NSX-T. Reportez-vous à la section Appliquer TNP sur un cluster sans état. |
| Recherche des erreurs de conformité. | Problème : la correction du profil d'hôte ne parvient pas à corriger les erreurs de conformité liées à la configuration de NSX-T.
Solution : assurez-vous que la configuration de NSX-T correspond sur le profil d'hôte et TNP. Redémarrez l'hôte pour que les modifications de configuration prennent effet. L'hôte s'affiche. |
| Correction | Problème : s'il existe des erreurs de conformité spécifiques à NSX-T, la correction du profil d'hôte sur ce cluster est bloquée. Configuration incorrecte :
Solution : assurez-vous que la configuration de NSX-T correspond sur le profil d'hôte et TNP. Redémarrez l'hôte pour que les modifications de configuration prennent effet. L'hôte s'affiche. |
| Attachement | Problème : dans un cluster configuré avec NSX-T, le profil d'hôte ne peut pas être attaché au niveau de l'hôte. Solution : aucune. |
| Détachement | Problème : le détachement et l'attachement d'un nouveau profil d'hôte dans un cluster configuré avec NSX-T ne supprime pas la configuration de NSX-T. Même si le cluster est conforme à la nouvelle association du profil d'hôte, il dispose toujours de la configuration de NSX-T d'un profil précédent. Solution : aucune. |
| Mise à jour | Problème : si l'utilisateur a modifié la configuration de NSX-T dans le cluster, extrayez un nouveau profil d'hôte. Mettez à jour le profil d'hôte manuellement pour tous les paramètres qui ont été perdus. Solution : aucune. |
| Configuration du nœud de transport au niveau de l'hôte | Problème : une fois que le nœud de transport a été déployé automatiquement, il agit comme une entité individuelle. Toute mise à jour de ce nœud de transport peut ne pas correspondre au TNP. Solution : mettez à jour le cluster. Toute mise à jour d'un nœud de transport autonome ne peut pas conserver sa spécification de migration. La migration peut échouer à publier le redémarrage. |
| La configuration PeerDNS n'est pas prise en charge sur l'adaptateur VMkernel sélectionné pour la migration vers le commutateur NVDS. | Problème : si un adaptateur VMkernel sélectionné pour la migration vers NVDS est activé pour le DNS homologue, l'application du profil d'hôte échoue. Solution : modifiez le profil d'hôte extrait en désactivant le paramètre de DNS homologue sur l'adaptateur VMkernel qui doit être migré vers un commutateur NVDS. Vous pouvez également vous assurer ne pas migrer les adaptateurs VMkernel activés pour le DNS homologue vers un commutateur NVDS. |
| Adresse DHCP de l'adresse de la carte réseau VMkernel non conservée | Problème : si l'hôte de référence est avec état, tous les hôtes sans état utilisant le profil extrait de l'hôte de référence avec état ne peuvent pas conserver leur adresse MAC de gestion VMkernel dérivée du MAC démarré par PXE. Cela entraîne des problèmes d'adressage DHCP. Solution : modifiez le profil d'hôte extrait de l'hôte avec état et redéfinissez « Déterminer comment l'adresse MAC pour vmknic doit être décidée » en « Utiliser l'adresse MAC à partir de laquelle le système a été démarré par PXE ». |
| L'échec de l'application du profil d'hôte dans vCenter peut entraîner des erreurs de configuration de NSX sur l'hôte. | Problème : si l'application du profil d'hôte échoue dans vCenter, la configuration de NSX peut également échouer. Solution : dans vCenter, vérifiez que le profil d'hôte a bien été appliqué. Corrigez les erreurs et réessayez. |
| Les LAG ne sont pas pris en charge sur les hôtes ESXi sans état. | Problème : le profil de liaison montante configuré en tant que LAG dans NSX n'est pas pris en charge sur un hôte ESXi sans état géré par une instance de vCenter Server ou dans NSX. Solution : aucune. |
| Un hôte sans état ne démarre pas avec l'adresse MAC de la carte réseau PXE lorsqu'il est appliqué à un profil d'hôte extrait d'un hôte avec état. | Problème : si un hôte sans état est attaché à un profil d'hôte extrait d'un hôte avec état, l'adaptateur VMkernel (vmknic) de l'hôte sans état ne démarre pas avec l'adresse MAC de la carte réseau PXE de l'hôte, car un hôte avec état ne démarre pas en tant que système compatible PXE. Solution : lorsque vous configurez le déploiement d'hôtes sans état, assurez-vous que le profil d'hôte extrait provient d'un hôte qui démarre en tant que système compatible PXE. |
