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.
Avec un titre comme ça il faut qu’on vous plante le décor au préalable ; nous avons un cluster de deux hosts dont un est en maintenance, les deux serveurs d’admin (RDSH) qui sont hébergés sur l’autre host commence à être chargés, sur un de nos serveur d’administration nous avions déjà une session en mode déconnecté depuis une vingtaine heures environ. La reconnection à notre session s’est faite sans problème (une chance car l’autre serveur refuse toute connexion) cependant lorsque nous avons essayé de lancer une connection distante (SSH) via PuTTY nous avons rencontré l’erreur ci-dessous :
Network error : No buffer space available
Notre premier bug PuTTY 🙂
Dans le journal system nous avons trouvé l’Event ID 4227 qui visiblement a un lien direct avec notre problème.
TCP/IP failed to establish an outgoing connection because the selected local endpoint was recently used to connect to the same remote endpoint. This error typically occurs when outgoing connections are opened and closed at a high rate, causing all available local ports to be used and forcing TCP/IP to reuse a local port for an outgoing connection. To minimize the risk of data corruption, the TCP/IP standard requires a minimum time period to elapse between successive connections from a given local endpoint to a given remote endpoint.
Outre le problème rencontré avec PuTTY, nous ne pouvons plus “sortir” du serveur, que ce soit via l’accès à un partage distant, un telnet, un rdp, AD etc.. etc….. . Un google plus loin nous comprenons qu’il se pourrait que notre serveur ait un problème de port dynamique (AKA “Ephemeral Port“). Afin d’afficher la liste et l’état des connexions (ce qui nous intéresses ce sont les connexions en TIME_WAIT) sur notre serveur nous avons utilisé la cmdlet “Get-NetTCPConnection” comme ci-dessous :
Get-NetTCPConnection -state timewait
Nous avons constaté un nombre conséquent (environ 200) de connexions en TIME_WAIT (malheureusement nous n’avons pas eu le temps de faire un screenshot, juste le temps de noter les PID coupables, et comme c’est de la prod on ne kill pas les PID sans savoir), on comprend mieux pourquoi PuTTY ne trouve pas un port dynamique de libre. Afin de connaître la plage des ports dynamiques il faut lancer la commande ci-dessous :
netsh int ipv4 show dynamicport tcp
Notre server a une une plage par défaut pour un Windows 2019
La solution de facilité serait de rebooter le serveur (mais nous avons toujours des utilisateurs connectés sur le serveur), nous optons pour agrandir la plage des ports dynamiques (sans redémarrer le serveur) . Afin d’agrandir la plage des ports dynamiques et réduire le temps de libération d’un port qui passe en TIME_WAIT de quatre minutes (valeur par défaut) à 30 secondes nous avons passé les clés de registre ci-dessous (qu’on expliquera plus bas) via une console PowerShell.
Nous relançons un “netsh int ipv4 show dynamicport tcp” afin de vérifier que la plage des ports dynamique a bien été agrandie.
Notre plage est désormais agrandie
On teste si PuTTY se lance bien avec la plage des ports dynamiques agrandie.
Nickel (ça passe sans reboot)
Quelques explications sur les trois clés passées plus haut.
MaxUserPort : Permet de fixer la plage des ports dynamiques, par défaut la plage sur Windows 2019 commence à 49152 et se termine à 65535
TcpTimedWaitDelay : détermine la durée pendant laquelle une connexion TCP reste dans l’état TIME_WAIT (ou 2MSL) lorsqu’elle est fermée. La valeur par défaut d’un TIME_WAIT est de 240 secondes (4 mn) soit 120 secondes pour MSL qu’on double pour avoir deux MSL (2MSL).
TcpNumConnections : nombre de connexions TCP ouvertes simultanées
Un peu de littérature autour des ports dynamiques :
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.
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”
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.
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 :
Juste un petit warning, si vous faîtes un update d’un infra Horizon View (dans notre cas 7.1 vers 7.10 avec des replica server) n’oubliez pas d’ouvrir le port TCP 32111 entre vos Connection Server et les Réplica. Si vous lisez la la KB1027217, notamment la section “TCP Ports for View Connection Server and Replica Server Instances” vous remarquez l’absence du port TCP 32111.
Donc pas besoin du port TCP 32111 ? 🙂
Par contre si on lit la KB1027217 jusqu’au bout (notamment les notes en bas de la KB ) on tombe sur :
In Horizon 7.2 and later, TCP 32111 is required between Connection Servers in a replica group
On avait remonté ça à VMware il y a quelques mois.. mais ils préfèrent les KB type “Escape Game” 🙂
Si vous souhaitez modifier votre mot de passe dans une session RDP imbriquée elle-même dans d’autres sessions RDP, sans passer par l’utilisation du “ctrl-alt-del” (ou plutôt ctrl-alt-end dans une session RDP) ou de l’OSK (aka On-Screen Keyboard) alors il y a un moyen sympa et rapide : PowerShell.
Dans une console PowerShell lancez la commande ci-dessous.
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).
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
