NSX : Ajout du Management Pack NSX dans vRops

 

Dans la continuité de nos articles dédiés à NSX dans la :

Catégorie NSX

 

 

Lançons nous dans la mise en place du management pack NSX sous vROPS, celui ci vous permettra de faire remonter les informations de performannce,troubleshoot et dedugs de NSX à vRops

 

Download 

https://solutionexchange.vmware.com/

Chercher le :  » Management Pack for NSX for vSphere X.X « 

Prendre la dernière version :

Aujourd’hui « Mai 2016 »

Management Pack for NSX for vSphere 3.0.x

2016-05-10_10h44_40

 

 

Vous aurez un fichier : « vmware-xxxxxxNSXxxxxxxxxxxx.pak »

 

 

 

Installation du management PACK NSX 

Se connecter à votre usine à gaz vROPS

Faites :

  1. Solutions
  2. le + vert
  3. Parcourir (sélectionner le fichier PAK téléchargé précédemment)
  4. Télécharger

2016-05-10_10h48_59

 

 

2016-05-10_10h54_14

 

Installation terminée

2016-05-10_11h00_12

 

 

Configuration du Management Pack

Se mettre sur le management Pack fraîchement installé, cliquer sur les petites roues

2016-05-10_11h02_03

 

 

Inscrire les infos de votre vCenter & NSX Manager

2016-05-10_11h04_06

 

2016-05-10_11h45_07

 

 

Tester la connexion :

2016-05-10_11h46_18

 

Valider le certificat 

2016-05-10_11h45_52

 

2016-05-10_11h46_05

 

 

2016-05-10_11h49_34

 

 

On peut voir notre vRops en cours de collecte 

2016-05-10_11h52_02

 

 

Tour rapide 

Pour voir les objets NSX sous vRops

2016-05-10_14h15_57

 

 

Et vous voila dans la belle usine vRops avec une vue NSX.

Vous aurez différente vue, pour explorer :

  • La topologie réseau sous forme graphique
  • Des badges de santés de votre infrastructure
  • Informations de performances de vos éléments NSX (edge, LDR, …)
  • Performance réseau
  • Recommandations

 

2016-05-10_14h16_44

 

 

A vous de décortiquer tout ça …

 

 

 

 

 

 

Share

NSX : Troubleshoot erreur Installation VIBs vTEP – XXX eam.agent.enable.label not found XXX

 

 

Lors de la préparation des ESXi sous NSX manager dans un clusteur, 1 ESXi ne veut pas passer la phase d’installation sans erreur.

 

2016-04-28_21h25_51

 

 

 

Impossible de comprendre la source de l’erreur depuis le client WEB

Pour avoir plus d’informations obligé de faire un tour sur le client lourd, et la nous pouvons observer l’erreur : 

 

XXX eam.agent.enable.label not found XXX

2016-04-28_21h25_14

 

 

En gros rien de méchant, c’était une erreur sur les serveurs DNS configurés dans l’ESXi. Car l’hyperviseur va chercher à installer les VIBs nécessaires en se connectant au serveur via le nom de domaine

On corrige, on relance l’installation et sur le client lourd on voit que c’est un peu plus jolie.

2016-04-28_21h27_39

 

 

2016-04-28_21h27_57

 

 

 

 

 

 

 

 

 

Share

NSX : Troubleshoot bloqué sur Désinstallation « VIBs » (Uninstalling stuck in progress)

 

 

Apres pas mal de bricolage, j’ai eu besoin de désinstaller les VIBs de mes ESXi.

Apres une pause déjeuné je retrouve mes ESXi toujours sur la désinstallation en cours. Je reboot les ESXi et toujours bloqué sur le même statut.

2016-04-28_16h25_57

 

 

Déconnecter vos ESXi du vCenter et supprimer le cluster, oui oui carrément.

 

2016-04-28_21h08_16

 

 

 

Recréer un cluster puis ajouter de nouveau vos ESXi, et lancer un dernier reboot

