Sur Win­dows 2008 R2, lors de la pré­sen­ta­tion de volumes à une machine dis­po­sant de l'EFI (Exten­sible Firm­ware Inter­face), un pro­blème peut sur­ve­nir lors d'un redémarrage.

Il se peut que le ser­veur ne par­vienne pas à démar­rer sur ces disques locaux, pour celà Micro­soft a sorti un cor­rec­tif que voici :

http://support.microsoft.com/kb/979374/en-us

Micro­soft vient de sor­tir un pos­ter d'architecture des com­po­sants d'Hyper-V R2. Il est télé­char­geable en for­mat PDF.

Voici la liste des com­po­sants détaillé dans le poster:

• Archi­tec­ture
• Vir­tual networking
• VM Snap­shots
• Live Migra­tion
• Sto­rage Interfaces
• Sto­rage Types
• Import & Export

Merci au blog Virtual-PC-Guy d'avoir relayé l'info

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...

Carlo Cos­tanzo a écrit un article inté­res­sant sur le redi­men­sion­ne­ment d'un vDisk uti­lisé en Pro­vi­sion­ning Services.

Voici rapi­de­ment ca pro­cé­dure (basé la CTX118608) en français:

Lire la suite...

Voici un eBook com­plet de 540 pages en fran­çais (consul­table en ligne): Hyper-V et SCVMM - Tech­no­lo­gie de Vir­tua­li­sa­tion sous Win­dows 2008 R2 :

Et tout aussi inté­res­sant (mais en anglais) le "Sur­vi­val Guide" d'Hyper-V : http://social.technet.microsoft.com/wiki/contents/articles/hyper-v-survival-guide.aspx

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