vRLI : reset du mot de passe utilisateur cassandra

Récemment sur un vRLI 4.8.0-13036238, nous avons constaté que le compte par défaut de Cassandra (user : cassandra) avait un mot de passe qui ne respectait pas  les critères de sécurité de notre entreprise. Pour faire un  reset du mot de passe du compte user “cassandra” dans Cassandra (vous nous suivez ? 🙂 ) , il faut ouvrir une console SSH sur votre vRLI puis entrer dans Cassandra et lancer deux commandes.

Une fois connecté en SSH sur votre vRLI, lancer la commande ci-dessous afin de rentrer dans Cassandra.

/usr/lib/loginsight/application/lib/apache-cassandra-*/bin/cqlsh -u cassandra -p YourPassword
Il ne reste plus qu’à faire un reset du password 😉

Entrer la commande ci-dessous afin de faire le reset du password du compte cassandra.

ALTER USER cassandra WITH PASSWORD 'NewPassword';
Taper exit puis valider.

Quelques liens utiles :

Post to Twitter

VM avec deux Datastores appartenant à deux Clusters de Datastores différents

Lors d’un dernier check de routine avant une decomm de Datastore nous avons eu l’agréable surprise  de tomber sur une VM qui avait deux Datastores qui eux-mêmes appartenaient à deux clusters de Datastore différents (jusqu’a là pourquoi pas… mais vu que la dite VM n’avait rien à faire là, nous avons voulu en savoir plus.)

Là où c’est rigolo c’est que le premier Datastore est complètement vide et que le deuxième Datastore contient bien tous les fichiers de notre VM 🙂

On s’aperçoit aussi que toute modification de la VM est impossible (ce qui nous étonne qu’à moitié) et que notre VM a une ISO attachée (ça donne une bonne piste vous l’aurez compris.)

En googlelant nous sommes tombés sur la KB2105343  qui explique en détail comment procéder pour supprimer le Datastore “intrus”.

  1. Vérifier l’emplacement du fichier vmx de la vm
  2. Faire un “Power Off” de la vm
  3. Faire un “Remove from Inventory” de la vm
  4. Inventorier la vm dans le vCenter
  5. Faire un clique droit sur la vm, Edit Setting, dans “CD/DVD drive 1*” choisir “Client Drive” puis cliquer sur le bouton “OK”
  6. Vous pouvez “Power On” la VM si vous le souhaitez
Nous avons désormais un seul Datastore et on va pouvoir décommissionner notre Datastore vide 🙂

Post to Twitter

Error : A specified parameter was not correct……

Lors d’un Storage vMotion en masse nous avons rencontré sur certaines VMs l’erreur ci-dessous.

A specified parameter was not correct: ConfigSpec.files.vmPathName

En regardant de plus près même la suppression d’une des VMs en question n’était pas possible non plus (au préalable on a bien vérifié qu’on avait un backup récent 🙂 ).

Afin de pouvoir terminer notre Storage vMotion nous avons dû faire un “Remove from Inventory”sur les VMs qui posaient problème puis les inventorier dans le vCenter (6.7.0.48000)

Ci-dessous la commande pour afficher les VMs d’un vCenter avec leurs clusters, dossiers et le chemin du vmx.

Get-VM | Select Name, @{N="Cluster";E={Get-Cluster -VM $_}}, @{N="vmx Path";E={$_.ExtensionData.Config.Files.VmPathName}},@{N="VM Folder";E={$_.folder}}

Ci-dessous un exemple de commande pour inventorier une VM qui causait problème.

New-VM -VMFilePath "[datastore0] FolderVm/MyVM1.vmx" -VMHost (Get-Cluster "MyCluster" | Get-VMHost | Get-Random) -Location (Get-Folder MyFolder) -RunAsync

Comme vous savez faire vos boucles, il vous reste plus qu’à….. 😉

Post to Twitter

