VCenter on Zwindler's Reflection

Changer le nom du vCenter 6 (vCSA)

Tue, 27 Dec 2016 12:55:00 +0000

Changer le nom du vCenter, facile ?

La version 6 de l’appliance vCSA est sortie depuis un moment déjà (début 2015). Et pas mal de choses ont changés depuis les premières versions que j’ai pu tester ! Au début, c’était moins léché, peu efficace (un SUSE très gourmand en RAM et avec moins de fonctionnalités). Et puis au fur et à mesure des versions, ça s’est amélioré.

Si vous souhaitez un tutoriel sur l’installation du vCSA 6, je vous conseille d’aller voir le très bon vladan.

Dans les versions précédentes, j’ai souvent du me connecter sur le shell du Linux pour modifier des paramètres qui ne pouvaient pas être modifiés autrement, comme le layout du clavier (Qwerty par défaut !) ou la quantité de RAM allouée à chaque composants du vCSA pour réduire son empreinte mémoire.

Dans cette nouvelle version, une surcouche a été ajoutée en console, ce qui change drastiquement l’administration ! Pour les non linuxiens, c’est certainement plus simple.

Je me suis donc demandé comment changer le hostname du vCenter que je venais d’installer. Et la première chose que j’ai tentée a été de retrouver un bash, pour rester dans ce que je connaissais.

Bash 2 en 1

Voilà à quoi ressemble la console lorsqu’on s’y connecte.

VMware vCenter Server Appliance 6.0.0.10000
Type: vCenter Server with an embedded Platform Services Controller
Using keyboard-interactive authentication.
Password:
Last login: xxx from xxx
Connected to service
* List APIs: "help api list"
* List Plugins: "help pi list"
* Enable BASH access: "shell.set --enabled True"
* Launch BASH: "shell"

A première vue, on peut toujours lancer un bash. Chouette !

Command> shell
Shell is disabled.

Ok…

Command> shell.set --enabled True
Command> shell
---------- !!!! WARNING WARNING WARNING !!!! ----------
Your use of "pi shell" has been logged!
The "pi shell" is intended for advanced troubleshooting operations and while
supported in this release, is a deprecated interface, and may be removed in a
future version of the product. For alternative commands, exit the "pi shell"
and run the "help" command.
The "pi shell" command launches a root bash shell. Commands within the shell
are not audited, and improper use of this command can severely harm the
system.

C’est donc clair. Le shell est encore là, pour l’instant. Mais il faut explicitement l’activer pour l’utiliser et il est clairement indiqué que ce n’est pas comme cela qu’il faut administrer votre vCSA car cette possibilité (dépréciée) sera probablement retirée à l’avenir.

La nouvelle façon d’administrer la console

Du coup, retour en mode non-bash pour jeter un œil aux possibilités offertes par la nouvelle méthode d’administrer en CLI le vCSA.

Command> help api list
Supported API calls by this server:
com.vmware.appliance.version1.access.consolecli.get
com.vmware.appliance.version1.access.consolecli.set
com.vmware.appliance.version1.access.dcui.get
com.vmware.appliance.version1.access.dcui.set
com.vmware.appliance.version1.access.shell.get
com.vmware.appliance.version1.access.shell.set
com.vmware.appliance.version1.access.ssh.get
com.vmware.appliance.version1.access.ssh.set
com.vmware.appliance.version1.localaccounts.user.add
com.vmware.appliance.version1.localaccounts.user.delete
[...]
com.vmware.appliance.version1.services.list
com.vmware.appliance.version1.services.restart
com.vmware.appliance.version1.services.status.get
com.vmware.appliance.version1.services.stop
com.vmware.appliance.version1.system.update.get
com.vmware.appliance.version1.system.update.set
com.vmware.appliance.version1.system.version.get
com.vmware.appliance.version1.timesync.get
com.vmware.appliance.version1.timesync.set

On voit qu’il existe un nombre relativement important de commandes. En réalité, à bien regarder, cela correspond finalement à l’ensemble des opérations que l’on peut réaliser directement depuis l’interface graphique web.

Cela n’a donc rien à voir avec l’accès direct qu’on peut avoir sur un Linux en shell, ce qui d’expérience est pourtant utile. Une fois de plus, VMware nous enferme dans le mode boite noire, ce qui aura le don d’agacer les habitués du monde Linux/Unix.

Je ne vais pas tout traiter dans ce tutoriel et juste me concentrer sur l’exemple que je cite en début d’article. Pour autant, vous avez l’accès à l’ensemble de la documentation sur le site de VMware (lien mort comme tout chez VMware).

Les commandes sont assez explicites et assez simples, avec une commande « get » et « set » et des « –help » à chaque fois.

Command> com.vmware.appliance.version1.networking.dns.hostname.get
Name: toto01
Command> com.vmware.appliance.version1.networking.dns.hostname.set --help
Usage:
com.vmware.appliance.version1.networking.dns.hostname.set
[--help/-h] --name STR
Description:
Set the Fully Qualified Domain Name.
Input Arguments:
--name STR
FQDN.
Command> com.vmware.appliance.version1.networking.dns.hostname.set --name vcenter.zwindler.fr
Command> com.vmware.appliance.version1.networking.dns.hostname.get
Name: vcenter01.zwindler.fr

Conclusion

