La gamme des packages Essen­tials n'a rien de nou­veau et la ver­sion vSphere Essen­tials est en ce moment très attrac­tif car il y a une promo de -50% jusqu'au 15 juin 2010.  Soit 3 ser­veurs ESX et 1 vCen­ter fon­da­tion avec 1 an de sub­scrip­tion pour 405 €uros. C'est une bonne occa­sion pour les PME de gou­ter à la vir­tua­li­sa­tion et d'upgrader des ESXi gratuit.

Pour rap­pel, depuis février der­nier, il est pos­sible d'upgrader des licences Essen­tials ou Essen­tials Plus vers du Stan­dard ou Enter­prise (pour qua­si­ment le prix complet).

Par contre, je viens de décou­vrir un piège: Les ser­veurs ESX d'un Bundle Essen­tials ne peuvent être managé que par un vCen­ter Essen­tial (et celui-ci ne dis­pose pas du Linked-Mode) c'est donc pour des solu­tions Stand-Alone.

Pour ajou­ter des ESX d'un Bundle Essen­tial à un vCen­ter stan­dard, il faut parti sur des Bundles Essen­tials for Retails and Branch Office aussi nommé ROBO. Et là, le prix est presque le même mais il faut par­tir sur un mini­mum de 10 Bundles (plus trop orienté PME).

Voici un tableau réca­pi­tu­la­tif des dif­fé­rences entre les ver­sions de la gamme Essen­tials : Lire la suite...

Et oui ca arrive les Purple Screen Of Death de VMware (rare­ment heureuse).

La situa­tion c'est dans un Chas­sis Sun BL6000 avec des Lames X6250 sur les­quels sont ins­tal­lés des ESX 3.5 Update 4, sur les­quelles on a ajouté des cartes réseaux X7287A-Z. On avait un PSOD toutes les 48h même sans acti­vité par­ti­cu­lière (en Main­te­nance Mode).

Il faut pré­ci­ser que ces cartes réseaux sont ini­tia­le­ment prévu pour des Lames SPARC et même si elles sont mar­quées comme sup­porté dans le HCL de VMware en char­geant un dri­ver spé­ci­fique (sinon elles ne sont pas recon­nues), elles pro­voque ce PSOD:

Le Sup­port VMware et celui de Sun n'ont du mal à résourdre cet inci­dent alors que dans la cap­ture on voit très bien dès la 2nde ligne l'erreur "Spin count excee­ded (Net Vmm­Grou­pInfo) - pos­sible dead­lock" et plus loin un "Net_HaltResume". La KB1020105 explique les PSOD avec l'erreur 'Spin Count excee­ded" mais ne donne pas solu­tion pour le réseau. En tous cas, le pro­blème était bien lié aux cartes réseaux, le rem­pla­ce­ment par des cartes réseaux pour Lames x86 a résolu direc­te­ment le problème.

Le pro­blème est peut être résolu avec l'Update 5, je n'ai pas eu l'occasion de tes­ter depuis.

Pour faire suite aux articles sur les KB, voici un outil récem­ment sorti qui est un "must-have" pour les admi­nis­tra­teurs VMware: un plu­gin Firefox/IE/Safari pour avoir une barre d'outils du sup­port VMware.

Elle com­prend:

• un moteur de recherche dans les KBs
• un accès rapide aux com­mu­nau­tés VMTN, aux docu­men­ta­tions, aux télé­char­ge­ments et au support
• des outils pour suivre le sup­port VMware: un lec­teur RSS et Twitter
• un chat pour dia­lo­guer avec des Experts VMware et le Support
• un switch rapide entre la par­tie Infra­struc­ture et la par­tie Desktop
• la com­pa­ti­bi­lité avec Fire­fox, IE et Safari
• et divers petits outils (noti­fi­ca­teur email, lec­teur radio, météo...)

L'accès au télé­char­ge­ment: http://vmwaresupport.toolbar.fm/

Il y a aussi une vidéo expli­ca­tive de la KBTV.

J'ai récem­ment ren­con­trer une erreur sur une VM win­dows qui s'arrêtait au lieu de faire le redé­mar­rage auto­ma­tique pla­ni­fié. Bizarre seule­ment cer­taine VM avait le Pb alors qu'elle venait du même tem­plate.
En regar­dant dans les logs, on a le mes­sage suivant:

