Aujourd'hui un pro­blème inco­hé­rent et presque incompréhensible:

Sur un ser­veur, je n'arrivais pas à me connec­ter aux sites de Microsoft:

• tous les autres sites marches dans IE
• la réso­lu­tion NSLOOKUP fonctionne
• le ping sur sur le nom DNS ne résout pas
• le ping de l'adresse IP ne répond pas
• le tra­cert de l'adresse IP n'aboutit pas

Pas mal de temps perdu à cher­cher une expli­ca­tion et une réso­lu­tion jusqu'à ce que je tombe sur cette page, le pro­blème semble lié à un malware.

Voici la résolution:

• arrê­ter le ser­vice "DNS client"
• mettre le ser­vice "Event Log" en auto­ma­tique et démarré
• mettre le ser­vice "Back­ground Intel­li­gent Trans­fert" en manuel et démarré
• mettre le ser­vice "Auto­ma­tic Updates" ou "Mise à jour auto­ma­tiques" en auto­ma­tique et démarré
• lan­cer un coup de Win­dows Update et ins­tal­ler les correctifs
• après un redé­mar­rage tous doit être revenu à la normale.

Pour défaut les ESX ont un Ser­vice Console de 272 Mo (jusqu'à 800 Mo), quand la mémoire du Ser­vice Console com­mence à man­quer les mes­sages "Memory Che­cker" appa­raissent dans les fichiers hostd­log (dans /var/log/vmware).

Ce manque de mémoire peuvent venir d'un pro­duit tiers ins­tal­ler dans le Ser­vice Console ou un grand nombre de res­source à gérer (host/vm). Ce pro­blème se carac­té­rise visuel­le­ment par des décon­nec­tions inter­mit­tentes du vCen­ter ou un arret du ser­vice Hostd sur un ESX.

Comme il est dit dans la KB 1002713 de VMware, il faut aug­men­ter la mémoire du Ser­vice Console (800 Mo étant la valeur max). Cette opé­ra­tion néces­site d'avoir au préa­lable bien dimen­sion­ner les par­ti­tions et sur­tout un reboot pour que la modi­fi­ca­tion soit prise en compte.

[2009-09-18 09:43:24.241 'Memory che­cker' 78818224 war­ning] Cur­rent value 164768 exceeds soft limit 122880.

En revanche, ce que ne pré­cise pas la KB, c'est qu'en plus il faut modi­fier les seuils d'alerte. Sinon passé le pre­mier seuil on a tou­jours des war­nings dans le fichier hostd.log et passé le second les ser­vices hostd & vpxa s'arrêtent.

Pour cela éditer le fichier /etc/vmware/hostd/config.xml et ajou­ter les lignes sui­vantes en fonc­tion des nou­veau seuils que vous vou­lez (ici un exemple de seuil pour un Ser­vice Console à 512 Mo) dans la par­tie <config>:

<hostdWarnMemInMB>375</hostdWarnMemInMB>

<hostdStopMemInMB>465</hostdStopMemInMB>

Les VMs en Debian sont offi­ciel­le­ment sup­por­tés depuis vSphere, mais la mise à jour des VMwa­re­Tools ne reste pas si simple que dans une Red­Hat. Il faut d'abord sup­pri­mer les pré­cé­dents VMwa­re­Tools et les modules char­gées avant de lan­cer l'installation.

Voici les com­mandes pour la mise à jour des VMwa­re­Tools (ESX4.0 update1) d'une Debian 5 32bits:

dpkg --purge vmwaretools
rm -rf /etc/vmware-tools/
rm -f /lib/modules/2.6.26-2-686/misc/vm*
reboot

Après le redé­mar­rage de la VM, lan­cer l'installation des VMware Tools

mount /media/cdrom0
cp /media/cdrom0/VMwareTools-4.0.0-208167.tar.gz .
tar -zxvf VMwareTools-4.0.0-208167.tar.gz
cd vmware-tools-distrib
./vmware-install.pl
vmware-config-tools.pl

Il ne reste plus qu'à répondre aux ques­tions (nor­ma­le­ment les valeurs par défaut) et redé­mar­rer la VM pour que le sta­tus des VMware Tools des VMs Debian passe de "Out of Date" à "OK".

Il m'est déjà arri­ver plu­sieurs fois que le CPU0 (celui du Ser­vice Console) d'un ESX sature à 100%.

En regarde plus en détail avec top, on constate que c'est le pro­ces­sus ftPerl qui sature le Ser­vice Console.

Ce pro­blème existe sur des ESX en 3.0 et en 3.5 jusqu'à l'update 4 (peut être résolu depuis), il est lié un pro­blème dans la confi­gu­ra­tion du Cluster.

Réso­lu­tion:

• le plus simple mais seule­ment tem­po­raire, faire un "Recon­fi­gure HA" sur cette ESX. Réso­lu­tion tem­po­raire car le pro­blème revien­dra plus tard.
• la solu­tion per­ma­nente est de créer un nou­veau et de migrer les VMs et les ESX dans ce nou­veau Clus­ter et sup­pri­mer l'ancien. Une KB existe chez VMware expli­quant la recréa­tion de Cluster.

Réfé­rence:

• http://professionalvmware.com/2009/05/ftperl-hates-me/

En essayant de sau­ve­gar­der juste le disque sys­tème (scsi0:0) d'une VM avec Veeam Backup 4, j'ai eu un mes­sage d'erreur surprenant:

File <uns­pe­ci­fied file­name> is lar­ger than the maxi­mum size sup­por­ted by datas­tore '<uns­pe­ci­fied datastore>

Le disque sys­tème ne fait que 15 Go dans un VMFS de 500 Go (avec plus de 300 Go de libre). En plus du disque sys­tème j'ai un disque RDM (vir­tual) de 2 To.

Je pen­sais que le pro­blème venait de la par­tie sélec­tion de disque dans le Job de sau­ve­garde. Mais le pro­blème est ailleurs, en effet un simple Snap­shot sur la VM pro­duit la même erreur.  Ce pro­blème affecte les Snap­shots et donc poten­tiel­le­ment tous les pro­duits de sauvegarde.

L'explication:

vSphere a changé la manière dont sont gérer les Snap­shots (et notam­ment les pré-requis). Le block-size du volume de des­ti­na­tion du Snap­shot est com­paré avec la taille de disques de la VM. Dans mon cas, le block-size du VMFS de des­ti­na­tion du Snap­shot est de 2 Mo soit une taille maxi­mum de 512 Go alors que mon RDM fait 2 To.

Cf. la KB 1012384 de VMware

Réso­lu­tion:

• Soit mettre le disque RDM en mode Indepent, mais il ne pourra pas être sauvegardé.
• Soit dépla­cer (avec SVmo­tion) toutes les VMs de ce VMFS, le sup­pri­mer, le recréer avec un block-size supé­rieur, enfin faire reve­nir toutes les VMs sur le VMFS.