vROPs : Not receiving data from the Desktop Agent

Nous voilà de retour avec vROps  (vous allez croire qu’on est fan à force), cette fois-ci ce sont des vms de type dekstop qui ne remontaient plus d’infos dans vROps depuis leur Desktop Agent.  Le message d’erreur  dans le dashboard “Horizon Help Desk” était :

Not receiving data from the Desktop Agent

Ne soyons pas médisants on a déjà le protocole qui remonte 🙂

En collaboration avec notre collègue de l’équipe “Poste de Travail” (Christophe Mazzardis) nous avons regardé sur plusieurs vms impactées et avons remarqué que dans la log de l’agent View (C:\ProgramData\VMware\vRealize Operations for Horizon\Desktop Agent\logs\v4v-vrops-rmi-YYYY-MM-DD.log) nous avions l’erreur ci-dessous :

0x00002e70 ERROR    Failed to initialize RMI in the Java client.  java.io.IOException: Invalid keystore format


Vous l’aurez compris le “Invalid keystore format” nous a permis rapidement de faire la liaison avec le fichier “v4pa-truststore.jks” (ce fichier contient le magasin de confiance que l’adaptateur utilise pour authentifier le certificat du broker agent)  situé dans “C:\ProgramData\VMware\vRealize Operations for Horizon\Desktop Agent\conf”. En remplaçant le fichier “v4pa-truststore.jks” par un fichier d’une vm ne posant pas de problème et en relançant le service “v4v_agent” (Vmware vRealize Operations for Horizon Desktop Agent) nous avons pu à nouveau obtenir la remontée des métriques view dans vROps.

On regarde vite fait dans le fichier de log Agent\logs\v4v-vrops-rmi-YYYY-MM-DD.log pour voir si ça se passe bien.

7:14:46 0x00000a68 INFO     Using message server ‘rmi://vROPsIP:3091′.
17:14:46 0x00000a68 INFO     UnregisterDataDumpCallback success: (, , )
17:14:46 0x00000a68 INFO     RegisterDataDumpCallback success: (rmi:// vROPsIP:3091,
539dc7df8b99f2fbddfe841c9332b8dabe1426eee73b449c3b3bfd7fc3d4c1ba, 0500304531153013060355040A130C564D776172652C20496E632E312C302A060355040313237643656E746572204F7065723656E746572204F706573656E746572204F706573656E7B83E986FD33AC301EE104FC25C1DE7435495A………………)
17:14:46 0x00000a68 INFO     Using message server ‘rmi:// vROPsIP:3091’.
17:14:46 0x00000c0c INFO     Using JRE from ‘C:\Program Files\VMware\VMware View\Agent\jre\’.
17:14:47 0x00000c0c INFO     SUCCESSFULLY initialized the Message Logger.
17:14:47 0x00000c0c INFO     Initialized communication manager.
17:14:47 0x00000c0c INFO     Updated the message server URL in the Java client to rmi:// vROPsIP:3091.


Le “SUCCESSFULLY initialized the Message Logger” confirme que tout est ok.

Retournons côté vROps afin de voir si notre vm a bien ses métriques View qui remontent.

Après quelques minutes tout est ok

