Régler les problèmes de freeze de Windows Server 2008 R2 sous VMware vSphere 4

Ceux d’entre vous qui déploient Windows Server 2008 R2 en environnement VMware vSphere 4 ont peut être eu la désagréable surprise de voir leur OS figé sans raison apparente. Dans ce cas, aucune autre alternative que d’éteindre en force le serveur. En cause, une incompatibilité graphique provoquée par un pilote SVGA après l’installation des VMware Tools relatée dans le KB VMware 1011709.

Si la solution – radicale – préconisée par l’éditeur est de passer votre hyperviseur en VMware vSphere 4 U1, vous n’avez peut-être pas de votre côté la possibilité d’observer tant de souplesse. Aussi, il vous faut une alternative.

Vous avez déjà installé les VMware Tools

Rendez-vous dans le Gestionnaire de périphériques, dépliez le dossier Cartes graphiques et repérez le driver incriminé VMware SVGA II.

A présent, cliquez droit > Désinstaller puis cochez Supprimer le pilote pour ce périphérique dans la fenêtre de confirmation qui apparaît.

Autrement, vous pouvez restaurer le pilote de carte précédent en passant par l’onglet Pilote de votre carte. Pour cela, passez par un clic droit sur le Bureau > Résolution d’écran > Paramètres avancés > bouton Propriétés

Après un redémarrage nécessaire pour prendre en compte les modifications, votre carte reprendra le driver graphique générique qui, à défaut d’être performant, ne vous fera pas planter le serveur.

Vous n’avez pas encore installé les VMware Tools

Lorsque vous lancerez les opérations d’installation, sélectionnez le type Personnalisé.

Ensuite, dans le menu Pilotes de périphériques VMware, désélectionnez simplement Pilote SVGA.

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 !

Utiliser le Thin Provisionning sous VMware vSphere 4

Une des avancées majeures de vSphere 4 concerne le support du Thin Provisionning qui permet d’économiser de l’espace disque sur un SAN en donnant la possibilité à l’administrateur de spécifier à des disques virtuels de ne consommer que la place réellement utile et de grandir au besoin, plutôt que d’allouer tout l’espace par défaut. Si la technologie est connue, son comportement sous vSphere mérite d’être mieux appréhendé.

Lorsque l’on déploie une machine, l’assistant Disk Format nous propose désormais l’option Thin provisioned format. Vous remarquerez au passage que seuls les systèmes de fichiers VMFS-3 supportent cette fonctionnalité.

Dans le montage ci-dessous, on a déployé le même template deux fois de suite. La première fois on a choisi Same format as source qui crée dans notre cas un disque Thick par défaut. La deuxième fois, on a choisi Thin provisioned format. On peut dès lors observer les différences d’allocation d’espace disque. La machine dont le disque utilise le Thin Provisionning ne consomme effectivement que 5,90 Go sur les 16 potentiels.

Lorsque l’on navigue dans le Datastore correspondant et qu’on ouvre le conteneur de la VM, on obtient la preuve que le Thin Provisionning est bien pris en compte.

Si maintenant on veut tester la fonctionnalité, il suffit de remplir l’espace disque vide en copiant des fichiers et constater l’agrandissement du disque VMDK en temps réel dans le Datastore.

Dans l’inventaire de la VM, un rafraîchissement de la vue du stockage indiquera la nouvelle allocation.

A partir de ces observations, vous devrez avoir compris le principe. Sachez toutefois que faire de la place sur un disque en Thin provisioned format ne provoquera pas une réduction du disque .vmdk pour autant. L’opération ne fonctionne en effet que dans un sens…

Le cas des snapshots

Etude de cas très importante que la création de snapshots en mode Thin Provisionning. Du moment où vous en aurez créé un, le provisionnement du disque augmentera automatiquement pour refléter les changements.

De retour dans le conteneur de la VM, vous découvrirez alors les fichiers habituels .vmsn et le nouveau .vmdk dans lequel les écritures s’effectueront jusqu’à la consolidation du snapshot. Lors de sa suppression, le provisionnement reviendra à son état initial.

Thin Provisionning rime avec planification

Si l’utilisation de cette technique est séduisante et permet de maximiser l’utilisation d’un SAN, n’oubliez jamais qu’elle peut vous amener à gérer des situations douloureuses, par exemple dans le cas où la taille totale de l’espace provisionné dépasserait l’espace disque total de votre Datastore à cause – pourquoi pas – de snapshots non maîtrisés.

La capture écran ci-dessous reflète l’utilisation la plus sécurisée de l’espace, dans le sens où la valeur Provisioned Space ne dépasse pas la valeur Capacity. C’est en revanche un constat extrêmement fréquent que de relever des valeurs de provisionning bien supérieures à la capacité totale physiquement disponible.

Pour éviter de vous faire surprendre par un volume plein, une seule solution invariable : monitorez plutôt deux fois qu’une le remplissage des disques, que ce soit par le biais d’alarmes dans le vCenter ou par un outil tiers !