Apr 26 23:11:19.481: vcpu-0| Msg_Post: Error
Apr 26 23:11:19.481: vcpu-0| [msg.log.error.unrecoverable] VMware ESX unre­co­ve­rable error: (vcpu-0)
Apr 26 23:11:19.481: vcpu-0| Unex­pec­ted return sta­tus from VMKernel_SetupPhysMemMap(pagein, 250604 pages): Not found[msg.panic.haveLog] A log file is avai­lable in "/vmfs/volumes/.../.../vmware.log".  [msg.panic.haveCore] A core file is avai­lable in "/vmfs/volumes/.../.../vmx-zdump.000".  [msg.panic.requestSupport.withLogAndCore] Please request sup­port and include the contents of the log file and core file.  [msg.panic.requestSupport.vmSupport.vmx86]
Apr 26 23:11:19.481: vcpu-0| To col­lect data to sub­mit to VMware sup­port, run "vm-support".
Apr 26 23:11:19.481: vcpu-0| [msg.panic.response] We will respond on the basis of your sup­port entit­le­ment.
Apr 26 23:11:19.481: vcpu-0| ----------------------------------------
Apr 26 23:11:19.582: vmx| VTHREAD wat­ched thread 4 "vcpu-0" died
Apr 26 23:11:19.682: Worker#0| VTHREAD wat­ched thread 0 "vmx" died
Apr 26 23:11:19.684: mks| VTHREAD wat­ched thread 0 "vmx" died

Ce pro­blème est ren­sei­gner dans la KB1020158. La par­ti­cu­la­rité c'est que cela inter­vient que pour les Win­dows 32bit avec plus de 3 Go de RAM et avec les VMware Tools au niveau de l'ESX en 4.0 update 1.

Pour le résoudre il faut reve­nir vers la ver­sion anté­rieure du dri­ver SVGA (le dri­ver est dis­po­nible en bas de la KB).

Après le plan­tage ou un arrêt violent d'un ESX, le File­Sys­tem / ne peut être monté au démar­rage, avec le mes­sage d'erreur "Ker­nel Panic: VFS: : unable to mount root fs on 00:00".

Vous avez essayer de mon­ter le File Sys­tem à la main en tapant les com­mandes "mount –o remount,rw /" puis "mount –a". On peut accé­der au logs avec "dmesg", faire un véri­fi­ca­tion de la table de par­ti­tion avec "fsck" (*) mais quand on redé­mar­rage les ser­vices cela néces­sité un reboot et au redé­mar­rage, on perd de nou­veau le FileSystem.

Ouf, heu­reu­se­ment il existe une KB pour ca: KB1004797. Voici la marche à suivre:

1. Chois­sir "Ser­vice Console-troubleshooting mode" au GRUB de démar­rage de l'ESX
2. Se connec­ter avec le compte root
3. taper la com­mande "esxcfg-boot -p" pour mettre à jour les para­mètres PCI
4. taper la com­mande "esxcfg-boot -b" pour mettre à jour les para­mètres de démarrage
5. taper la com­mande "esxcfg-boot -r" pour mettre à jour les fichiers de démarrage
6. redé­mar­rer l'ESX avec la com­mande "reboot" ou " "shut­down -r 0"

Et la on doit repar­tir sur un démar­rage clas­sique d'un ESX.

(*): si le démar­rage plante que le File­Sys­tem est en Read-Only, avec les mes­sages d'erreurs "Fai­led to copy esx.conf from ini­trd to file­sys­tem." et "Pos­sible cause: Read-Only File­sys­tem or sto­rage device". Il faut aller vers la KB1013233

Je com­mence cette série sur les KB, qui à défaut d'avoir le temps de faire des articles de toutes ces infos, j'en fait une syn­thèse. Voici la liste des KB inté­res­santes de ce mois-ci. La liste est longue pour le début de série.

ESX

