VMWare, c'est bien! Avec cela, on peut tester diverses situations ou projets (comme par exemple, ReactOS ) sans forcément flinguer son système. Par contre, la maintenace de ce type de système tend à devenir assez laborieux pour peu que l'on doive gérer les mises à jour système (ne serait-ce pour conserver le support constructeur). C'est pour cela qu'on utilise les vmware-tools, ces outils bien pratiques qui permettent la gestion de l'ESX à partir d'une machine cliente. Seulement voilà ; ces outils étant très spécifiques, il est nécessaire d'installer les vmware-tools qui correspondent bien à la version de son ESX installé (si vous avez du temps et du pop-corn à portée de main, installer donc les vmware-tools d'un ESX 4.0 sur une machine géré par un ESX 5.1, c'est fendard ! ). Là où ça devient franchement folklo, c'est lors d'un déploiement automatisé. En effet : plus votre parc est grand, plus il est probable d'avoir des versions différentes d'ESX. Dans ce cas, on arrive au paradoxe de l'oeuf et de la poule : une fois la VM guest installée, pour connaitre la version des vmware-tools à installer, il faudrait connaître la version de l'ESX mais cette information n'est accessible qu'à traverser les vmware-tools... Du coup, comment faire ?
Par chance, à travers, les dizaines d'informations que nous fournis dmidecode, il y en a une qui va nous sauver :
En effet, si on regarde attentivement le champ Address de la commande dmidecode -t 0 sur une VM, on s'aperçoit que l'adresse est toujours identique, en fonction de la version de l'ESX hôte ! C'est donc par cette information qu'on va pouvoir passer. On obtient donc le script ci-dessous (j'ai testé différentes VM sur différents ESX pour obtenir les valeurs indiquées) :

#!/bin/sh

case $( dmidecode | grep -A4 "BIOS Information" | grep Address | awk '{ print $2 }' ) in
  "0xE8480" ) echo "ESX 2.5" ;;
  "0xE7C70" ) echo "ESX 3.0" ;;
  "0xE7910" ) echo "ESX 3.5" ;;
  "0xEA550" ) echo "ESX 4U1" ;;
  "0xEA2E0" ) echo "ESX 4.1" ;;
  "0xE72C0" ) echo "ESX 5"   ;;
  "0xEA0C0" ) echo "ESX 5.1" ;;
  *) echo "Unknown version: "; dmidecode | grep -A4 "BIOS Information";;
esac 

Et voilà Bon, bien sûr , même si c'est fonctionnel, ce n'est pas le top d'utiliser ce type de script durant la post-install (sans parler que c'est difficile de le réutiliser). C'est pour cela que je fournis également la version facter afin de pouvoir l'utiliser au sein d'une installation automatisé avec Puppet et son copain Foreman

# /usr/lib/ruby/site_ruby/1.8/facter/esxversion.rb
Facter.add("esxversion") do
  confine :kernel => :Linux
  setcode do
    case Facter::Util::Resolution.exec('dmidecode | grep -A4 "BIOS Information" | grep Address | cut -d x -f 2')
    when "E8480"
      "ESX 2.5"
    when "E7C70"
      "ESX 3.0"
    when "E7910"
      "ESX 3.5"
    when "EA550"
      "ESX 4U1"
    when "EA2E0"
      "ESX 4.1"
    when "E72C0"
      "ESX 5"
    when "EA0C0"
      "ESX 5.1"
    else
      "Unknown"
    end
  end
end

Une fois copié dans le répertoire qui va bien (ou déployé par puppet, en placant le fact ci-dessus dans le répertoire facter du projet), le script devrait renvoyer la version correcte de l'ESX hôte s'il est appelé par un : facter esxversion