VSphere 5.X 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)

[Tutoriel] Installation et configuration de VMware vSphere Replication 6.1.0

Sat, 02 Jan 2016 09:00:34 +0000

Présentation de VMware vSphere Replication

Une fonctionnalité sympathique (au moins sur le papier) lorsqu’on achète une licence VMware à partir de la très agressive Essential Plus est la possibilité de se créer un PRA automatisé via l’appliance VMware vSphere Replication.

L’idée est simple. Vous déployez l’appliance sur un ou plusieurs vCenter, puis vous sélectionnez les machines virtuelles que vous souhaitez synchroniser entre vos sites (ou sur un même site, cela créera une copie de sauvegarde) et régulièrement votre cluster VMware se charge d’en avoir une copie complète (mais en envoyant que le delta) à moins de X minutes de retard (Recovery Point Objective).

En réalité, le produit n’est ni plus ni moins qu’un équivalent de ce que font vos produits de sauvegarde de VM et qui tirent eux même partie des API de sauvegarde à chaud de VM mis à disposition par VMware (sauvegarde via snapshot, change block tracking, …). Je pense que ce produit se positionne comme concurrent des produits des grands éditeurs de la sauvegarde de VM (VEEAM pour n’en citer qu’un) et qui proposent pratiquement tous cette fonctionnalité.

Déploiement

Les captures d’écrans proviennent en partie d’un déploiement de vSphere Replication 5.8.1 mais il faut savoir que la procédure est strictement identique pour vSphere Replication 6.1.0. Je n’ai remonté aucune différence notable entre les deux outre le fait que l’une est pour un vCenter en version 5.X lorsque l’autre fonctionne avec un vCenter 6.X.

Récupérez le fichier zip contenant les sources de l’OVF de l’appliance vSphere Replication sur le site de VMware.

Pour la version 5.8.1 (vSphere 5.X)

VMware-vSphere_Replication-5.8.1.10254-2915556.zip (lien mort)
Administration de vSphere Replication 5.8 (lien mort, comme tout chez VMware)

Pour la version 6.1.0 (vSphere 6.X)

VMware-vSphere_Replication-6.1.0.10819-3051487.zip (lien mort)
Administration de vSphere Replication 6.1 (lien mort, comme tout chez VMware)

Connectez vous ensuite sur la console (client lourd ou web) et déployez l’OVF.

Pendant la phase de déploiement, renseignez le DNS, la passerelle, le netmask, puis l’adresse IP et le mot de passe root.

/!\ ACHTUNG : Avant de démarrer la VM, renseignez le hostname de la machine dans votre DNS et assurez vous bien que la machine y accède. C’est particulièrement vrai à partir de vSphere 6 où le problème s’est clairement amplifié et où aucuns de vos produits ne marcheront si votre DNS n’est pas correctement configuré (vCenter, Update Manager, vSphere Replication).

Bootez la machine virtuelle une fois que le déploiement est terminé. S’il y a eu une autre appliance précédemment enregistrée sur le vCenter, vous devrez valider en arrivant sur l’écran suivant :

Si tout se passe bien, on doit obtenir ceci dans la console.

Ouvrez un navigateur web pour finaliser la configuration de l’appliance via l’URL indiquée dans la console https://@IP_configurée:5480/

Vérifiez que les paramètres sont bons sur la console (les paramètres sont basiques).

Il faut ensuite vérifier que le serveur de réplication est bien connecté au serveur vCenter dans l’onglet VR/Configuration. Si ce n’est pas le cas, renseignez les logins/mdp du vCenter pour que l’appairage se fasse, puis cliquez sur « Save and Restart Service ».

Si tout fonctionne, la console doit afficher « VRM Service is running ».

De même, sur le client web vSphere, un nouveau module « vSphere Replication » apparait sur la page d’accueil.

Si vous souhaitez simplement disposer de la réplication sur un seul et même site, vous pouvez vous contenter de cette appliance.

Par contre, dans le cas où vous voudriez plutôt exporter les machines virtuelles sur un site de secours piloté par un autre vCenter, il faudra déployer une seconde appliance sur le deuxième site en suivant la même procédure.

Attention : les deux appliances doivent avoir la même version sinon elles ne communiqueront pas correctement. Et c’est donc potentiellement un problème car pour un vCenter 6.X, il vous faut une appliance vSphere Replication 6.1, et pour un vCenter 5.X une vSphere Replication 5.8. On en déduit donc que vos deux clusters doivent être de même version (5.X ou 6.X).

