Hi ​@LEBRETON, did you enable Automatic analysis in Define analysis method and update policy section of job settings?

In the job result listing you can access to raw data and compare with your exclusion mappers.

Regards

Bonjour,

Oui j’ai bien mis Automatic analysis.

est-ce que ce sont les logs du type : DEBUG - -autodiscovery] Event: :HOSTDISCOVERYJOBLISTENER] …

Si oui le retour est incomplet, mon VCenter gère environ 6000 hosts

Merci

did you try to modify timeout in your job parameters?

Le timeout du job est de 1200s et quand il s’exécute j’ai une durée affichée de 1mn 40s

J’ai découvert sur mon VSphre que une des machines découverte au premier passage et désactivée au second avait été clonée deux fois et quelles avaient toutes le même UUID :

Pourtant j’ai un mapper d’exclusion pour les VM PoweredOff et notRunnig.

A la première passe j’ai bien ma machine 113501L420app qui est enregistrée dans Centreon. Mais lors de la seconde passe elle est mise en disable.

J’ai aussi dans Policy cocher “ Disable hosts already added to configuration if the mapping rule excludes them ”.

Si je décoche cette option, que j’active à nouveau le HOST et relance le Job, le HOST n’est pas désactivé.

J’avoue ne pas bien comprendre le fonctionnement de cette option avec le mapper, puisque le mapper exclue les VM poweredOf et not Running.

Merci

Le problème vient surement de l’unicité des machines pour la découverte.

Si les 3 serveurs ont le même identifiant, quand l’analyse automatique du résultat va boucler sur les hôtes découvert, il va passer le premier en actif puis le désactiver en passant sur le server 113501L420app_Impaire qui lui est poweroff

Je pensais que les mapper inclusion/exclusion permettait d’avoir une liste réduite de host et que la policy s’appliquait apres pour les autres mapper.

Le problème vient de l’unicité des hôtes découvert, j’ai plus le critère exacte en tête et c’est dans le plugin associé, mais si jamais c’est l’UUID alors ca va poser des problèmes.

J’ai moi même été surpris que sur VMware des VM pouvait avoir le même UUID.

Mon collègue spécialiste VMware m’a précisé que lors d’un clone via l’interface, L’UUID changeait.

Par contre lorsqu’on déplace les fichiers de la VM vers un autre datastore, on peut si on veut préciser que l’UUID soit changé, mais ce n’est pas obligatoire. Ici l’admin a déplacé les fichiers vers un autre datastore sans changer l’UUID.

A ce moment là, il faudrait que ce soit le plugin de discovery VMware qui calcul l’UUID et non reprendre celui fourni par VMware. Comme pour le plugin de discovery Tower que j’utilise aussi.

Tu peux créer une idée pour pouvoir définir/surcharger la manière de calculer l’unicité des ressources dans les jobs de découverte ?

Je pense plutôt que nous sommes face à un bug : Pour VMware l’UUID peut ne pas être unique, mais pour Centreon c’est obligatoire, donc je pense que c’est au plugin discovery VMware de calculer son propre UUID.

C’est ce que je disais pour le discovery Tower dont les infos remontées ne fournissent pas d’UUID : il est généré par le plugin je pense.

La problématique c’est que si nous changeons la manière de calculer l’unicité, tous les utilisateurs vont avoir des problèmes avec leur tâche de découverte dès la mise à jour du plugin.

L’idée sera de dire que si la règle d’unicité provenant du plugin n’est pas celle souhaité, alors l’utilisateur peut en proposer une autre.

Cdt,

Cela veut dire que je suis le seul à avoir rencontré ce problème sur VMware.

Sachant qu’en décochant : “ Disable hosts already added to configuration if the mapping rule excludes them ” le resultat est correct avec les mappers que j’ai défini.