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 !

Publier une application sous Windows Server 2008 (deuxième partie)

Avant toute chose, je vous invite à lire la première partie de cet article.

Il existe trois moyens d’accéder à une application publiée via Windows Server 2008 :

• Accès via un portail web
• Accès via un fichier .rdp déposé sur le bureau du client
• Accès via un package .msi installé sur l’ordinateur client

Accéder à une application publiée via un portail web

Afin de pouvoir joindre le portail web qui hébergera votre application, vous devrez autoriser vos utilisateurs en les ajoutant dans le groupe Ordinateurs Accès Web TS. Vu qu’il s’agit d’une démonstration, on garde seulement l’utilisateur Administrateur. Dans un cadre de production, vous utiliserez probablement un groupe de sécurité Active Directory.

Dans la première partie de cet article, je vous parlais du service Accès Bureau à distance par le Web. Comme son nom l’indique, c’est un service de rôle essentiel pour accéder au portail de vos applications publiées. Nous allons donc l’installer.

Depuis le Gestionnaire de serveur, cliquez droit sur les Services Bureau à distance et sélectionnez Ajouter des services de rôle.

Ensuite, cochez la case Accès Bureau à distance par le Web. Une fenêtre apparaît et vous indique alors qu’il faut notamment installer le Serveur Web (IIS), un classique chez Microsoft.

Au besoin, vous pourrez personnaliser l’installation du serveur web. Par défaut, les réglages proposés conviendront.

Passez enfin à l’installation du service de rôle, du serveur web ainsi que des Outils d’administration de serveur distant.

Une fois l’installation effectuée, vous découvrirez la présence du serveur IIS.

Après redémarrage, l’assistant de validation des Services Bureau à distance reflètera la nouvelle configuration. Toutefois, il est probable que vous rencontriez un message indiquant qu’une connexion Bureau à distance pour ce serveur n’est pas visible dans l’accès Bureau à distance par le Web.

Modifiez alors les paramètres de l’application et cochez la case Afficher une connexion Bureau à distance sur ce serveur hôte de session Bureau à distance dans l’accès Bureau à distance par le Web. Vous pourrez également en profiter pour changer le nom du serveur et éventuellement le port RDP afin de sécuriser votre installation.

Une fois les réglages effectués, rendez-vous à l’adresse https://<votre serveur>/rdweb sur laquelle vous devriez trouver la mire de connexion aux services Bureau à distance. Identifiez-vous.

Si la connexion est validée, vous trouverez enfin votre application publiée.

Lors du premier lancement, vous aurez probablement une alerte de sécurité Windows. Ne vous en inquiétez pas et validez.

L’application peut démarrer.

Si vous n’avez pas produit de certificat valide pour l’application, un message apparaîtra. Même opération, passez outre pour le moment. Il sera bien assez temps de régler ce point avant un passage en production.

Dès que la connexion est établie, un message s’affiche dans la barre de notifications. Vous pouvez commencer à utiliser l’application.

Si vous ouvrez le Gestionnaire des tâches de Windows, vous pourrez dès lors valider que l’application lancée s’exécute bien via un serveur distant.

Accéder à une application publiée via fichier .rdp ou package .msi

Parmi les options de publications que nous avons à disposition, existe donc la possibilité de créer un fichier .rdp ou un package .msi.  Vous pourrez commencer les opérations à partir de la page d’accueil des Services Bureau à distance.

Les réglages de publication par fichier .rdp sont très simples. Choisissez un emplacement de destination où enregistrer les packages, un serveur et un port associé, comme nous l’avons déjà étudié. Vous pourrez également charger un certificat valide à ce stade.

En navigant dans le répertoire de dépôt des packages, vous retrouverez vos applications publiées avec l’extension qui correspond à vos préférences.

La publication par package .msi varie sensiblement de celle par fichier .rdp. En effet, la seule différence notable concerne la configuration du package de distribution pour laquelle vous aurez la possibilité de créer des raccourcis sur le Bureau de l’utilisateur ainsi que dans le dossier menu Démarrer (par défaut Applications distantes).

Sur le Bureau utilisateur, les deux applications déployées à la main ou par exemple par GPO prendront pour le package .rdp la forme d’une connexion à distance classique alors que le package .msi installé ressemblera plus à une application publiée Citrix, bref, probablement plus défendable pour une utilisation d’entreprise.

Publier une application sous Windows Server 2008 (première partie)

Pour ceux qui sont familiers des publications d’applications sous Citrix, Windows Server 2008 propose une solution alternative avec les Services Bureau à distance (anciennement Terminal Server) qui semblent arriver enfin à maturité pour sortir du cadre habituel d’administration connu des techniciens. L’objectif est simple, vous désirez publiez une application à vos utilisateurs et vous voulez surtout que l’intégration se fasse de la façon la plus transparente qui soit, sans tous les tracas des couches superposées qui vous polluent la vie au quotidien (qui a parlé des problèmes de mappages d’imprimantes ?)

Installation des Services Bureau à distance

A la manière d’une promotion en contrôleur de domaine ou en serveur de fichiers, installez les Services Bureau à distance en cochant la croix prévue à cet effet. Pensez simplement à toujours installer les applications à publier après avoir installé le rôle.

Pour l’instant, nous ne cocherons que le service de rôle Hôte de session Bureau à distance. En production, vous pourrez au besoin installer le Gestionnaire de licences Bureau à distance ou l’Accès Bureau à distance par le Web (nous l’ajouterons  d’ailleurs plus tard dans cet article).

Windows Server 2008 amène une amélioration de la sécurité et propose désormais une authentification plus forte. A vous de juger ce qui vous ira le mieux en production. Pour l’exemple une nouvelle fois, nous choisirons l’option Ne nécessite pas l’authentification au niveau du réseau à des fins de rétro-compatibilité.

Idem pour les licences, nous choisissons Configurer ultérieurement alors que votre installation, pour être pérenne, devra nécessairement passer à terme par un mode de licence Par périphérique ou Par utilisateur (lisez d’ailleurs cet article pour obtenir des détails sur le sujet).

Enfin, vous pourrez d’ores et déjà ajouter les utilisateurs ou les groupes autorisés à administrer ce serveur Hôte de session Bureau à distance.

L’assistant vous proposera d’améliorer l’expérience utilisateur au moyen de fonctionnalités d’affichage avancées (thème Aero notamment). Dans la plupart des cas vous n’en tiendrez pas compte pour préférer les performances au confort visuel.

Une fois l’installation terminée, vous devrez redémarrer le serveur. Au prochain boot, vous verrez un message qui vous récapitulera les opérations effectuées.

Préparer la publication d’application

Nous arrivons enfin à la publication d’application. Rendez-vous pour cela dans le Gestionnaire de serveur et dans les Rôles, dépliez Service de Bureau à distance, repérez Gestionnaire RemoteApp (Nom de votre serveur) puis faites un clic droit > Ajouter des programmes RemoteApp.

L’Assistant RemoteApp s’ouvre et vous permet de sélectionner le ou les programme(s) déjà intallés possibles à publier par simple case à cocher.

Si vous cliquez sur le bouton Propriétés… vous aurez également la possibilité de personnaliser le nom du programme, de passer des arguments ou encore de changer l’alias de l’application.

Dans la fenêtre Programmes RemoteApp, vous retrouverez ainsi toutes vos applications candidates à la publication.

Dans le prochain article en ligne le 23/04, vous découvrirez trois manières de publier une application à vos utilisateurs.