Au final, c’est assez simple à utiliser, même si assez limité !

On ne peut pas dire que ce soit étonnant de la part de VMware : leur but, c’est bien entendu de faire un produit simple d’utilisation et éviter aux gens d’aller bidouiller.

Ainsi, il permettent au plus grand nombre d’administrer un vCenter sous Linux sans pour autant avoir des connaissances dans le domaine.
Personnellement, ça me rappelle la « hidden console » des ESXi lors des premières releases, qu’on ne pouvait accéder qu’après une combinaison de touches.

A vos shells limités ! ;-)

Client web pour version ESXi hors vCenter, le VMware Host Client

Thu, 26 May 2016 11:55:27 +0000

VMware Host Client : Le Half Life 3 des clients d’administration des hyperviseurs

Oui alors on a bien une version gratuite, pas de souci. Mais … vous ne pourrez plus utiliser le client lourd. Du coup il vaudrait mieux que vous vous payez un vCenter pour l’administrer, non ?

Cela fait un moment que VMware nous a annoncé que le client lourd (Java) ne serait plus mis à jour avec les nouvelles fonctionnalités. Et il faut dire que ce n’était pas forcément simple car il fallait installer le client de chaque version mineure (par exemple 5.0, 5.1, 5.5) pour pouvoir vous connecter à toutes vos versions, pas simplement la plus récente. Mais il avait le mérite de plutôt bien marcher et restait une référence correcte.

Pour autant, on ne peut pas dire que l’alternative proposée par VMware ait été particulièrement crédible. Le vSphere Web Client, censé corriger tous les défauts de la version client lourd avait quand même encore quelques gros défaut (mais certains étaient nouveaux alors c’est pas grave, non ?).

Pour avoir le vSphere Web Client, pas d’alternative, il vous faut vous payer un vCenter ! A quoi bon proposer un hyperviseur gratuit si c’est pour faire payer le client d’administration ? Ceci a longtemps été une vaste blague de la part de VMware avec aucune réponse officielle.

Pour autant votre client lourd reste vital pour certaines opération, comme l’accès direct aux ESXi sans passer par le vCenter. Le vCenter est down ? Dommage ! Vous pouvez ressortir le client lourd et tout refaire comme avant. Sauf ce que vous ne pouvez plus faire parce que réservé à la version web client.

Le vSphere Web Client nécessite l’installation de Flash sur le navigateur du poste d’administration, ainsi que plusieurs plugins à télécharger et à autoriser dans le navigateur pour pouvoir fonctionner à pleine capacité. Autant dire que l’avantage « c’est du web, donc 0 installation » vient instantanément de disparaitre…

Au delà de ces points rédhibitoires, le client web dans sa version actuelle est très lent et le serveur est assez gourmand en ressources (côté vCenter).

Bref on ne peut pas dire que je sois un grand fan. D’ailleurs, j’ai longtemps résisté à l’appel de la migration du hardware virtuel en v9, 10, et 11 car je savais que je ne pourrais plus modifier les paramètres (!!!) sur le client lourd une fois que ça aurait été fait (si le client web ne fonctionne plus, on fait quoi ? Oups…). Et oui, pas de mises à jour sur le client lourd ;-).

ENFIN !

Et bien CA Y EST !

Introduit avec la v6 en « test », VMware a créé un composant VIB (composant pour ESXi, à installer sur le serveur directement pour ceux qui ne connaissent pas) qui fourni un serveur web avec les fonctionnalités de base pour piloter l’ESXi et les VMs. Attention le but n’est pas de remplacer le vCenter mais bien de combler le vide d’un serveur pour piloter votre ESXi directement, sans vCenter et sans utiliser le client lourd.

Voici la liste des opérations qui peuvent être réalisées depuis ce Host Client :

Opérations basiques sur la machine virtuelle (démarrer, arrêter, etc)
Afficher la console de la machine virtuelle
Création d’une nouvelle machine virtuelle & déploiement d’un OVF/OVA
Afficher les informations sur l’état de de l’hyperviseur
Configuration du serveur ESXi et des ses composants comme vous le feriez avec le client lourd
Opérations basiques sur l’ESXi comme le rebooter

Initialement, pour l’installer il fallait installer soit même le fichier VIB sur l’ESXi et le rebooter. Cependant le composant étant passé en version 1, il est directement intégré à la toute nouvelle version d’ESXi 6.0 Update 2.

Les erreurs du passé

Et pour ne rien gâcher, même si l’interface web ressemble comme 2 gouttes d’eau au vSphere Web Client, il semblerait que VMware n’ait pas reproduit les erreurs du passé avec ce VMware Host Client, entièrement en HTLM5 et Javascript. Pas de Flash et de plugins navigateurs à installer, simplement le Javascript a autoriser sur les URLs de vos serveurs.

Dommage pour VMware que, faute d’une solution sans vCenter crédible, j’ai migré mon lab personnel sur KVM… ;-)

Sources

pubs.vmware.com/Release_Notes/en/vsphere/60/vmware-host-client-10-release-notes.html (lien mort comme tout chez VMware)
www.vladan.fr/esxi-free-web-client-interface/

vSphere 6.0 : Volumes VMFS désapprouvés

Sat, 31 Oct 2015 11:30:57 +0000

Symptômes