• LUNs man­quantes après mise à jour ESX 3.5 update 5 vers ESX 4, KB1017469
• Ges­tion des LUNs détec­tés comme Snap­shot en ESX4 , KB1011387 et ESX3, KB9453805
• Com­prendre un PSOD avec le mes­sage "Fai­led to ack TLB inva­li­date" , KB1020214
• Com­prendre un PSOD avec un "Excep­tion 13" ou "Excep­tion 14", KB1020181
• Vali­der la mémoire d'un Host, KB1004012
• Faire que le para­mètre de LUN mas­king soit per­sis­tant sur les ESXs, KB2057
• Le ser­vice Hostd ne démarre plus après mise à jour d'ESX 4.0 à ESX 4.0 update 1, KB1016010
• Un host 64bits est reconnu seule­ment comme com­pa­tible 32bits, KB1006190
• Redé­mar­rer les agents de mana­ge­ment sur un ESX ou un ESXi, KB1003490
• Com­prendre un PSOD avec un mes­sage "Spin count excee­ded, pos­sible dead­lock", KB1020105
• Chan­ger le mot de passe root oublié sur un ESX, KB1317898
• Désac­ti­ver et Acti­ver le Web Access sur un ESX, KB1007617
• Erreur mémoire du ser­vice Pega­sus (CIM­ser­ver) constaté sur ESX 3.5 update 2 et supé­rieur, KB1009607
• Para­mètre Hal­tin­gId­leM­sec­Pe­nalty: guide de modi­fi­ca­tion l'équilibrage entre équité et débit des CPUs dans vSphere, KB1020233
• Envoyer les logs Hostd à un ser­veur Sys­log dis­tant, KB1019102
• Les paths des LUNs en iSCSI soft­ware ne reviennent pas après être passé offline, KB1016836

vCen­ter

• Erreur dans vCen­ter Ser­vice Sta­tus & Hard­ware Sta­tus quand on essaye de rafrai­chir l'Host, KB1014213
• Le ser­vice vCen­ter plante au démar­rage avec l'erreur: the pass­word for the user account has expi­red, KB1012498
• L'installation de vCen­ter 4 plante avec l'erreur 28035, KB1013530
• Plan­tage du ser­vice Vir­tual­Cen­ter avec une erreur SQL: Vio­la­tion of PRIMARY KEY constraint 'PK_VPX_GUEST_DISK', KB1020317
• Clé USB n'est plus dis­po­nible après décon­nec­tion du View Client sous Linux, KB1019986
• VM en Fault Tole­rant bas­cule rapi­de­ment entre ESX au démar­rage, KB1013400
• Erreur de copie de fichier .vmx et .nvram d'une VM allu­mée à par­tir du Datas­tore Brow­ser de vCen­ter, KB1019286
• Le plu­gin Upda­te­Ma­na­ger s'installe mais reste ins­tal­lable et ne peut être activé, KB1017052
• Après upgrade en ESX 4.0 update 1, les VMs plante au Power On avec l'erreur "Insuf­fi­cient resources" et le mes­sage "COS Swap not confi­gu­red" dans la console ESX, KB1016297
• Ini­tier plus de 16 taches dans le VI Client prend long­temps, KB4329356
• Impos­sible de connec­ter le CDrom à tra­vers le VI Client sous XP/Vista/7, KB1009065
• Ins­tal­ler PowerPath/VE pour vSphere en uti­li­sant Update Mana­ger, KB1019844
• Erreur dans Per­for­mance Over­view avec l'erreur "STATs Report ser­vice inter­nal error", KB1012812
• Sau­ve­garde file-level VCB n'arrive à libé­rer le Snap­shot après le fin du job, KB1005845
• Le che­min actif ne dis­pa­rait pas avec le LUN mas­king, KB1005596
• VCB avec Backu­pExec plante avec l'erreur: "Exit code 16", KB1012296
• Alarme Host connec­tion state change fré­quem­ment de Green à Red, KB1020210
• Déploie­ment d'un Tem­plate plante à 95 - 96%, KB1005783
• Cer­tain sto­ckage néces­sité un second Rescan pen­dant un Test & Reco­very SRM, KB1008283
• Ges­tion d'erreur de cer­ti­fi­cat dans SRM, KB1021031

View

• Sup­pri­mer manuel­le­ment les entrées des Lin­ked Clones ou des Bureaux Vir­tuel expi­rés dans View Mana­ger, KB1008658
• View Client 4.0.1 n'arrive pas a se connec­ter au bureau avec l'erreur: Connect desk­top fai­led, KB1019742
• Erreur de connexion et écran noir en se connec­tant à un bureau View en PCoIP, KB1016753
• Clé USB n'est plus dis­po­nible après décon­nec­tion du View Client sous Linux, KB1019986
• Résoudre le mes­sage d'erreur "Mis­sing VM was not in the ori­gi­nal query" dans l'event log de View Mana­ger, KB1009810
• Erreur "Mis­sing VM was not in the ori­gi­nal query" dans l'Event Log de View Mana­ger, KB1009810