De retour sur l’interface NSX

Et voila vous pouvez procéder à la réinstallation si besoin

 

2016-04-28_21h15_30

 

 

 

 

 

 

Share

NSX : Troubleshoot / Test de connectivité vXLAN entre 2 ESXi / vTEP / NSX Controller

 

 

Lors de l’implémentation d’une infrastructure NSX avec du vXLAN, il est important une fois avoir configuré vos ESXi / vTEP et NSX Controller de faire un test de connectivité avant d’aller plus loin. Pour éviter de deployer EDGE et LDR puis tout casser et je sais de quoi je parle   ;-p

 

 

Avant tout contrôler l’état de votre cluster

 

2016-04-29_15h54_52

 

 

 

Il est possible de réaliser un PING vXLAN entre 2 ESXi / vTEP, en envoyant des trames avec des tailles de paquets modifiés.

lister vos 2 VMkernel / vTEP de vos ESXi à tester (IP attribué via l’IP Pool)

 

2016-04-29_15h17_38

 

 

Connectez vous en SSH à l’un des 2 ESXi 

via la commande :

 

Les paramètres sont :

Ping  ++netstack=vxlan : PING en utilisant le STACK vXLAN de l’ESXi

-d   :   Ne pas fragmenter le paquet

-s   :    Taille du pacquet entre 1572 – 1600

-I    :     Depuis quel interface envoyer le PING

X.X.X.X   :     IP de destination

 

Et tester aussi depuis l’autre ESXi

 

2016-04-29_13h00_11

 

 

 

Si il n’y a pas de réponse au PING, il est fort probable que le MTU d’un de vos switch physique ne soit pas en 1600 ou un soucis de vLAN

 

 

Via le WEBUI

 

Sous Logical / Commutateurs logiques :

2016-04-29_15h39_19

 

Double cliquer sur votre « logical Wire »

Lancer un test entre 2 ESXi, un peu de la même manière que sous SSH mais en graphique.

2016-04-29_15h42_47

 

Si vous avez une erreur et que vous étes sûre de votre MTU, allez jeter un œil sur votre ou vos Controller NSX

 

 

 

NSX Controller

 

Dans notre LAB, nous en avons déployé qu’un seul NSX Controller.

 

se connecter dessus en SSH

Exécuter la commande 

show control-cluster status

 

2016-04-29_15h50_32

 

 

D’autre commandes sont a essayer :

show control-cluster roles

2016-04-29_15h47_03

 

show control-cluster connections

show control-cluster core stats

show network interface

 

 

En gros faite des Ping de tous les cotés, verifier vos vLAN, Gateway, promiscuous mode  de vos vSwtichs (LAB FULL virtuel), gateway physique,…

 

 

 

 

Share

NSX : Ajout NSX Manager Erreur : Initialization of STS clients failed …

 

Petite erreur, que je pense que plus d’un, ont du rencontrer enfin j’espère pour moi.

Ayant déjà dans le passé  mis en place un NSX manager sous un environnement vSphere 5.5, c’est naturellement que lors de l’interconnexion du NSX manager avec le SSO vCenter j’entre le port 7444

 

Et sans comprendre je me retrouve avec cette erreur.

error :

NSX Management Service operation failed. (Initialization of STS Clients failed. Root cause. The SSL certificate of STS service cannot be verified)

 

2016-04-12_17h27_30

 

 

On google un peu et je trouve que d’autre nœuds nœuds comme moi on fait cette erreur sur les communities VMware.

Bah tout simplement que le port d’écoute SSO sur vCenter 6, est 443 et non 7444 (sous vSphere 5.x)

 

On edit :

2016-04-12_17h29_07

 

 

Et la cela marche bien mieux avec le port 443

2016-04-12_17h29_45

 

2016-04-12_17h29_53

 

 

Si tu es la c’est que tu es surement un ami nœud nœud toi aussi  ;-p

 

 

 

 

 

Share