Si vous venez de passer à vSphere 6.0 comme moi, vous êtes peut être tombés sur le bug suivant. Dans un cluster vCenter, vous ajouter une datastore à partir d’un LUN que vous venez de créer. Celui ci est bien créé dans la toute dernière version (5.61), mais pour une raison inconnue, un avertissement « VMFS désapprouvés » apparaît sur tous les autres membres du clusters.

ou en anglais (l’erreur me semble souvent plus parlante en anglais chez VMware … c’est assez énervant) :

Pourtant nous sommes bien dans la dernière version, le datastore est bien visible sur tous les serveurs et même utilisable sans soucis.

Et bien ne vous fatiguez pas, c’est effectivement un bug, référencé par le KB suivant (lien mort).

Mais …

Currently, there is no resolution.

Ah ben cool sympa merci !

Contournement

En fait, ils donnent quand même une astuce pour contourner le problème, mais on ne peut pas dire que ça soit particulièrement pratique à mettre en place. En effet, l’erreur disparaît si vous redémarrez les agents de management de l’hôte.

Déjà, ça veut dire que vous devez passer sur TOUS vos serveurs et appliquer la procédure un par un (on peut le faire de différentes manières, notamment par ssh donc …), mais surtout, votre hôte devient temporairement inaccessible et donc c’est potentiellement problématique (surtout dans un cluster!).

Pour rappel, voici le KB (lien mort) qui liste les méthodes pour le faire. Moi je l’ai fais via la console (en iLO).

Sinon vous pouvez le faire par ligne de commande comme ceci :

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

En attendant mieux, il va falloir faire avec. Je ne manquerait pas de vous donnez la solution si VMware venait à réagir dans les prochains jours, mais il est fort à parier que cela passera par un patch à appliquer sur vos serveurs.

VMware 5.X + 2GBSparse : Erreur fichier …000001.vmdk introuvable après snapshot

Sat, 03 Oct 2015 10:30:52 +0000

Problème ?

Récemment je me suis fais une petite frayeur alors que j’effectuais une opération de maintenance en apparence banale : cloner une machine virtuelle.

Lors d’un clone de machine virtuelle à chaud, le serveur vCenter déclenche un snapshot temporaire pour pouvoir disposer d’un état au repos du disque dur à cloner. Et c’est pendant cette étape que j’ai reçu une erreur qui a non seulement fait planter mon clone, mais m’a aussi bloqué ma machine virtuelle.

Une erreur s’est produite lors de la consolidation des disques : msg.disklib.FILENOTFOUND.

Pire, impossible de relancer la machine virtuelle qui fonctionnait pourtant bien jusqu’à présent.

Le client m’indique de consolider les disques durs, mais quand j’ai essayé de consolider les disques durs, j’ai reçu l’erreur suivante :

On se mord la queue, là !

A partir de ce moment là, plus aucune opération sur la machine virtuelle ne fonctionnait (clone, snapshot, démarrage, consolidation, etc) et un vMotion ou storage vMotion n’avait aucun effet, éliminant les problèmes sur le matériel physique.

Cause

Ce n’est pas la première fois que je « râle » contre le niveau de détail, l’imprécision et la non-pertinence des erreurs remontées par VMware. Et visiblement ce ne sera pas la dernière !

Car en fait, il ne s’agit pas d’un bug à proprement parler. En fait c’est normal, mais vous ne le savez pas.

La machine virtuelle ne peut pas être clonée car les disques VMDK sont au format 2Gb Sparse qui ne sont plus supportés depuis la version 5.0. Tout simplement.

Dans mon cas, cette machine provient d’un prestataire qui nous l’a livrée avec des paramètres historiques, notamment ce format de VMDK non supporté.

Cependant, lors de l’import sur notre Infrastructure, à aucun moment VMware ne nous a prévenu que ce type de VMDK n’était plus supporté.
Pire, la machine virtuelle a fonctionné correctement pendant plusieurs jours, puis s’est bloquée sans prévenir pendant une banale opération de routine.

Et donc avec un message d’erreur trompeur puisqu’il ne s’agit pas d’un fichier manquant, juste d’un disque plus supporté !

Solution !

Heureusement le KB VMware apporte la solution et on peut régler le problème sans trop de difficultés.

kb.vmware.com (lien mort comme tous les KB de VMware)

On vérifie d’abord qu’il s’agit bien d’un problème lié à ce type de disque (voir createType)

/vmfs/volumes/502c61d6-jibber-jabber-uuid/maVM # cat maVM-2gbsparse.vmdk
# Disk DescriptorFile
version=1
CID=d20eb8ad
parentCID=ffffffff
isNativeSnapshot="no"
createType="twoGbMaxExtentSparse"
# Extent description
RW 207618048 SPARSE "maVM-s001.vmdk"
# The Disk Data Base
#DDB
ddb.adapterType = "ide"
ddb.encoding = "UTF-8"
ddb.geometry.cylinders = "12924"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "c81d0031d071fb58a1bb6317d20eb8ad"

La manipulation consiste alors à transformer via la commande vmkfstools directement sur l’ESXi le disque au format 2GBSpare vers un format autorisé (Thin provisioning dans mon exemple)

vmkfstools -i maVM-2gbsparse.vmdk ../maVM/maVM-thin.vmdk -d thin