Configurer la réplication

Ouvrez maintenant la liste des machines virtuelles « Hôtes et clusters », puis faites un [clic droit] sur une machine virtuelle à répliquer.

Sélectionnez « Répliquer vers un système vCenter Server » dans tous les cas (c’est à dire, que le vCenter soit distinct sur un site de secours ou que vous souhaitiez rester au sein du même cluster).

Vous aurez donc le choix du site cible. Soit vous sélectionnez le vCenter local, soit vous ajoutez un site (vCenter) distant.

La première fois, seul le vCenter local apparaît. Si vous voulez en ajouter un autre, cliquez sur « Ajouter un site distant ». Remplissez les informations de connexion et un nouveau vCenter devrait apparaître dans la liste.

Cet écran est particulièrement intéressant puisqu’il nous permet de régler le RPO (Perte de données maximale admissible) ce qui aura bien entendu un impact sur la quantité de données qu’on va perdre en cas de bascule sur le PRA mais aussi la fréquence à laquelle les données entre sites seront synchronisées.

Une fois que c’est terminé, on peut observer l’état de santé de la réplication dans la page « Surveiller » du vCenter.

Et pour finir, les paramètres de la réplication peuvent être modifiés en ouvrant la page « Gérer » du vCenter.

Troubleshooting

La plupart des erreurs que vous pouvez avoir lors du déploiement des appliances VMware (que ce soit le vCenter VCSA ou le vSphere Replication) sont liés à des problèmes de résolution DNS. Comme les déploiements sont relativement longs donc je vous conseille vivement de bien vérifier que vos DNS sont bien à jour et que toutes les machines résolvent bien tous les noms, sinon vous devrez probablement tout recommencer.

Erreur « Invalid URI : The format of the URI could not be determined ».

Dans mon cas, le hostname du vCenter ne correspondait pas avec l’entrée dans le DNS et l’appliance de réplication n’arrivait pas à résoudre le vCenter.

L’icône refusait d’apparaître dans la console vCenter. Quand j’essayais d’ajouter manuellement le plugin à la main dans la console vSphere Client, le message suivant pouvait être lu dans le log de débug.

Heureusement que nous avons toujours le client lourd, car aucune erreur n’était visible dans le client web !

[       :startup :W: 1] 2015-11-26 16:03:05.159 Log for vSphere Client Launcher, pid=8744, version=6.0.0, build=build-3016447, option=release
[       :Failed t:P: 3] 2015-11-26 16:03:31.993 System.Net.WebException: Le nom distant n'a pas pu être résolu: 'vcenter'

Voir le KB de VMware (lien mort comme tout chez VMware) pour plus d’informations.

Limitations

Rétrocompatibilité

La première limitation que j’ai rencontré au produit est l’absence de rétro compatibilité entre les instances de vSphere Replication. Et donc comme on doit installer la version qui correspond à la version de son vCenter, cela vous oblige à avoir des clusters à des niveau de vSphere identiques, ce qui n’est pas toujours facile à réaliser selon les contextes.

Dans le fond, on ne peut pas trop leur en vouloir, c’est leur outil après tout. Ce qui est plus agaçant et qui est assez courant chez VMware, c’est l’absence de garde fou ou même de message d’erreur. Pour vous donner une idée, j’ai essayé de le faire lorsque je ne savais pas encore que les appliances 5.8 et 6.1 n’étaient pas compatibles. Que j’essaye d’initier la connexion depuis l’une ou l’autre, un message d’erreur pas du tout explicite s’affichait dans un sens, et il ne se passait rien du tout dans l’autre.

Il aurait été tellement simplement pourtant d’ajouter une petite vérification pour dire « Ah non ça ce n’est pas possible, pas la bonne version ! ». Mais bon ;-).

Bande passante

Le deuxième point est assumé par VMware et je ne comprend vraiment pas leur position.

Lorsque vous faite du vSphere Replication, il faut que les deux clusters aient entre eux un lien dédié à cela, que vous devrez estimer vous même en fonction de la taille estimée du delta à faire passer dans ce lien en fonction du RPO défini (voir le KB VMware (lien mort comme tout chez VMware)).

Pourquoi ? Tout simplement parce que lorsque vous allez lancer la synchronisation, votre liaison inter-site sera totalement saturée par vSphere Replication.

