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>

Fin février IBM a sorti un plu­gin gra­tuit pour vCen­ter 4, ce plu­gin per­met de gérer les baies DS3000/4000/5000 tout comme dans DS Sto­rage Mana­ger direc­te­ment dans vCenter.

Pour l'instant seul les baies FC sont sup­por­tées, la ver­sion sup­por­tant les atta­che­ments iSCSI et SAS sor­tira 2nd semestre 2010.

Ce plu­gin per­met de:

• créer les arrays et les volumes
• défi­nir les hosts et les mappages
• avoir un map­page entre les volumes et les datastores
• défi­nir des permissions

Quelques cap­tures pour illustrer:

A noter qu’il faut modi­fier le Jetty Port en 8444 (car le 8443 est le port par défaut de vCen­ter Web Ser­vices), sinon le reste de l’installation et de la confi­ga­tion est comme dans la doc :

• Ins­tall du plu­gin sur le vCen­ter (Jetty port 8444 + enre­gis­tre­ment des IP des baies dans ArrayHosts.txt)
• Redé­mar­rage du vCenter
• Ins­tal­la­tion des certificats
• Créa­tion du rôles Sto­rage Admi­nis­tra­tor dans vSphere Client et asso­cia­tion aux uti­li­sa­teurs (pas aux groupes)

Le lien de télé­char­ge­ment et le Manuel uti­li­sa­teur.

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.

Micro­soft pro­pose un Lab en ligne pour tes­ter l'implémentation de Xen­Desk­top 4 sur Hyper-V R2.

Il est dis­po­nible à l'adresse: https://cmg.vlabcenter.com/default.aspx?moduleid=281742e3-2613-42da-bd58-2c3578f039b4

Le Lab dure 1h30, ce qui est trop court pour s'amuser mais ca per­met de voir la base de l'implémentation.

Voici le contenu du lab:

• Mettre en oeuvre l'AD pour Xen­Desk­top (config DHCP pour le PXE et créer une OU)
• Créer une ferme de Bureau Vir­tuel sur le DDC
• Fina­li­ser la confi­gu­ra­tion du PVS avec l'assistant
• Créer et for­ma­ter un vDisk
• Ins­tal­ler Xen­Con­vert et l'agent Xen­Desk­top dans une VM de référence
• Cap­tu­rer l'image de la VM de référence
• Créer un tem­plate de bureau vir­tuel et pro­vi­sion­ner plu­sieurs bureau à par­tir du template
• Confi­gu­rer les pro­prié­tées du Pool de bureau virtuel
• Se connec­ter à un bureau virtuel

Le manuel du Lab est dispo en ver­sion PDF.

Bien­ve­nue sur le Blog VMnerds : consa­cré à la virtualisation.

C'est le pre­mier post et ce n'est qu'un début.