Mettre à jour le Virtual Hardware sous VMware vSphere 4

Lors de la migration de VMware Virtual Infrastructure 3.5 vers vSphere 4, le Virtual Hardware ayant évolué pour passer de la version 4 à la version 7, vous devrez également planifier cette mise à jour pour toutes les machines qui en tirent réellement des bénéfices. Les autres pourront pour l’heure rester en version 4 vu la lourdeur des opérations que cela implique.

Le Virtual Hardware 7 offre plusieurs nouvelles caractéristiques dont :

• Périphériques virtuels SAS (Serial Attached SCSI) : permet le support des configurations en clustering de Windows Server 2008
• Périphériques virtuels IDE : permet le support des anciens systèmes d’exploitation qui ne gèrent pas les pilotes SCSI
• Support Hot Plug : permet aux systèmes d’exploitation supportés d’utiliser des fonctions hot add CPU et RAM et périphériques virtuels
• VMDirectPath : permet d’améliorer l’efficacité CPU des VMs en gérant la charge en fonction du nombre et de la fréquence des I/O des périphériques
• Block Tracking : permet d’améliorer les opérations de sauvegarde et de restauration
• VMXNET 3 : permet l’amélioration des performances réseau, le support IPv6, etc…

Identifier et mettre à jour le Virtual Hardware

Lorsque vous éditez les paramètres de configuration de votre machine virtuelle, l’information du vHardware s’obtient très simplement, en regardant au-dessus de la RAM allouée à la machine. Ici, vous cherchez toutes les machines en version 4.

Pour mettre à jour le Virtual Hardware d’une machine, éteignez votre VM et passez par le menu VM > Upgrade Virtual Hardware de la console ou simplement au moyen du clic droit > Upgrade Virtual Hardware.

Un message apparaît alors pour vous demander de confirmer l’opération. Notez le caractère irréversible de l’opération et prenez les dispositions qui s’imposent (préférez toujours le clone au snapshot).

Si vos VMware Tools ne sont pas à jour, l’assistant vous demandera d’annuler ou de continuer malgré tout. C’est une bonne pratique que de s’assurer que ses VMware Tools soient à jour avant toute upgrade du vHardware. Annulez donc l’installation, mettez vos VMware Tools à jour et recommencez.

L’installation des VMware Tools pour Windows se fait aisément au moyen du menu VM > Guest > Install/Upgrade VMware Tools ou par clic droit > Guest > Install/Upgrade VMware Tools. Pour Debian (Lenny), consultez cet article.

La mise à jour du Virtual Hardware ne prend que quelques secondes. Vous pouvez suivre son avancement dans la fenêtre des tâches récentes.

De retour dans les paramètres de configuration de votre serveur, vous devriez obtenir l’indication de la nouvelle version.

Sachez que la mise à jour que vous venez de faire apporte également un nouveau pilote réseau VMXNET 3 et un pilote para-virtuel PVSCSI (à ne pas utiliser pour les disques de démarrage avant vSphere 4 U1)

Utiliser le pilote VMXNET 3

Rendez-vous dans les paramètres de configuration de machine. Vous verrez qu’il n’est pas possible de changer le type d’adaptateur courant.

Vous devrez donc créer un adaptateur supplémentaire pour bénéficier du nouveau pilote VMXNET 3. Une fois celui-ci créé, supprimez l’ancien en ayant bien sûr pris soin de sauvegarder la configuration réseau de votre ancienne interface.

Pour obtenir plus de détails concernant les cartes réseau virtuelles, rendez-vous sur le blog VMware.

Si vos paramètres réseau sont trop laborieux à recopier, simplifiez-vous la vie en utilisant l’utilitaire en ligne de commandes netsh pour les sauvegarder :

C:>netsh interface ipv4 dump > "c:ip.txt"

Pour les restaurer sur la/les nouvelle(s) interface(s) (pensez à changer le nom de vos connexions dans le fichier d’export…), passez l’argument -f :

C:>netsh –f "c:ip.txt"
Réinitialisation de Général, OK !
Réinitialisation de Interface, OK !
Réinitialisation de Adresse unicast, OK !
Réinitialisation de Routage, OK !
Redémarrez l'ordinateur pour terminer cette action.

Rendez-vous sur le KB VMware 1005595 ou sur le site Microsoft Technet pour obtenir toutes les informations relatives à la commande netsh (lien pour Windows Server 2008)

Utiliser le pilote PVSCSI

Ce pilote n’est à utiliser que pour les machines très sollicitées niveau I/O (lire le KB VMware 1017652), autrement, cela peut même dégrader les performances.

Pour éviter un écran bleu Windows (BSOD) au démarrage, créez un deuxième disque VMDK (peut importe la taille, c’est temporaire) pour lequel vous choisirez le pilote VMware Paravirtual. Puisque c’est un nouveau contrôleur, isolez-le complètement en le mappant par exemple sur la Virtual Device node SCSI (1:0).