Une fois que c’est fait, on peut supprimer le disque présent dans la configuration de la machine virtuelle et le remplacer par notre nouveau disque maVM-thin.vmdk.

A partir de là, elle devrait redémarrer correctement et peut être clonée/snapshotée/… Merci VMware.

#OuPas

vCenter, où, quand, comment ? Que choisir … en 2015 !

Thu, 23 Jul 2015 17:00:56 +0000

Un de mes articles qui intéresse le plus, et ce depuis le début du blog, est celui où je me pose la question “Où est ce qu’il est le plus opportun de situer un vCenter dans une infrastructure virtuelle VMware?”.

Si une bonne partie des recommandations et du retour d’expérience que je détaille dans cet article sont toujours valides, les choses ont quand même un peu changées depuis 2010. Et comme l’article attire toujours les visites, j’ai décidé que cela méritait bien un petit dépoussiérage, histoire que les nouveaux visiteurs puissent profiter d’un avis plus récent sur la question.

Attention : Une fois encore, cet article est plutôt long, ne contient pas vraiment de technique pure mais plutôt un retour sur expérience et mon ressenti face à des choix techniques que j’ai du faire. Il y a vraiment plusieurs solutions et bien malin celui qui peut donner « la bonne ».

Résumé des épisodes précédents

A l’époque, le contexte professionnel dans lequel je travaillais s’éveillait peu à peu à la virtualisation d’entreprise.

Pour tout dire, les serveurs de production étaient encore massivement physiques sans autre raison réelle que notre plateforme de virtualisation en place était encore un peu jeune pour la DSI. On parle de quelques Terminal Servers sous Windows 2003/2008 et un ou deux RedHat, une broutille.

Cependant, la virtualisation prenant de l’ampleur et des machines de productions étant prévues pour arriver directement sur l’hyperviseur sans passer par la case « serveur physique », j’ai du faire un choix pour savoir où migrer le vCenter. Il était alors hébergé sur un poste de travail crachotant gérant à la fois la supervision sous Linux et une machine virtuelle sous XP dédiée au vCenter. Autant dire que ça ne tenait pas du tout la route et qu’il fallait une solution plus pérenne pour assurer la production.

Deux (trois) solutions s’étaient alors présentées, que j’avais affectueusement nommés comme ceci :

1. La simplicité : booster le fameux poste de travail dans l’idée de garder la console d’administration hors du cluster qu’elle administre.
1. La brutalité : réinstaller le vCenter sur un vrai serveur physique. Le problème était de savoir comment migrer la base de données ou comment transformer la VM sous XP en serveur physique. Autant vous dire que j’ai vite compris qu’espérer faire du V2P (virtual to physical) était peine perdue, là où le P2V était bien rôdé (et c’est toujours le cas aujourd’hui).
1. Le choix VMware : j’avais été particulièrement surpris de voir que VMware conseille et supporte l’intégration du vCenter directement sur un des serveurs ESX(i) qu’il administre, dans le cas de petites installations.

Cette dernière solution m’avait particulièrement interloqué. Mais en y réfléchissant, j’avais assez vite compris l’intérêt de la chose :

3a) Une machine virtuelle n’a pas de raison de tomber en panne, là où la machine physique le peut, surtout lorsque c’est un vieux serveur de récup’, réutilisé pour l’occasion.
3b) A l’inverse, un serveur VMware demandant plus de puissant, c’était probablement une machine plus haut de gamme, moins sensible à la panne qu’un serveur lambda.
3c) Ensuite, la machine virtuelle se fiche de savoir sur quel serveur elle tourne => dans le pire des cas, le serveur qui héberge le vCenter tombe en panne. Pourtant, elle peut être redémarrée sur l’autre (ou les autres) serveur qui lui fonctionne toujours. Le principe reste le même si on doit déplacer le vCenter vers un autre serveur ESX(i), suite à un upgrade de la plateforme, par exemple.
3d) Enfin, la machine virtuelle peut évoluer sans contrainte, contrairement au serveur physique qui vivra sa vie et finira par devenir obsolète ou sous(/sur)dimensionné.

J’en avais donc déduis à l’époque que sur de petits clusters vCenter, la virtualisation de ce composant sur un serveur Windows paraissait une bonne idée, ne réservant les installations physiques que pour les gros clusters avec déport de base de données Oracle. Petit aparté, l’un n’empêche pas l’autre : on peut très bien avoir un vCenter virtuel et base Oracle déportée, mais je ne vois pas bien dans quel contexte.

D’accord. Mais en 2015?

Et bien en 2015, comme je le dis en introduction, les points que je cite dans la partie précédente sont toujours valables.

J’aime toujours le principe de séparer une console d’administration du cluster qu’elle administre, mais les gains apportés par la solution 2 me paraissent supérieurs à cet inconvénient. Je reste convaincu que cette dernière solution est la meilleure dans la plupart des cas, au bémol près que le point 2b) n’est pas (plus?) à généraliser.

On pourrait arguer que dans certains cas aujourd’hui, ça serait plutôt le contraire : les serveurs de virtualisation (nœuds Compute dans le jargon du « cloud ») sont devenus totalement remplaçables au sein des clusters, une panne n’ayant pas plus d’impact que la perte de redondance dans un RAID.

vCSA

Mais. Il y a bien un « Mais » sinon je ne récrirais pas cet article.

