0

Horizon 7.10 error : warning Echec de la connexion

Suite à la migration d’un environnement Horizon view 7.3 vers 7.10, on nous a remonté une erreur de connexion à la console d’administration HTML5 avec les navigateurs Chrome (79.0.3945.117 – Build officiel – 32 bits ) et Firefox (72.0.1 – 32 bits).

 

Le problème se produit uniquement avec Chrome et Firefox… qui a dit que Internet Explorer était un mauvais navigateur 🙂 .

 

Ce problème de connection peut-être résolu en modificant le fichier “locked.properties” (dans le cadre d’un problème d’affichage HTML5 via le navigateur Edge et en passant par des F5 nous avions deja eu l’occasion de jouer avec le fichier “locked.properties”). Revennons à nos moutons, la KB2144768 chez VMware nous donne la liste des actions à réaliser afin résoudre ce problème de connexion.

  1. Créer le fichier C:\Program Files\VMware\VMware View\Server\sslgateway\conf\ locked.properties
  2. Ajouter la ligne : checkOrigin=false
  3. Redémarrer le service « Composant VMware Horizon View Security Gateway” (wstunnel)

 

Voila ça c’est fait (il nous reste encore quelques bugs qui feront l’objet d’autres posts 🙂 )
0

vCenter error : interface com.vmware.vim.binding.integrity.VcIntegrity is not visible from class loader

Sur un vCenter 6.5 Version 6.5.0.10000 Build 5973321 nous avons rencontré l’erreur ci-dessous dans l’onglet “Update manager – Attacher une ligne de base”

 

interface com.vmware.vim.binding.integrity.VcIntegrity is not visible from class loader

 

Mais comme on est pressé et que VMware fait bien les choses la KB 60640 répond pile-poil à notre problème

  • Allez en SSH sur le vCenter
  • Lancez la commande service-control –stop –all
  • Lancez la commande service-control –start –all

 

Nickel ça nous a pris 10 mn 🙂
Tags:
0

Horizon View 7.8 : vmware view error during provisioning initial publish failed fault type is VC_FAULT_FATAL

Lors de l’intégration d’un serveur composer dans une infra  Horizon View 7.8 on nous a remonté l’erreur ci-dessous lors du déploiement de machines au sein d’un pool de postes de travail en “Automated, instant clone, floating”.

 

vmware view error during provisioning initial publish failed fault type is VC_FAULT_FATAL

 

Au départ nous pensions à un problème de permissions sur le Vcenter, mais en regardant de plus près sur la configuration du vCenter/Composer dans la console “Horizon 7 Administrator” nous avons constaté que le vCenter était configuré avec un compte local

 

Et si on configurait l’accès au vCenter avec un compte de service du domaine 🙂

 

Une fois le compte local remplacé par un compte de service du domaine (avec les permissions adéquates) le déploiement de machines a pu se faire sans problème.

 

Nous avons mis le même compte de service pour le vCenter et le Composer 😉
0

VIP injoignable sur NetScaler VPX

Sur des NetScaler VPX (11.0.71.18 qu’il faudra mettre à jour ASAP) nous avons créé des VIPs qui étaient pingables mais injoignables sur les ports sur lesquels elles étaient configurées (dans le cas présent TCP 443 et TCP 8085).

En regardant du côté firewall (ASA) nos collègues du réseau ont remarqué des time-out et drop.

01/09 07:37:35 <182>Sep 02 2019 20:37:17: %ASA-6-106015: Deny TCP (no connection) from xx.xxx.xx.xxx/80 to xx.xxx.xx.xxx/59968 flags SYN ACK  on interface cag_VIP978


En googlelant nous sommes tombés sur la CTX205292 extrêmement intérressante, en effet activant le MBF sur les Netscaler, les VIPs étaient joignables sans problème.

Pour activer le MBF il faut se connecter en SSH sur le Netscaler et lancer la commande ci-dessous. 

enable ns mode mbf


Le problème dans notre cas était bien un problème de routage asymétrique et pas question de toucher à la conf des firewall, donc on a activé le mode MDF sur les Netscaler.

Tags:
0

vSAN : Rechercher un disque

La lecture du titre de ce post vous laisse dubitatif avouez le 🙂 .

Dernièrement nous avons dù identifier physiquemebt un disque (au sein d’un disque group) qui rencontrait de grosses latences (entre 15000 ms et 45000 ms), un remplacement rapide s’imposait donc.

Le problème est que nous avons pu identifier le disque au sein du disque groupe via son naa, mais comment l’identifier physiquement sur l’ESXi (serveur CISCO UCS-C240-M4SX) ? Dans UCS Central aucune alarme ne remontait côté disque (normal il n’y a pas de problème hardware vous nous direz) et en ESXCLI on ne remonte pas d’informations de type PID permettant de faire le lien entre le naa. et le disque dans UCS. Dans le Vcenter, sur l’ESXi dans l’onglet “Configure” –  “Storage-Storage Device” vous avez un bouton qui permet (logiquement) d’allumer la led d’un disque  selectionné (le fameux “turn on ou turn off disk locator”), mais dans notre cas cela ne fonctionnait pas. 

On a beau cliquez ça reste vert 🙁 .

En googlelant nous sommes tombés sur la commande ci-dessous qui permet d’allumer (ou clignoter) la led d’un disque.

esxcli storage core device set -d naa.50000397885347bd -l=locator -L=600

Après avoir trouver une âme charitable dans le Datacenter, le collègue a pu nous donner la position du disque dans le serveur en vue de son prochain remplacement.

Tags: , , ,