VCSA on Zwindler's Reflection

vSphere Web Client : VMware Lookup Service SSL certificate verification Failed

Tue, 08 Aug 2017 11:30:25 +0000

Qui a entendu du VMware Lookup Service ?

[Aparté]M4vr0x ayant pas mal monopolisé le temps de parole sur Proxmox VE, je retourne un peu sur VMware histoire de changer un peu, mais rassurez vous, d’autres articles sur le clustering vont suivre ;-).[/Aparté]

Un matin d’astreinte comme les autres. On me réveille aux aurores car un serveur Business Object est encore dans les choux. Le serveur Windows qui l’héberge (je ne vous donnerai pas la version, vous allez vous moquer) est encore en carafe, encore pour une raison obscure (pas de pb de RAM, pas de charge CPU, pas de pic d’IO… normal ?).

C’est une vieille infra client, sur laquelle je n’ai plus trop mon mot à dire : elle n’est plus sous ma responsabilité directe, en dehors de l’astreinte. Mais j’ai quand même encore les accès en console VMware pour me connecter et regarder ce qui ne va pas.

Dans le doute, reboot. Si ça rate, reformate.

Un des hymnes de l’IT au bureau. Roy et Moss approuveraient.

Depuis quelques temps, j’ai des soucis avec mon client lourd vSphere. La console ne s’affiche pas en entier, du coup je ne vois que le quart supérieur gauche de l’écran, ce qui est relativement handicapant.

![](/2017/08/vsphere.avif

Ok je fais comment là ?

De toute façon comme il est déprécié et censé disparaitre depuis des années (la 5.5 je crois ?), je n’ai pas pris la peine de chercher pourquoi et n’utilise plus que le client Web, malgré sa lenteur épique sur les plus vieilles versions.

Manque de chance, un message d’erreur m’attend au login !

Failed to connect to VMware Lookup Service. SSL certificate verification failed

L’erreur a le mérite d’être assez clair. Quelque part, il y a un service qui se charge de vérifier un certificat et ce certificat est mauvais ! Heureusement on trouve pas mal de ressources en anglais sur le sujet, notamment chez Yellow bricks (pour la 5.1, lui).

« Lorsque vous modifiez le nom d’hôte de vCenter Server Appliance, une erreur Lookup Service apparaît lorsque vous redémarrez le dispositif. »

OK. Qui est le saucisson qui a modifié le hostname mais ne s’est pas logué après pour vérifier que ça fonctionnait ?

C’est donc tout simplement un certificat qui n’est plus valide car le nom d’hôte a changé.

On peut facilement corriger le problème en se connecter sur l’application d’administration de la VCSA. Vous l’avez utilisée lors de l’installation de l’appliance, via l’URL https://@IP_ou_FQDN_vcenter:5480.

Il faut se connecter avec le compte root de l’appliance, choisi au moment de l’installation.

Naviguez jusqu’à trouver l’onglet Admin. A partir de là, sur la 5.5, il y a un bouton radio qui permet de régénérer automatiquement les certificats si nécessaire. Passez le à « oui ». Idéalement il faudra penser à l’enlever une fois le problème réglé, pour d’évidentes raisons de sécurité.

La documentation officielle indique que redémarrer les services ne suffisent pas. Il est donc réellement nécessaire de rebooter complètement l’appliance car la régénération des certificats se fait au reboot.

Ne cliquez pas sur « Reset », ça efface tous le champs. J’en aurai une bonne à vous raconter à ce sujet d’ailleurs ;-).

Après le reboot, l’erreur sur le vsphere web client sur https://@IP_ou_FQDN_vcenter:9443 devrait avoir disparue !

Unable to connect to server

Tout est bien qui fini bien ? Non ! Si vous essayez comme moi de retourner sur le serveur de configuration du vCenter (pour prendre des captures d’écran et faire un article de wiki ou de blog par exemple), vous ne pourrez plus vous connecter. Après le login vous aurez le message suivant qui apparaitra en rouge :

Unable to connect to server

En réalité, c’est simplement un problème de cache de votre navigateur web. Il faut vider votre cache navigateur et accepter le nouveau certificat qui vient d’être régénéré.

Source

www.yellow-bricks.com/2012/12/19/failed-to-connect-to-vmware-lookup-service-ssl-certificate-verification-failed/
pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.troubleshooting.doc%2FGUID-D9ACB836-2BB4-4DDC-9383-91EF6E546A30.html (lien mort comme absolument tout chez VMware)

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 ! ;-)

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é