Mais depuis, VMware a publié diverses versions d’une machine virtuelle préinstallée sous Linux permettant de gérer le rôle vCenter sans licence (Microsoft) supplémentaire : la vCenter Server Appliance (vSCA), sous SLES 11. Et c’est d’autant plus sympa de la part de VMware qu’on a une licence SLES 11 incluse dans votre licence vCenter.

« Génial ! » me direz vous, car vous aimez Linux et vous avez bien raison (troll). « Pas si vite », je vous répondrais. Il y a des limitations.

Awww, man :-( too bad

D’abord, il faut savoir que les prérequis pour faire tourner la machine dans de bonnes conditions sont conséquentes : d’expérience, comptez environ 8Go de RAM, même pour un contexte de type HomeLab avec un serveur et quelques VMs. C’est assez gourmand, surtout quand on voit que le Tomcat réserve 3 Go à lui tout seul. Ça s’est cependant bien amélioré avec la version 5.5 (et voir le tuning sur la 5.1 ici)

Ensuite, gros gros gros point noir : il faut savoir que VMware Update Manager n’est pas non plus compatible avec Linux et donc vCSA. Pour mettre à jour vos ESXi, il faudra donc impérativement installer le module VUM sur un serveur Windows, ce qui annule l’avantage de la vCSA pour l’affranchissement de Windows dans des environnements full Linux/Unix/whatever.

Enfin, il y a quelques fonctionnalités que je n’utilise pas mais néanmoins assez utilisées et pas compatibles, comme :

Microsoft SQL en temps que base de données déportée pour vCenter.
le vCenter Server en « Linked Mode »
vCenter Server Heartbeat
et même le support de IPv6.

Hell yeah !!!

Pour autant, cette façon d’installer un vCenter est révolutionnaire. Via l’OVF, en quelques clics (5 minutes montre en main), vous avez une VM autonome jouant le rôle de vCenter pour vos ESXi, et vous amenant les fonctionnalités suivantes :

vSphere Web Client
vCenter Single Sign On (SSO)
vSphere Auto Deploy Server
ESXi Dump Collector
Inventory Service
Syslog Collector

Et si dans un premier temps, cet appliance ne convenait que pour les petites installation (5 hosts/50 VMs il me semble), elles peuvent maintenant atteindre les 400 serveurs et 4000 machines virtuelles. De quoi voir venir !

Non, franchement, le vCenter sur une machine virtuelle à de beaux jours devant lui

Quelques ressources supplémentaires sur la vSCA

Changer le clavier qwerty par défaut de l’appliance vCenter vCSA de 4 à 5.5
Réduire la RAM consommée par VMware vCenter Server Appliance 5.1 (vCSA 5.1)
Le KB de VMware pour « sizer » son vCSA (lien mort, comme tous les KBs VMware)
Un avis sur le célèbre site Yellow-Bricks à propos de vCSA, un peu daté mais toujours d’actualité

Changer le clavier par défaut : qwerty (de l’appliance vCenter vCSA 5.X)

Wed, 08 Apr 2015 15:07:24 +0000

Depuis vSphere 5.0, il est possible d’installer un vCenter sur une appliance virtuelle Linux et ainsi s’affranchir du cout d’une licence Windows, parfois utilisé exclusivement pour ce besoin.

Ça vous oblige à trancher par défaut la question du vCenter physique ou virtuel (voir </2010/06/01/vcenter-ou-quand-comment/>) et à vous accommoder de certaines limitations assez agaçantes (pas compatible avec les modules vCenter tiers + vSphere Update Manager doit quand même être installé sur Windows ? « Allo quoi! » comme dirait l’autre), mais s’affranchir de Windows, ça n’a pas de prix ;-)

Plus sérieusement, la vCSA (vCenter Server Appliance) a pas mal évolué depuis la version 5.0 pour arriver jusqu’à une 5.5 en Suse Entreprise Linux Server (1 licence SLES incluse avec votre licence vCenter !!! Youhou!), mais tout n’est pas encore parfait.

Un des gros problèmes est que, encore aujourd’hui, la console sur le vCenter est en qwerty.

AAAAAAAAAH !

Si vous avez une IP à changer ou un fichier de conf à modifier (par exemple </2013/05/07/reduire-la-ram-consommee-par-la-vmware-vcenter-appliance-5-1/>), vous allez devoir connaitre votre correspondance azerty/qwerty par cœur.

C’est un bon exercice cela dit, mais je suis sympa, je vais vous donner un coup de main ;-)

Pour changer le layout par défaut, le fichier à modifier est le suivant

vi /etc/sysconfig/keyboard

Dans ce fichier, la variable à modifier est la variable KEYTABLE. Cette variable doit avoir pour valeur le nom d’un fichier de layout avec le suffixe .kmap.gz et présents sur la machine à l’emplacement suivant :

vMA4 : /usr/lib/kbd/keymaps/i386
vMA5 : /usr/share/kbd/keymaps/i386

Pour faire simple, dans notre cas nous les Français/Azerty, il faut remplacer la partie us de cette variable (KEYTABLE=us.map.gz) par fr-latin9. Donc sur un clavier azerty, il faut taper les caractères fr)lqtinç

Rappels pour ceux qui n’aiment pas « vi », pour enregistrer il faut taper :wq hors du mode édition, et donc Mza sur votre azerty ;-)