Une fois Windows démarré, il prendra en compte le changement matériel et sera prêt à accepter le nouveau pilote pour vos disques existants préalablement configurés en LSI Logic moyennenant un redémarrage pour charger les nouveaux pilotes.

Il ne vous reste donc plus qu’à effectuer les modifications sur vos disques de production et à supprimer le disque tampon.

Voici un exemple de BSOD que vous rencontrerez inévitablement si vous ne suivez pas ces conseils :

Il ne fait aucun doute que l’upgrade du vHardware doit être effectuée sur vos templates. Pour ce qui est de vos machines de production, comme je l’indiquais en début d’article, l’intérêt est bien moins évident. Analysez-donc attentivement les nouveautés avant de vous lancer dans ces opérations tête baissée et en tout état de cause, SAUVEGARDEZ !

Reconstruire un pack RAID 1 sur un HP Proliant ML350 G3

Sur un serveur HP Proliant ML350 G3, si jamais vous remarquez une diode rouge fixe sur un disque de votre pack RAID 1, cela signifie probablement qu’il faut le remplacer. Pour vérifier votre suspicion, connectez-vous au serveur et lancez l’outil HP Array Configuration Utility. En sélectionnant pour cet exemple le contrôleur Smart Array 642 dans Connecteur 1, vous observez immédiatement une alerte visuelle sur l’état du contrôleur.

Pour obtenir plus d’informations, cliquez sur Messages d’état. Dès lors, vous obtenez la confirmation du problème. Ici, il faudra donc remplacer un disque.

Les serveurs HP Proliant ML350 G3 sont assez obsolètes mais la technologie Hot Add était déjà implémentée. Comme nous avons ici 3 disques 36.4Go ULTRA320 SCSI 10K en RAID1, l’un d’eux sert de spare (RAID 1 + 0)et permet de garantir la continuité de service en cas de problème. On peut donc enlever le disque défectueux à chaud et le remplacer, tout en prenant au préalable le soin de quitter l’outil HP Array Configuration Utility (sinon vos disques clignoteront continuellement). Le serveur va de suite découvrir le nouveau disque et reconstruire le pack RAID avec.

En lançant de nouveau l’outil HP, l’état du contrôleur change. On clique de nouveau sur Messages d’état.

Désormais, le contrôleur indique qu’il reconstruit une unité logique RAID 1 + 0. Une fois les opérations terminées, plus aucune information n’apparaîtra dans l’état du contrôleur, signe que le problème est complètement réglé.

En façade, votre nouveau disque se verra assigner une diode verte fixe, signe de bonne santé.

Pour aller plus loin concernant la configuration de ces serveurs, je vous renvoie à la documentation HP relative aux Proliant ML350 G3.

Utiliser memtest pour détecter les erreurs de mémoire RAM

Une bonne pratique de déploiement de serveurs consiste à tester la RAM pendant 24/48h grâce à des outils constructeur ou tiers tels que Memtest86+ qui est probablement le plus connu et réputé. Le but étant, vous l’aurez compris, de détecter les pannes mémoire avant une mise en production.

Avec ce programme, vous pourrez détecter donc les pannes sur les processeurs et chipsets Intel, AMD, SiS, VIA, nVidia etc…de même, vous pourrez déterminer la fréquence mémoire FSB, le statut PAT, les timings mémoire, le statut ECC, le nombre de canaux mémoire, etc…
L’application est mise à jour régulièrement pour refléter les nombreuses évolutions matérielles des constructeurs. N’hésitez pas à vous tenir informé sur le site pour suivre les évolutions.

Preuve de la crédibilité de Memtest86+ dans le domaine IT, des éditeurs tels que VMware recommandent de l’utiliser pour diagnostiquer d’éventuels problèmes hardware ayant amené un crash ESX (voir le KB VMware 1003690). Les “grands” constructeurs eux-mêmes indiquent officieusement (car ils développent leurs propres solutions) qu’ils font confiance au programme, raison de plus pour l’utiliser sereinement…

Pour utiliser Memtest86+, téléchargez-le via l’image ISO mise à disposition sur le site, gravez-la puis démarrez dessus. En principe, les options par défaut suffisent, le but étant principalement de tester en profondeur et surtout dans le temps (le programme ne s’arrête qu’à votre demande !) les barrettes de votre nouveau serveur. Au besoin, vous pourrez configurer sommairement le programme en appuyant sur la touche C pour personnaliser vos tests, ce qui vous proposera quelques options supplémentaires :

Voici un exemple de test réussi sur un chipset Intel i875P :

Ici, un problème mémoire sur un chipset nVidia nForce4 :

Notez enfin que toutes les erreurs signalées par Memtest86+ ne sont pas forcément dues à la RAM étant donné que les tests utilisent – forcément – les mémoires caches L1 et L2 du CPU ainsi que la carte mère. Il est dès lors impossible pour le programme de savoir à 100% du temps d’où viennent les erreurs. Comme pour tout débuggage, on procédera par élimination des éléments suspects pour valider son diagnostic (inversion ou retrait de barrettes notamment).