Inventaire host VmWare

[neo35]

Bonjour,

J'ai éffectué l'inventaire des hôtes VmWares via l'agent FusionInventory. Tout s'es parfaitement, jusqu'à l'étape de GLPI.
J'ai injecté les fichiers ocs dans le serveur, mais le problème c'est que bien que les machines n'ont pas le même nom, glpi les considère comme identiques (même numéro de série,etc) et je souhaiterais donc savoir si il y a un moyen de contourner ce problème afin que tous mes hôtes apparaissent dans glpi.

Merci de votre aide

[ddurieux]

même numéro de série? bah blackliste ce numéro de série s'il n'est pas bon

[neo35]

Mon tuteur m'a dit que c'était normal qu'il y ai le même numéro de série. Ce qui me gêne c'est que du coup je neux pas toute les importer dans GLPI...
Je vais tout de même éssayer de blacklister le numéro de série.

Merci de ta réponse!

[neo35]

Ca fonctionne en blacklistant le numéro de série. Merci beaucoup !

[ddurieux]

Je ne vois pas en quoi c'est normal d'avoir plusieurs machines physiques avec le même numéro de série

[neo35]

Moi non plus, mais bon on fait avec ^^"

[neo35]

Bonjour, je reviens vers vous pour vous prévenir que mon tuteur de stage pense que l'agent fusioninventory remonte le numéro de série du chassis et nom de la lame.

[ddurieux]

Il me semble que c'est ce que nous donne le webservice ESX, à moins qu'il ne stocke la bonne info ailleurs dans les infos disponibles par le SDK

[neo35]

Je vais chercher pour éssayer de trouver.

Sinon, j'aurais une dernière question: Est-il possible d'inventorier également les hôtes Hyper-V?

[ddurieux]

Bah oui avec l'agent installé sur l'hote, il va te remonter les hyper-v

[neo35]

D'accord, mais je ne peux pas le faire avec une commande similaire à "fusioninventory-esx --user root --password password --host esx-server --directory /tmp"?

[neo35]

Help? ^^

[keyser75]

Bonjour, je reviens vers vous pour vous prévenir que mon tuteur de stage pense que l'agent fusioninventory remonte le numéro de série du chassis et nom de la lame.

Bonjour,

J'ai mis en place une contrainte d'unicité sur les numéros de série et je pense avoir le même problème : les hôtes ESX ont le même, probablement celui du chassis.
Nous utilisons des chassis Dell M1000e et des lames Dell PowerEdge M620/630.

J'ai regardé un peu le code de l'agent ESX.
Je pense que la fonction getBiosInfo dans Host.pm est utilisée. Elle retourne le serial que je vois dans le XML d'inventaire (<SSN>).
C'est l'élément "hardware.systeminfo->otherIdentifyingInfo->identifierValue" qui semble récupéré pour la variable $ssn pour chaque hôte (lame).

J'ai essayé de remonter les infos à la main avec les commandes powershell et notamment get-esxcli :

Code:

$esxcli = get-esxcli -VMHost <HOTE>
$esxcli.hardware.platform.get()

Mais le compte que j'utilise ne semble pas avoir tous les droits :

Code:

+ $esxcli.hardware.platform.get()
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [], NoPermission
    + FullyQualifiedErrorId : VMware.VimAutomation.ViCore.Types.V1.ErrorHandling.NoPermission

Par exemple je n'ai pas de problème avec :

Code:

$esxcli.system.version.get()

La version de Vmware remonte bien dans mon inventaire

Je vais essayer de voir avec le SDK Perl et l'api SOAP pour faire la même chose.
Parallèlement je vois si ce n'est pas un problème de droits. Je n'ai pas la main sur les esx, j'utilise le compte qu'on m'a créé.
J'ai lu aussi sur certains forums, que le constructeur ne complète pas toujours la valeur du numéro de série...

Si vous avez des news sur ce point ça m'intéresse, parce que je vais devoir entrer les serials à la main et les verrouiller et les nouvelles lames risquent d'être bloquée par ma contrainte.

[keyser75]

Je viens de trouver ce vieux cas : http://forge.fusioninventory.org/issues/2191.

Le problème est identique, nous sommes en Esx 5.1.
De ce que je comprends, le problème aurait été corrigé, mais pour Esx 4.0. Personne n'indique si ça fonctionne en 5.0+ avec les versions d'agent ultérieures.
Si quelqu'un à l'info.