Il ne reste plus qu’à sortir de la session courante avec exit, et se reloguer pour que la modification soit prise en compte.

Et voilà!

Pour aller plus loin, la source : ici (lien mort, j’utilise Internet Archive)

Réduire la RAM consommée par VMware vCenter Server Appliance 5.1 (vCSA 5.1)

Tue, 07 May 2013 15:49:57 +0000

Dans le cas où vous auriez la possibilité d’avoir un vCenter pour piloter votre/vos ESXi, vous avez probablement déjà installé vCenter sur un serveur Windows 2003/2008 qui traine (ou une VM), car ça a longtemps été le seul OS capable d’éxécuter l’installeur du vCenter.

C’était vraiment dommage, surtout quand on sait que ce n’est qu’une bête application Java derrière un Tomcat. Heureusement, après avoir vomi leur rage de Windows pendant des années sur les forums, les développeurs de chez VMware ont enfin pris le temps de penser aux Unixiens et réaliser un portage sous Linux. Il s’agit en fait d’une appliance prête à déployer (Novell Suse en l’occurrence pour l’appliance 5.1).

Après un bref passage sur le véloce (*ironie*) site de VMware, et un prompt téléchargement de ladite appliance, il est temps de la déployer sur notre hyperviseur préféré!

Une fois déployée, merci donc de jeter un petit coup d’œil sur la config de l’appliance vCSA (vCenter Server Appliance), ainsi que sur ce site :

KB VMware (lien mort, j’utilise Internet Archive)

Pourquoi je dis ça? Parce que moi lorsque je l’ai déployé et lancé sans me poser de question, j’ai entendu les disques grater. Mon ESXi s’est rapidement mis à swapper la RAM active de mes VMs… Oui, je n’ai qu’un petit lab avec 8Go de RAM, et l’appliance prend par défaut … 8Go de RAM!!!

Voyons voir ce qu’on peut faire pour y remédier…

Déjà, commencez par configurer l’appliance avec un peu moins de RAM, disons 4Go pour commencer (moi j’en suis à 3, et je pense qu’on peut encore faire mieux en désactivant certains composants).

Démarrez la. Une fois la VM lancée, configurer le vCenter en suivant le programme d’installation. Je ne couvrirai pas cette partie, de nombreux blogs le font déjà.

Une fois le serveur configuré et que nous sommes logués dessus en console, on remarque tout de suite qu’on a quand même pas mal d’espace pour swapper au cas où Java prendrait un peu trop ses aises !

free -m
total       used       free     shared    buffers     cached
Mem:          3017       2939         77          0          3        139
-/+ buffers/cache:       2797        219
Swap:        15366       1206      14160

Le seul travail qu’à fait VMware ici, c’est faire rentrer un multitude d’applications serveurs Java pour héberger les différents services qui composent la suite vSphere 5.1. Et quand on connait la gloutonnerie de Java…

Pour trouver les billes pour réduire la quantité de RAM consommée par cette appliance, je me suis basé sur une partie de la blogosphère qui traite malheureusement majoritairement de la version précédente de l’appliance (v5), et notamment cet article sur squishnet.org (lien mort, j’utilise Internet Archive).

Tuning de la base de données

Dans les préconisations des blogueurs qu’on peut y voir parler d’une base DB2. Or à priori, depuis la 5.1, VMware utilisent maintenant une base PostGreSQL

df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda3       10179904 4268324   5394460  45% /
udev             1544716     104   1544612   1% /dev
tmpfs            1544716       0   1544716   0% /dev/shm
/dev/sda1         130888   20994    103136  17% /boot
/dev/sdb1       20641788  176200  19416948   1% /storage/core
/dev/sdb2       20641788  409008  19184140   3% /storage/log
/dev/sdb3       20635732  319156  19268336   2% /storage/db

