Welcome to OCS Inventory NG community support, where you can ask questions and receive answers from other members of the community.

Please ask questions only in English or French.

Release 2.4.1 available

The official documentation can be found on http://wiki.ocsinventory-ng.org. Read it before asking your question.

Remonté des serveurs ESXi

Existe-t-il un moyen d'inventorié les hôtes VMware ESXi dans OCS.

L'agent fusion inventory dispose d'un outil capable de le faire. J'ai l'impression qu'il s'appuie sur SNMP pour le faire.

Quelqu'un a-t-il des infos ?
asked in SNMP by (1.1k points)

5 Answers

0 votes
Il y a aussi la remontée d'information en snmp sur Esxi dans l'agent linux.
answered by (2.1k points)
0 votes
Oui je pense installer l'agent Unix sur mon serveur OCS, mais je n'ai trouvé aucune info dans la doc à ce sujet.

dwizz, peux tu m'en dire plus.

Utilises tu cela pour inventorier des serveurs ESXi ?
answered by (1.1k points)
0 votes
Oui cela remonte un certain nombre d'information. Par contre je ne sais pas si ces informations correspondent à ton besoin.

Attention, pour remonter les informations et en fonction de la version d'Esxi, les actions de parametrage snmp sur ton Esx ne se font pas de la même maniere (regarde donc bien la doc Esx)

Regarde sur la demo ce que tu peux recuperer comme informations
answered by (2.1k points)
+1 vote

Bonjour,

Personnellement j'utilise le script Perl de Fusion-Inventory pour inventorier mes hôtes ESXi dans OCS Inventory.

Le script de Fusion-Inventory n'utilise pas SNMP mais l'API SOAP de VmWare, ce qui permet d'inventorier à distance les hôtes ESXi (sans rien installer sur l'ESXi lui-même donc; ce qui a l'avantage de faire plaisir à mon service Système ^^).

OK, je sais que Fusion-Inventory est un concurrent d'OCS mais ce script est vraiment efficace !

 

L'astuce consiste donc à modifier le fichier .ocs généré par le script de Fusion-Inventory pour que les balises et leurs données correspondent à la structure attendue par le serveur OCS. En effet, les 2 projets ayant évolué séparément, la structure générée est légèrement différente.

 

En résumé, pour "inventorier un ESX" mes étapes sont donc :

1 - Générer les .OCS à partir du script Perl "Fusion" légèrement modifié (lancé à distance sur les différents serveurs ESXi). Je suis partie du script de FusionInventory version 2.3.10.1

2 - Modifier les .OCS générés par le plugin "Fusion" afin qu'ils aient le format attendu par OCS (à l'aide d'un script perl "maison" Fusion2OCS.pl)

3 - Injecter les .OCS modifiés dans OCS à l'aide du script perl "ocsinventory-injector.pl" fourni par OCS

 

Le détail dans les posts en dessous.

J'espère que ça pourra aider qqun d'autre.

Salut,

Sylvie

answered by (340 points)

Modifications apportées au plugin "Fusion"

1 - Ajout de la balise "CHECKSUM" au fichier .OCS généré

Il faut modifier la sub createInventory dans le fichier perl\agent\FusionInventory\Agent\Task\ESX.pm

et insérer la commande "$inventory->computeChecksum();" juste avant le "return $inventory;"

sub createInventory {
...
--> insérer cette ligne
    $inventory->computeChecksum();
<--

    return $inventory;

}

Le checksum n'est pas recalculé si la seule différence depuis le dernier inventaire concerne la les VM détectées sur l'hôte ESXi (bug dans le script Fusion ?).

Il faut modifier la sub computeChecksum dans le fichier perl\agent\FusionInventory\Agent\Inventory.pm
et ajouter "VIRTUALMACHINES => 131072," juste après "SOFTWARES   => 65536,"

sub computeChecksum {
...
    SOFTWARES   => 65536,
--> insérer cette ligne
    VIRTUALMACHINES => 131072,
<--
...
}

 