VMs

• Migrer une VM avec des disques en RDM, KB1005241
• Ré-enregistrer des VMs dans l'état Orpha­ned, KB1007541
• Win­dows 2008 R2 plante à l'installation avec un BSOD, KB1015624
• Cus­to­mi­sa­tion de Win­dows 2008 64bit et 2008 R2 plante avec l'erreur: Cus­to­mi­za­tion of the guest OS 'windows7server64guest' not sup­por­ted in this confi­gu­ra­tion, KB1020716
• Impos­sible de créer des Snap­shots sur un Guest OS Win­dows, KB1019848
• Ajout à chaud de disques plante depuis mise à jour en vSphere avec l'erreur: license not avai­lable to per­form the ope­ra­tion, hot plug fea­ture requi­red, KB1013253
• Résoudre une VM qui appa­rait comme inva­lide, KB1002367
• Win­dows ne peut accé­der aux fichiers hgfs.dat et vmhgs.dat dans les pro­files, KB1317
• Erreur de ver­sion SCSIPORT.SYS ou BSOD avec l'erreur STOP Ox01E error lors du P2V d'un Win­dows 2000 SP4, KB1000719
• VM ne démarre pas à cause d'un fichier man­quant ou ver­rouillé, KB10051
• Limite Mémoire en fonc­tion de la ver­sion du Vir­tual Hard­ware d'une VM, KB1014006
• Le sys­tème de fichier Linux passe en Read-only, KB51306

Une bonne par­tie d'entre nous connait com­ment modi­fier les para­mètres de Queue-Depth sur des ESX (stan­dard) mais com­ment faire sur un ESXi? La pro­cé­dure change quelque peu mais s'applique de la même facon pour modi­fier le Net­Queue par exemple.

Pour modi­fier les para­mètres sur les cartes QLo­gic, il faut effec­tuer la pro­cé­dure sui­vante à par­tir du module vSphere CLI ou de la Vir­tual Appliance vMA (vSphere Mana­ge­ment Assistant):

1. Véri­fier que le module des carte HBA QLo­gic est bien chargé, avec la com­mande vicfg-module -l | grep qla
2. Ensuite taper la com­mande vicfg-module -s "ql2xmaxqdepth=64" ql2300_707 pour défi­nir une carte QLo­gic accé­dant à des LUNs avec une Queue Depth de 64.
3. Enfin redé­mar­rer le ser­veur ESXi pour que la modi­fi­ca­tion soit prise en compte

Pour les cartes Emu­lex, on uti­li­sera la variable lpfc0_lun_queue_depth avec le module lpfcdd.

Réfé­rence:

• http://vknowledge.wordpress.com/2010/03/23/adjust-queue-depth-on-vsphere-esxi/
• La KB1267 de VMware http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008113

NB:

Il est égale­ment pos­sible de le faire en Power­Shell comme expli­quer dans le très bon article d'Hypervizor.

Lorsque vous déployez plu­sieurs VMS depuis un même tem­plate VMWare, il se peut que les dif­fé­rents ser­veurs n'apparaissent pas cor­rec­te­ment dans la console WSUS. Dans mon cas, j'avais déployé 4 VMs et celles-ci appa­rais­saient à tour de rôle dans la console WSUS. Je n'avais, du coup, jamais les 4 ser­veurs au même moment dans la console.

Après plu­sieurs recherches, j'ai trouvé la KB sui­vante. Il existe en fait un iden­ti­fiant client WSUS unique pour chaque ser­veur ins­tallé, mais vu que ces ser­veurs ont été déployé à par­tir du même tem­plate, l'Id est iden­tique et les VMs sont vues de la même manière
Pro­cé­dure à suivre :

net stop wuauserv

Sup­pri­mer les clés sui­vantes dans le registre :

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientId

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\susClientIDValidation

net start wuau­serv
wuauclt.exe /resetauthorization /detectnow

http://support.microsoft.com/?scid=kb%3Ben-us%3B903262&x=17&y=11

Une KB1002281 VMware explique com­ment res­tau­rer la table de par­ti­tion VMFS. Cette KB est plus détaillée et contient la marche à suivre