Je commence donc par tuner la mémoire kernel pour PostgreSQL (plus d’infos sur http://www.postgresql.org/docs/9.2/static/kernel-resources.html)

vi /etc/sysctl.conf
kernel.shmall = 524288
kernel.shmmax = 2147483648
sysctl -w kernel.shmmax=2147483648
sysctl -w kernel.shmall=524288

Tuning des JVM

Une fois que c’est fait, on peut maintenant s’attaquer au plus gros problème de cette appliance, les réservations ridicules de mémoires pour l’ensemble des composants Java

vi /usr/lib/vmware-vsphere-client/server/bin/dmk.sh
JAVA_OPTS="$JAVA_OPTS -Xmx512m -Xms512m -XX:PermSize-128m"

En plus des tweaks qui sont proposés, j’ai regardé les processus Java en cours de fonctionnement, et ai remarqué que le serveur VMware SSO consomme 2Go à lui seul.

ps -ef | grep ssod
[...] -Xms2048m -Xmx2048m [...]
2Go! -_- Même pas en rêve... Personnellement je ne l'utilise même pas dans mon lab, il faudrait que le trouve comme le couper carrément mais en attendant j'ai mis
vi /usr/lib/vmware-sso/bin/setenv.sh
[...] -Xms256m -Xmx512m [...]

Une fois que c’est fait, j’ai aussi remarqué qu’on pouvait modifier le fichier de conf de l’Inventory Service (dans le cadre d’un petit parc d’ESXi et de VMs), ainsi que le composant SPS (VMware vSphere Profile-Driven Storage Service) et les options par défaut des composants vpx.

vi /usr/lib/vmware-vpx/inventoryservice/wrapper/conf/wrapper.conf
# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256
# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024
vi /usr/lib/vmware-vpx/sps/wrapper/conf/wrapper.conf
# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256
# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=512
vi /etc/vmware-vpx/tomcat-java-opts.cfg
-Xmx512m -XX:MaxPermSize=256m -Dvim.logdir=/var/log/vmware/vpx

Aftermath (littéralement “après les maths”)

Après un redémarrage complet (un reboot est le plus crade mais le plus simple), les JVM devraient se tenir un peu plus à carreau. Je ne dis pas que tout fonctionne, car je n’ai pas tout testé (notamment le VMwareSSO pour lequel j’ai de sérieux doutes vu la quantité de RAM demandé à la base et le peu que je lui ai mis), mais le client VMware lourd ainsi que la version web répondent très bien.

Voici donc la liste des process java/vmware qui tournent sur la machine après tuning/reboot

/usr/lib/vmware-vpx/sps/wrapper/bin/./wrapper /usr/lib/vmware-vpx/sps/wrapper/bin/../conf/wrapper.conf (wrapper de vmware-sps)
/usr/java/jre-vmware/bin/java -Xms256m -Xmx512m (vmware-sps)
/usr/lib/vmware-vpx/inventoryservice/wrapper/bin/./wrapper /usr/lib/vmware-vpx/inventoryservice/wrapper/bin/../conf/wrapper.conf (wrapper de vpx/inventoryservice)
/usr/java/jre-vmware/bin/java -XX:PermSize=128m -XX:MaxPermSize=256m -Xms256m -Xmx1024m (vpx/inventoryservice)
/usr/java/jre-vmware/bin/java -Xmx512m -Xms512m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:MaxPermSize=256m (vmware-vsphere-client/server dans /usr/lib/vmware-vsphere-client/server/bin/dmk.sh)
/usr/java/jre-vmware/bin/java -XX:MaxPermSize=256M -Xms512m -Xmx512m (vmware-sso/webapps  dans /usr/lib/vmware-sso/bin/setenv.sh)

Processus auquels je n’ai pas touché car je ne suis pas vraiment certain de l’eur utilité et que ça ne mange pas beaucoup de RAM

/usr/java/jre-vmware/bin/java -Xms128m -Xmx512m (vmware-logbrowser ou com.vmware.vide.ws.server ?)
/usr/java/jre-vmware/bin/java -XX:PermSize=64M -Xmx512m -XX:MaxPermSize=256m (vfabric-tc-server-standard et son watchdog perso)

En tout cas dans mon lab, c’est indéniablement mieux que lorsque j’avais la RAM de mon host en train de swapper ;-)

BONUS TRACK : VMware Tools

Pour finir de tuner cette appliance, j’en profite pour référencer la solution permettant de résoudre le soucis “vmware tools non reconnus” de la machine virtuelle par l’hôte, à l’aide des précieuses instructions de virtuallyghetto http://www.virtuallyghetto.com/2011/07/tips-and-tricks-for-vma-5.html

/etc/init.d/vmware-tools-services stop
cp VMwareTools-9.0.0-782409.tar.gz /tmp/
cd /tmp
tar xzf VMwareTools-9.0.0-782409.tar.gz
cd vmware-tools-distrib
./vmware-install.pl

Accepter toutes les valeurs par défaut, et ignorer l’erreur lorsque l’installeur indique que gcc n’est pas présent car il n’est pas nécessaire. Après ça, le client VMware Tools sera bien affiché comme à jour dans l’interface vSphere.

Créer un modèle/template VM Windows XP sous ESXi sans vCenter

Sun, 20 Mar 2011 21:58:23 +0000

VMare a beau prétendre proposer un hyperviseur gratuit, la plupart des fonctions vitales d’un hyperviseur y sont absentes si on ne dispose pas d’une licence, contrairement aux concurrents (libres ou non). Sans prôner le libre à tout prix (je veux bien comprendre qu’il faut vivre de son produit, et ajouter des fonctionnalités selon les licences n’est pas une stratégie marketing dénuée de sens), il est quand même vraiment dommage de proposer un produit gratuit sans donner la possibilité de l’utiliser dans un environnement réel. Ça donne un peu le gout amer de shareware…

Parmi ces fonctions vitales qui n’ont aucunes raisons d’être payantes selon moi, j’ai nommé :

La possibilité de disposer d’un moyen de copier facilement des machines virtuelles pour déployer en peu de temps un SI virtualisé. Rien de plus horrible que de devoir se taper une demi heure de réponses débiles dans l’écran d’installation d’un OS. N’importe quel admin système a désespérément besoin de cette fonctionnalité, aussi petit soit le SI en question, et sans laquelle la virtualisation perd une bonne partie de son avantage en terme de gain de temps par rapport à une architecture physique…

Mais heureusement, il y a une petite astuce assez simple pour s’en affranchir.

Ne cherchez pas dans votre vSphere, la fonctionnalité pour copier des VMs n’apparaitra pas si vous ne disposez pas d’un vCenter. Cependant, en fouillant bien, on retrouve des fonctionnalités utilisant une notion un peu similaire, qui est la notion de template…