Does the vSphere Replication feature incorporate WAN bandwidth management?
No. vSphere Replication does not incorporate WAN bandwidth management. Use WAN optimizers to throttle and prioritize vSphere Replication traffic. To make it easier, vSphere Replication separates the initial replication from the ongoing replication using different ports so that you can assign different traffic shaping rules to the initial replication and ongoing replication.

Pas de gestion type QOS/traffic shaping pour restreindre la bande passante. A vous de le gérer vous même, soit via des équipements réseaux capable de gérer du trafic sur les ports utilisés par vSphere Replication, soit via des distributed vSwitchs et leur fonctionnalité Network IO Control (NIOC), disponibles si vous avez la version … Enterprise Plus (!!!).

Alors d’accord, une partie du problème peut être contourné en envoyant un disque dur avec les VMDK des machines à synchroniser sur le second site. Vous pouvez ainsi vous économiser l’envoi d’une grosse quantité d’information pour la première synchronisation et c’est seulement les deltas qui transiteront périodiquement sur votre réseau.

Pour autant, pour peu que vous ayez de grosses écritures sur les machines virtuelles que vous synchronisez, le problème reste entier. Le delta important entre deux synchronisations provoquera une saturation du réseau entre les deux sites.

En résumé, de la façon dont je vois les choses : vSphere Replication vers un site distant, disponible pour pratiquement tous les professionnels car accessible à partir de la très peu coûteuse Essential Plus, est donc totalement inutilisable sauf si :

Vous pouvez faire du traffic shaping sur votre infrastructure réseau
Vous disposez d’une liaison dédiée à cela (ou vous vous fichez de saturer votre réseau)
Vous avez la licence vSphere Entreprise Plus

Merci VMware. Trop sympa.

Documentation diverse

La documentation officielle sur le site de VMware (lien mort, comme tout chez VMware)
FAQ avec plusieurs points techniques intéressants sur vSphere Replication (lien mort, comme tout chez VMware)
La page wikipedia sur les PRA, relativement claire et permet d’appréhender les concepts
Le tutoriel de Yellow-Bricks pour la version 5.1 en mode réplication locale
La solution de VM Guy en utilisant le NIOC des VDS (lien mort, j’utilise Internet Archive)

[En bref] Ajouter une route supplémentaire sur un serveur VMware ESXi

Sat, 12 Dec 2015 11:30:52 +0000

Présentation du contexte

Dans certains cas où les ESXi sont placés sur plusieurs plans d’adressages différents, il peut être utile de pouvoir spécifier des routes autres que celle par défaut.

Typiquement, j’en ai eu besoin dans le cas de la migration d’un ancien cœur de réseau vers un nouveau (et surtout, dans un nouveau plan d’adressage).

Pour ne pas impacter la production, la gateway par défaut est restée la même. Le serveur ESXi a été connecté sur le nouveau cœur de réseau (encore … dans le nouveau plan d’adressage), et un nouveau vswitch a été créé sur l’ESXi.

L’ensemble des machines virtuelles ont été connectées au nouveau réseau, facilitant la migration le jour de la bascule.

Cependant, pour que la connectivité soit complète, l’ensemble des requêtes en direction du nouveau réseau devaient bien entendue être routée … vers le nouveau réseau.

Le KB de VMware (lien mort, j’utilise Internet Archive) suivant donne toutes les infos nécessaires sur le sujet.

ESXi 4.x et 5.0

Dans un shell ESXi ou via SSH, exécuter la commande suivante

esxcfg-route -a target_network_IP netmask default_gateway

Par exemple dans le cas cité plus haut

esxcfg-route -a 200.140.0.0/16 200.140.84.2

Point d’attention supplémentaire pour ESXi 5.0, les routes ne survivants pas au reboot pour cette version en particulier, il faut ajouter la commande dans le fichier **/etc/rc.local**.

ESXi 5.1, ESXi 5.5, ESXi 6.0

Dans un shell ESXi ou via SSH, exécuter la commande suivante

esxcli network ip route ipv4/ipv6 add --gateway IPv4_address_of_router --network IPv4_address

Par exemple dans le cas cité plus haut

esxcli network ip route ipv4 add --gateway 200.140.84.2 --network 200.140.0.0/16

Pour afficher la table de routage résultante, exécuter la commande

esxcfg-route -l