Dans le cas de perte d'un Datas­tore VMFS et de mes­sage d'erreur "LVM could not open device" dans le fichier /var/log/vmkernel appli­quer cette pro­cé­dure qui s'applique au ESX 2/3/4.x, voici la marche à suivre:

1. Se connec­ter au ser­vice console
2. Iden­ti­fier le péri­phé­rique SCSI (/dev/sdX) au volume VMFS concerné par le pro­blème. En tapant la com­mande vmkp­ci­divy -q vmhba_devs en ESX 2.x, esxcfg-vmhbadevs -q en ESX 3.x ou esxcfg-scsidevs -c en ESX 4.x
3. Confir­mer la perte de la par­ti­tion avec la com­mande fdisk -l /dev/sdX
4. Recréer la table de la par­ti­tion avec la com­mande fdisk /dev/sdX puis nou­velle par­ti­tion n, pri­maire p, pre­mière par­ti­tion 1 et vali­der 2 fois la valeur par défaut
5. Choi­sir le type VMFS (fb) pour la par­ti­tion avec p, la pre­mière par­ti­tion 1 avec le type fb
6. Ali­gner la par­ti­tion avec le sec­teur 128 (sauf en ESX 2.x) avec les com­mandes expert x, begin b, pre­mière par­ti­tion 1 et sec­teur 128
7. Quit­ter fdisk en sau­ve­garde avec la com­mande w
8. Redé­cou­vrir le volume VMFS avec la com­mande vmkf­stools -V

HP Vir­tual Connect Flex-10 10Gb est la nou­velle tech­no­lo­gie HP embar­quée sur les bla­de­cen­ter HP (C3000/c7000) pour la ges­tion du réseau.

Dans le cadre de la vir­tua­li­sa­tion, cette tech­no­lo­gie offre en effet de mul­tiples pos­si­bi­li­tés. Elle per­met de décou­per les cartes réseau 10Gb Flex-10 en plu­sieurs cartes vir­tuelles allant de 100Mb à 10Gb par tranche de 100Mb. Cela per­met donc de mettre en place une pla­te­forme 1Gb évolu­tive vers le 10Gb, qui au pas­sage, reste encore très peu dévo­lo­pée dans les entreprises.

La pro­li­fé­ra­tion des machines vir­tuelles et des nou­velles tech­no­lo­gies (Fault Tole­rance sous Vmware) en envi­ron­ne­ment Bla­de­Cen­ter amène ainsi de nou­veaux besoins (Connexion 10Gb dans les machines vir­tuelles, VMotion/Fault Tolerance....)

La mise en place de VMware Fault Tole­rance recom­mande 2 cartes giga, ajou­ter à cela 2 cartes giga pour VMo­tion, quelques cartes giga pour nos machines vir­tuelles et nous arri­vons assez vite aux limites phy­siques, sur­tout dans une archi­tec­ture blade.

Voici donc ici un exemple d'implémentation de cette tech­no­lo­gie sur un infra­struc­ture giga­bit exclu­si­ve­ment. Nous ver­rons que cer­taines inter­faces, avec des vitesses bien défi­nies, peuvent être internes au blade.

Confi­gu­ra­tion exposée:

Bla­de­Sys­tem c3000

Lames BL460c G6

Switch : HP Vir­tual­Con­nect Flex-10 10Gb Ether­net Module for Bla­de­Sys­tem c-Class

Carte réseau : Carte réseau mul­ti­fonc­tion 10 Giga­bit Flex-10 2 ports (Broad­com HP NC532m) pour Bla­de­sys­tem c-Class

Vue logique :

• Ser­vice Console (connecté sur le réseau de pro­duc­tion) : vmnic0 et vmnic2
  

• LAN (connecté sur le réseau de pro­duc­tion) : vmnic1 et vmni3

• VMo­tion (interne au blade): vmnic4 et vmnic10
• Fault Tole­rance (interne au blade) : vmnic5 et vmnic11

Vue phy­sique :

Infos sup­plé­men­taires:

HP Bla­de­Sys­tem Refe­rence Archi­tec­ture: HP Vir­tual Connect Flex-10 and VMware vSphere 4.0

HP Flex-10 technology

Unders­tan­ding HP Flex-10 Map­pings with VMware ESX/vSphere