vSphere propose de créer et d’importer des virtuals appliances. Pour faire simple, ce sont des machines virtuelles « prêtes à fontionner », généralement diffusées sur Internet dans le but de fournir des produits logiciels un peu complexe sans installation (OS de supervision prêt à l’emploi, VM faisant office de pare feu, …).

En détournant cette fonctionnalité à notre avantage, il est donc possible de créer des templates (littéralement « modèle » ou « gabarit ») qui représentent des copies complètes de machines virtuelles à un instant donné. A partir de ce template, il sera donc possible de recréer autant de machines virtuelles identiques que l’on souhaite. CQFD

Voici donc un petit tuto dans la lignée du précédent (rien de techniquement agressif et probablement beaucoup trop détaillé) pour créer un template de VM Windows XP en prenant garde de modifier les paramètres qui doivent rester uniques. En effet, deux machines virtuelles créées à partir d’un template ne peuvent pas fonctionner sur un même réseau, pour les raisons suivantes :

Si la carte réseau virtuelle était configurée avec une adresse IP, elles auront la même adresse IP
Si elles hébergent un système d’exploitation Windows :
- Elles auront le même identifiant supposé unique (SID)
- Elles auront le même nom complet sur le réseau

Comme les données du disque dur sont enregistrées dans le template, il est conseillé de créer des templates avec le moins de données possible sur le disque dur, autant pour des raisons d’économie de l’espace disque que pour gagner en temps de création/déploiement.

Ainsi, il deviendra possible de recréer en quelques minutes des machines virtuelles minimalistes préconfigurées pour une tâche. Attention à ne pas tomber dans l’excès non plus : il est tout de même malin d’installer toutes les mises à jour et tous les logiciels susceptibles d’être installé sur tous les postes, le but de la création de template étant de gagner du temps!

Pour faciliter le déploiement de VM sous Windows, il est conseillé d’ajouter l’utilitaire NewSID.exe qui sera bine utile pour modifier les identifiants uniques de la machine avant de l’introduire sur le réseau.

Créer un template à partir du client vSphere

Choisir une machine à exporter en template, et l’éteindre
Sélectionner la machine virtuelle choisie
Cliquer sur File/Export/Export OVF Template
Entrer un nom et un répertoire de destination pour le template [Next]
Choisir le format d’enregistrement (OVF ou OVA) [Finish]

Ces deux formats sont tous les deux des valeurs possibles. OVF (Open Virtualization Format) est plus standard que OVA, il sera donc plus simple d’importer des fichiers OVF sur un autre système de virtualisation. Cependant, OVA offre la possibilité de tout stocker dans un seul fichier, contrairement à OVF qui génèrera plusieurs fichiers (configuration et disque dur).

Exporter un template à partir du client vSphere

Cliquer sur File/Deploy OVF Template
Choisir un template sur le disque ou depuis une url [Next]
L’assistant affiche une description du template [Next]
Entrez un nom pour la nouvelle machine virtuelle (qui n’existe pas déjà sur le serveur de virtualisation!) [Next]
Choisir dans quel pool la machine virtuelle doit être affectée [Next]
Choisir un Datastore dans lequel la machine virtuelle et sa configuration seront stockées [Next]
[Finish]

Une fois ces opérations terminées, la machine virtuelle est prête à être démarrée par le serveur ESXi. Cependant, il reste quelques opérations à effectuer :

Si la machine est sous Windows :
- Il faut changer le SID de la machine car cet SID est supposé unique. Or, toutes les machines déployées avec ce template auront le même SID : il faut donc en générer un nouveau. Ceci peut être fait à l’aide du programme NewSID.exe (voir la section « utilisation de NewSID.exe »). La modification de ce paramètre ne peut prendre effet qu’après redémarrage de la machine.
- Il faut donner un nouveau nom complet à la machine, car ce nom est supposé unique sur le réseau, et des noms identiques pourraient provoquer des conflits. L’utilitaire NewSID.exe permet de changer ce nom complet, après avoir généré un nouvel SID. Une autre manière de le faire est de d’effectuer l’opération suivante : Panneau de configuration/Système/Nom de l’ordinateur/Modifier et entrer un nom unique sur le réseau. La modification de se paramètre ne peut prendre effet qu’après redémarrage de la machine.
Attribuer à l’interface réseau virtuelle une adresse IP unique en fonction du plan d’adressage du réseau, un masque de réseau adéquat et l’adresse IP du serveur DNS.
Intégrer la machine nouvellement configurée au domaine. Pour se faire, il faut effectuer l’opération suivante : Panneau de configuration/Système/Nom de l’ordinateur/Modifier, sélectionner Membre de Domaine, et entrez le nom du domaine à intégrer.

Utilisation de NewSID.exe

Pour pouvoir modifier le SID et le nom complet de la machine, il faut suivre les étapes suivantes :

Exécuter NewSID.exe [Next]
L’utilitaire affiche le SID actuel, et propose d’en générer un nouveau [Next]
[Next]
L’utilitaire propose de renommer la machine, entrer un nouveau nom complet [Next]
[Next]

Normalement, après ces étapes, le SID sera modifié dans le registre, le nom complet sera modifié, et la machine redémarrera d’elle-même à la fin de la procédure.