Maintenant que le problème est résolu, on va essayer de lire le fichier “v4pa-truststore.jks”  (qui causait problème) via “KeyStore Explorer” (le mot de passe du fichier “v4pa-truststore.jks” est contenu dans le fichier “msgclient.properties” (truspass =……..).

Comme nous sommes sur du mot de passe, nous optons pour “le fichier magasin de certificats est corrompu”….on va cliquer sur Ok comme on est joueur
Et en cliquant sur le bouton Détails ?
Nous ne sommes pas plus avancés pour l’instant…..

Maintenant nous allons regarder  ce qu’il y a dans un fichier “v4pa-truststore.jks” sain.

On a bien la liste des certificats 🙂

Retournons côté vROps pour voir si notre vm remonte bien les métriques View.

Nickel

Post to Twitter

vROps : No Data

Dans un vROps (8.01) dédié à une infra Horizon View (ver 7.10) nous sommes tombés sur un “No Data” dans le Dashboard “Horizon Adapter Self Health” dans la section “Horizon Broker Agent Event DB Collection Statistics”.

On sent qu’on va adorer la suite… 🙂

Direction le Connection Server où est installé le Broker Agent afin de vérifier que tout est bien configuré (pour la partie Event DB).  Allez dans le menu Démarrer – Executer et tapez la commande ci-dessous afin de lancer le “Broker Agent Config Utility for Horizon”. 

C:\Program Files\VMware\vRealize Operations for Horizon\Broker Agent\bin\v4v_brokeragentcfg.exe

Passez les étapes de Pairing et de Connection Server, nous arrivons à l’écran “Configure the Envent DB and Pool Filters”, lors du test username/password nous obtenons l’erreur ci-dessous :

Event DB username and password cannot be validated
Format of the initialization string does not confirm to specification starting at index 104
An error has Occurred
Operation Validate DB Credential has Failed

On commence à comprendre notre “No data” dans vROPs”

Là ou ça devient intéressant c’est que le username/password utilisé est déjà utilisé dans la console View (dans la partie Configuration d’événements). Côté SQL les logs ne font même pas apparaître un problème d’authentification. Vu que l’association username/password fonctionne via la console view et ne fonctionne pas via l’agent broker, nous avons testé avec un mot de passe moins complexe.

Avec un password sans certains caractères spécifiques ça passe sans problème 🙂

Reste à voir dans le vROps ce que ça donne pour notre problème de “no data” dans le Dashboard “Horizon Adapter Self Health” dans la section “Horizon Broker Agent Event DB Collection Statistics”

Nickel 🙂

Un petit aparté au sujet de SexiGraf, Horizon View devrait faire son apparition dans SexiGraf très prochainement.

c’est dans le pipe on nous dit 🙂

Post to Twitter

Erreur :vSphere HA agent for this host has an error: vSphere HA agent cannot be installed or configured

Suite à une sortie de maintenance de plusieurs ESXi 6.7 (dans un vCenter 6.7) nous avons rencontré les erreurs ci-dessous :

vSphere HA Host status

vSphere HA agent for this host has an error: vSphere HA agent cannot be installed or configured

En faisant un “Reconfigure for vSphere HA” sur un des ESXi, cette fois nous avons eu droit à l’erreur :

The object ‘vim.Datastore:datastore—–‘ has already been deleted or has not been completely created 

Sur ce cluster nous savions qu’il y avait une “migration de datastore” il y a quelques temps, ce qui nous a amené à effectuer les actions ci-dessous afin de résoudre cette problématique :

  • Désactivez HA sur le Cluster (onglet Configure – Edit)
  • Activez HA sur le Cluster (onglet Configure – Edit)
  • Sur le cluster, onglet Configure – Edit – Edit Cluster Setting – Heartbeat Datastore
  • Cliquez sur “Use datastores only from the specified list”
  • Cliquez sur le bouton Ok
  • Allez sur le cluster, onglet Configure – Edit – Edit Cluster Setting – Heartbeat Datastore
  • Cliquez sur “Use datastores from the specified list and complement automatically if needed”
  • Cliquez sur le bouton Ok

Sur l’ESXi faite un « Reconfigure for vSphere HA », l’erreur devrait disparaitre.

Post to Twitter

Horizon View : cacher un/des domaine(s)

Ce que l’on apprécie dans Horizon View c’est la simplicité de mise en oeuvre (nous ferons prochainement un billet dessus), par contre certains détails comme par exemple cacher un domaine en 5x, 6.0x et 7x  (sur la fenêtre d’authentification du client View ou de la console View ) passe par la case ligne de commande uniquement (pourquoi ne pas continuer à faire simple pour un simple paramétrage ….) . La commande permettant de cacher un ou plusieurs domaine(s) est “vdmadmin”, c’est un peu la commande couteau suisse sous Horizon View au passage.

Dans le cas présent le but est de ne présenter qu’un seul domain lors de l’affichage des fenêtres d’ authentification

Ouvrez une console sur un des Connection Server et entrer la commande ci-dessous :

vdmadmin -N -domains -exclude -domain VotreDomain -add

Exécutez la commande autant de fois que vous avez de domains à cacher
Il ne reste plus qu’un seul domain de visible

Si vous souhaitez plus de détails sur les exclusions/inclusions de domain avec la commande vdmadmin :

Post to Twitter

Horizon View 7.10 : Access denied en PowerCli

Toujours dans la série des “problèmes” de permission sous Horizon View 7.10, cette fois-ci c’est via PowerCli qu’on nous a remonté l’erreur ci-dessous.

Access denied, user must have Direct interaction privilege


Afin de permettre les connections via PowerCli à Horizon View, il faut rajouter l’utilisateur (le mieux étant le groupe de l’utilisateur) dans le rôle “Local Administrators (Read only) dans la console Horizon View (dans notre exemple la console Flash).

Post to Twitter

Horizon View 7.10 : Probème d’accès console Flash

Récemment un de nos collègues admin nous a remonté un problème d’accès sur les consoles Flash (Horizon View 7.10). Le message d’erreur “Votre compte n’est pas autorisé à fonctionner via cette console” (“Your account is not allowed to operate through this console”) s’affichait systématiquement lors des tentatives de login via la console Flash, en HTML5 cela passait sans problème.


Sur le Connection Server où l’authentification a eu lieu nous avons constater dans le journal d’events (Application) l’event ID 104 : ADMIN_LOGIN_FAIL 

User login attempt has failed to authenticate to View Administrator with username and password
Attributes:
UserName=username12
ForwardedClientIpAddress=
Node=——–
ClientIpAddress=—–
Severity=AUDIT_FAIL
Time=Thu Aug 20 14:50:37 CEST 2020
Module=Admin
Source=com.vmware.vdi.admin.ui.LoginBean
Acknowledged=true
The specified resource type cannot be found in the image file


Après plusieurs recherches infructueuses (au niveau des groupes AD notamment) nous avons fait des tests au niveau des permissions et avons réalisé qu’en rajoutant le groupe (ou le compte) de notre collègue admin dans  le rôle “Inventory Administrators (Read only)” cela permettait de corriger le problème.

Une fois le groupe rajouté l’accès à la console Flash était de nouveau possible

Post to Twitter

Host hardware system board status

Sur plusieurs Vcenter 6.5/6.7 nous avons rencontré l’erreur “Host hardware system board status” sur des ESXi 6.5/6.7 (UCS-240-M4). En regardant côté CIMC (Cisco Integrated Management Controller) on n’a rien constaté au premier abord (pas d’alerte hardware ou autre). En navigant dans la CIMC dans l’onglet SEL (System Event Log) nous avons constaté que ce dernier était full, en faisant un clear log cela nous a permis de corriger l’alarme “Host hardware system board status”.


Il est aussi possible de faire un clear du SEL via SSH et REST API

En SSH :
Se connecter en SSH sur le serveur puis entrer les commandes ci-dessous :

  • show sel (si vous souhaitez au préalable visualiser le pourcentage d’occupation des log)L’attribut alt de cette image est vide, son nom de fichier est SEL01.png.
  • scope sel
  • clear (le screeenshoot ci-dessous montre le résultat de la commande show après un clear

En Rest API :

  • https://10.10.10.10/redfish/v1/Chassis/1/LogServices/SEL/Actions/LogService.ClearLog


Si vous souhaitez plus d’infos sur les CLI CISCO UCS c’est juste en dessous.

Post to Twitter