2 - Ajout des données CPU dans la balise "HARDWARE" en plus de la balise "CPU" (pour remontée jusqu'à GLPI)

Il faut modifier la sub createInventory dans le fichier perl\agent\FusionInventory\Agent\Task\ESX.pm
et insérer la commande "$inventory->computeLegacyValues();" juste avant le "$inventory->computeChecksum();"

sub createInventory {
...
--> insérer cette ligne
    $inventory->computeLegacyValues();
<--
    $inventory->computeChecksum();

    return $inventory;

}

 

3 - Calcul d'un sous-réseau pour les cartes réseau actives (pour tri par réseau, IPDiscover,...)

Il faut modifier le fichier perl\agent\FusionInventory\Agent\Task\ESX.pm :

a - Insérer la commande "use Socket;" au niveau des dépendances en début de fichier :

...
use warnings;
--> insérer cette ligne
use Socket;
<--
use base 'FusionInventory::Agent::Task';
...

b – Dans la sub createInventory au niveau de la boucle sur la cartes réseau :

sub createInventory {
...

    foreach my $network ($host->getNetworks()) {
        $ipaddr{ $network->{IPADDRESS} } = 1 if $network->{IPADDRESS};
--> insérer ces 3 lignes
        if (($network->{IPADDRESS}) && ($network->{IPMASK}) && (!$network->{IPSUBNET})) {
            $network->{IPSUBNET} = inet_ntoa(inet_aton($network->{IPADDRESS}) & inet_aton($network->{IPMASK}));
        }

<--
        $inventory->addEntry(section => 'NETWORKS', entry => $network);
    }
...
}

4 - Remontée d'un "type BIOS" pour fonctionnement correct des dictionnaires GLPI à l'autre bout (facultatif si vous n'avez pas absolument besoin d'un type de matériel)

L'objectif est de remonter le type de matériel.
Sur un Linux, on va par exemple trouver ce type d’information dans /usr/sbin/smbios

4     64   SMB_TYPE_CHASSIS (system enclosure or chassis)
[…]
  Chassis Type: 0x17 (rack mount chassis)


Après vérification des propriétés disponibles via l’API VmWare utilisée par FusionInventory (https://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/index-properties.html), cette donnée ne semble pas disponible.

Décision arbitraire de remonter "Server" en dur pour ne pas avoir de valeur nulle.

Il faut modifier la sub createInventory dans le fichier perl\agent\FusionInventory\Agent\Task\ESX.pm
et insérer la commande "$inventory->setBios( { TYPE => 'Server' } );" juste après le "$inventory->setBios( $host->getBiosInfo() );"

...
    $inventory->setBios( $host->getBiosInfo() );
--> insérer cette ligne
    $inventory->setBios( { TYPE => 'Server' } );
<--
...

 

5 - Modification de la génération "factice" du device_id afin que celui-ci soit toujours identique au lieu de correspondre à l' "up-time" du serveur.

Il faut modifier la sub createFakeDeviceid dans dans le fichier perl\agent\FusionInventory\Agent\Task\ESX.pm
On force une date fixe (on se moque de la valeur du champ tant qu’elle n’évolue pas).
Nous utilisons déjà cette méthode pour l’inventaire de nos clients légers.

sub createFakeDeviceid {
    my ( $self, $host ) = @_;

    my $hostname = $host->getHostname();
    my $deviceid = $hostname . '-2014-01-01-00-00-00';
    
    #my $bootTime = $host->getBootTime();
    #my ( $year, $month, $day, $hour, $min, $sec );
    #if ( $bootTime =~
    #    /(\d{4})-(\d{1,2})-(\d{1,2})T(\d{1,2}):(\d{1,2}):(\d{1,2})/ )
    #{
    #    $year  = $1;
    #    $month = $2;
    #    $day   = $3;
    #    $hour  = $4;
    #    $min   = $5;
    #    $sec   = $6;
    #}
    #else {
    #    my $ty;
    #    my $tm;
    #    ( $ty, $tm, $day, $hour, $min, $sec ) =
    #      ( localtime(time) )[ 5, 4, 3, 2, 1, 0 ];
    #    $year  = $ty + 1900;
   #    $month = $tm + 1;
    #}
    #my $deviceid = sprintf "%s-%02d-%02d-%02d-%02d-%02d-%02d",
    #  $hostname, $year, $month, $day, $hour, $min, $sec;

    return $deviceid;
}


6 - Modification de la récupération du serial de l'ESX

Actuellement, sur certains blades, le script récupère le serial du chassis et non pas le celui de la lame.

Du coup, on se retrouve avec plein de doublons dans l'onglet de suivi des doublons par serial.

Après investigations, il semble que ce souci soit spécifique aux châssis Dell et HP ProLiant BL460c G1 / G6. (Je n'ai pas ce souci sur un châssis HP ProLiant BL460c Gen8 par exemple).

A priori, il faudrait déployer le "Proliant Pack" sur les Proliant et l'équivalent sur les châssis Dell. Mon service Système a décidé de ne pas le faire... je ne peux donc pas confirmer ce "diagnostique" ;-)

Lancement du script Fusion2OCS.pl de modification des .OCS :

PI, au niveau des dépendances, ce perl a besoin de perl(File::Basename)

On lance le script par :

./Fusion2OCS.pl <fichier.ocs>

Le script en lui-même :

#!/usr/bin/perl -pi
# Transforme un .ocs au format FusionInventory dans un format lisible par un serveur OCS :
# les noms de champs sont légèrement différents
# et il faut faire un calcul pour le nombre de coeurs logiques

# Testé avec un fichier généré par l'agent FusionInventory 2.3.10.1 et vers un serveur OCS 2.1.2

# Version 1.0.0 - 23/09/2014 - Sylvie : Première version

use strict;
use warnings;
use File::Basename;

my $version="1.0.0";

# Declaration et initialisation variables
my $nomscript=basename($0);
my $nbcores=0;
my $nbthreads=0;
my $nblogicalcpus;

# Change la version de l'agent utilise pour generer le fichier en ajoutant un commentaire
s/(<VERSIONCLIENT>.*)(<\/VERSIONCLIENT>)/$1_modif_${nomscript}_${version}$2/g;

# Bloc <CPUS>
if (/<CPUS>/) { $_ .= <> while !/<\/CPUS>/;
  # Ajoute un "S" au champ CORE
  s/CORE>/CORES>/g;
  # Change le champ "NAME" en "TYPE"
  s/NAME>/TYPE>/g;
  # Si champ "CORES" trouve, stocke le nb de coeurs
  if (/<CORES>(.*)<\/CORES>/) {
    $nbcores=$1;
  }
  # Si champ "THREAD" trouve, stocke le nb de threads
  if (/<THREAD>(.*)<\/THREAD>/) {
    $nbthreads=$1;
    # Si le nb de coeurs est inconnu change simplement le champ "THREAD" en "LOGICAL_CPUS"
    if ($nbcores == 0) {
      s/THREAD>/LOGICAL_CPUS>/g;
    # Si le nb de coeurs est connu change le champ "THREAD" en "LOGICAL_CPUS" et remplace le chiffre par <nb coeurs> x <nb threads>
    } else {
      $nblogicalcpus=$nbcores*$nbthreads;
      #print "Nb logicalcpus est $nblogicalcpus\n";
      s/<THREAD>.*<\/THREAD>/<LOGICAL_CPUS>$nblogicalcpus<\/LOGICAL_CPUS>/g;
    }
  }
}

# Bloc <DRIVES>
if (/<DRIVES>/) { $_ .= <> while !/<\/DRIVES>/;
  # Change le champ "TYPE" en "VOLUMN"
  s/TYPE>/VOLUMN>/g;
}

# Bloc <HARDWARE>
if (/<HARDWARE>/) { $_ .= <> while !/<\/HARDWARE>/;
  # Change le champ "ARCHNAME" en "ARCH"
  s/ARCHNAME>/ARCH>/g;
}

# Bloc <NETWORKS>
if (/<NETWORKS>/) { $_ .= <> while !/<\/NETWORKS>/;
  # Change le champ "MTU" en "SPEED" mais en precisant qu'il s'agit du MTU avec les mots "MTU:"
  s/<MTU>(.*)<\/MTU>/<SPEED>MTU:$1<\/SPEED>/g;
}

# Bloc <VIRTUALMACHINES>
if (/<VIRTUALMACHINES>/) { $_ .= <> while !/<\/VIRTUALMACHINES>/;
  # Change le champ "VMID" en "SUBSYSTEM"
  s/VMID>/SUBSYSTEM>/g;
}

Lancement du script ocsinventory-injector.pl d'injection des fichiers .OCS :

PI, au niveau des dépendances, ce perl a besoin de libxml-simple-perl

Au niveau des paramètres, on le lance par :

./ocsinventory-injector.pl -d=<répertoire où sont stockés les .ocs> -v -r

-v : verbose
-r : supprime les .ocs une fois injectés

0 votes
Bonjour

Merci Sylvie pour ce partage d'informations.

Cordialement

Frank
answered by (59.7k points)
 
Powered by Question2Answer
...