Auteur/autrice : Ludovic Page 1 of 12

Lors du déploiement d’un Horizon Edge Gateway avec l’OVA horizon-edge-gw-2506.1.0.ova, nous avons rencontré un incident bloquant lors de la phase d’installation automatique du Edge Gateway.

Comme dans beaucoup d’environnements d’entreprise, le déploiement se fait derrière un proxy HTTP.
Lors de l’assistant de configuration, les paramètres proxy ont été renseignés comme suit :

• Adresse du proxy
• Port
• Proxy SSL : False (car HTTP simple)

Une fois le déploiement lancé, Edge Gateway démarre son processus d’installation… mais celui-ci n’aboutit pas.
Une vérification via la commande :

kubectl get pods -A

montre qu’un des conteneurs reste bloqué en état ImagePullBackOff, indiquant une impossibilité de télécharger l’image requise.

L’exécution du script de diagnostic :

/opt/horizon/bin/diagnostic.sh

confirme que certaines URL nécessaires au déploiement sont inaccessibles depuis l’appliance.

Après investigation, la cause a été identifiée du côté de la configuration Docker générée automatiquement pendant le déploiement.

En effet, le fichier suivant contient les paramètres de proxy utilisés par Docker :

cat /etc/systemd/system/docker.service.d/http-proxy.conf

Problème : bien que le déploiement ait été configuré avec un proxy HTTP, la configuration inscrite pour Docker utilise https dans les variables d’environnement, provoquant ainsi une tentative de passage par un proxy HTTPS… inexistant dans notre cas.

Résultat : Docker ne parvient pas à télécharger les images nécessaire (ImagePullBackOff.)

Solution appliquée

1. Édition du fichier de configuration Docker

En tant qu’utilisateur root, éditer le fichier suivant :

vi /etc/systemd/system/docker.service.d/http-proxy.conf

Puis remplacer toutes les occurrences de https par http dans les adresses de proxy.

2. Rechargement et redémarrage du service Docker

systemctl daemon-reload
systemctl restart docker

3. Relancer le déploiement du conteneur en échec

kubectl -n edge-namespace rollout restart deployment edgedevice-deployment

4. Vérifier le bon redéploiement

Surveiller la progression des pods :

watch kubectl get pods -A

Une fois les statuts Running, le déploiement est de nouveau fonctionnel.

Merci à JusteGeek qui à trouvé la solution et m'a fait un résumé pour écrire cet article !

Depuis la version Horizon 2412 il est possible de configurer un port personnalisé pour la console d'administration Horizon.

Pour changer la configuration, il faut ajouter une variable dans le fichier locked.properties sur chaque Connection Server.

Ce fichier se trouve dans le dossier C:\Program Files\Omnissa\Horizon\Server\sslgateway\conf du Connection Server. Si celui-ci n'existe pas, il est nécessaire de le créer.

Ajouter la variable suivante :
serverPortAdmin=10443

Il est possible de choisir un autre port.
Attention, ces variables sont sensibles à la casse.

Enregistrer le fichier et redémarrer le service Omnissa Horizon Connection Server pour appliquer les changements.

Voici une liste des principaux composants à vérifier avant d'upgrader Omnissa Horizon afin de s'assurer de la compatibilité de l'ensemble de la solution.

La page d'authentification de la console d'administration Omnissa Horizon (/admin) est, par défaut, accessible à tous le monde.
En modifiant la configuration du serveur Tomcat, il est possible de restreindre l'accès à certains subnets IP afin de renforcer la sécurité.
Cette opération est documentée chez Apache Tomcat mais pas chez Omnissa, donc non officiellement supportée.

Configuration

Sur les Connection Servers, éditer le fichier web.xml situé dans le répertoire :
C:\Program Files\VMware\VMware View\Server\broker\webapps\admin\WEB-INF

Dans l'exemple ci-dessous, nous allons autoriser uniquement les accès depuis localhost (le Connection Server) et le sous-réseau 192.168.1.0/24.
Ajouter le code suivant :

<filter>
      <filter-name>Remote CIDR Filter</filter-name>
      <filter-class>org.apache.catalina.filters.RemoteCIDRFilter</filter-class>
      <init-param>
      <param-name>allow</param-name>
      <param-value>127.0.0.0/8,192.168.1.0/24</param-value>
      </init-param>
      </filter>
      <filter-mapping>
      <filter-name>Remote CIDR Filter</filter-name>
      <url-pattern>/*</url-pattern>
</filter-mapping>

Enregistrer le fichier, le filtre sera automatiquement actif au bout de quelques secondes.

---

Les autres solutions possibles pour restreindre les accès sont :
- Mise en oeuvre d'une UAG interne
- Firewall Layer 7
- Mettre à jour en version Horizon 2412

Savez-vous qu'il est possible d'afficher le nombre d'images par seconde (FPS) et l'encodeur utilisé en surimpression du client Horizon ?

Pour configurer cette fonctionnalité, il faut se rendre sur un poste utilisateur où est installé leClient Horizon puis éditer ou créer un fichier settings.ini dans le dossier suivant :
C:\ProgramData\Omnissa\Horizon\Omnissa Horizon Client

Ajouter ensuite les deux lignes suivantes :

viewClient.drawFPS=TRUE
RemoteDisplay.enableDecoderWatermark=TRUE

Dans l'exemple ci-dessous, nous pouvons voir que le nombre de FPS est égal à 15 et l'abréviation BC SW pour BlastCodec (SoftWare Encoder)

Depuis quand cette fonctionnalité existe-t-elle ? 😮

VMware Horizon permet de se connecter à des postes de travail virtuels et applications à distance. Il est possible de simplifier l'accès (depuis un intranet ou un ENT par exemple) en configurant des liens web directs qui lancent automatiquement le client Horizon et connectent l’utilisateur à une machine virtuelle spécifique ou à un groupe d’applications. 

Configuration d'URL personnalisées pour Horizon Client

Le client VMware Horizon prend en charge des URL personnalisées permettant de se connecter à un environnement Horizon spécifique via un lien. Les administrateurs peuvent configurer ces liens en utilisant des URL structurées de manière spécifique. Une URL typique suit cette structure :

vmware-view://<serveur>?desktopId=<ID_poste>&domain=<nom_domaine>

vmware-view:// : Protocole utilisé par Horizon Client pour interpréter la demande.
<serveur> : Adresse du serveur de connexion Horizon.
desktopId : ID de l'application ou du poste de travail auquel l’utilisateur se connectera.
domain : Domaine auquel l'utilisateur doit être authentifié.

Exemple d'URL

vmware-view://horizon.lab.local?desktopId=Pool01&domain=LAB

Pour évaluer le ROI (retour sur investissement) d’une solution de virtualisation de poste de travail, il faut examiner plusieurs paramètres clés qui couvrent les coûts, les gains d’efficacité et les bénéfices à long terme. Voici les principaux critères à prendre en compte.

Coûts initiaux et opérationnels

Coût de licence : Investissement dans les licences de la solution de virtualisation les licences des logiciels virtualisés et le solution de management des clients.

• Coût du matériel : Serveurs, stockage, GPU, réseau et clients légers nécessaires pour héberger et déployer les applications / postes de travail.

• Coût de mise en œuvre : Dépenses liées à l’installation, à la configuration et au déploiement.

• Coût de maintenance : Frais récurrents pour la gestion, les mises à jour et la maintenance des postes de travail et de l’infrastructure.

Réduction des coûts IT

• Consolidation du matériel : Réduction du nombre de postes de travail et d’appareils individuels nécessaires.

• Maintenance centralisée : Gain de temps pour le support IT, qui peut gérer les poste de travail depuis un emplacement centralisé.

• Durée de vie prolongée des appareils : Les anciens appareils peuvent être utilisés plus longtemps puisqu’ils ne nécessitent plus de puissance de calcul locale élevée.

Gain de productivité et flexibilité

• Accès à distance : Les utilisateurs peuvent accéder aux postes de travail virtualisés depuis n’importe quel appareil, facilitant le télétravail.

• Disponibilité accrue : Les postes de travail sont accessibles en permanence, ce qui limite les temps d’arrêt et les pertes de productivité.

• Déploiement plus rapide : Les mises à jour ou les nouvelles applications peuvent être déployées instantanément sur tous les postes.

Amélioration de la sécurité et de la conformité

• Sécurité centralisée : Les données et applications restent dans le datacenter, réduisant les risques de pertes ou de vols d’informations.

• Contrôle des accès : Gestion simplifiée des accès utilisateurs, avec des niveaux de sécurité élevés.

• Conformité : Capacité à se conformer plus facilement aux réglementations en matière de gestion de données.

Économies d’énergie et impact environnemental

• Réduction de la consommation énergétique : Moins de matériel physique et de consommation électrique sur les postes utilisateurs.

• Impact environnemental : Contribution à des initiatives de développement durable avec moins de matériel et une durée de vie prolongée des terminaux.

Évolutivité et agilité

• Adaptabilité aux besoins futurs : Possibilité de faire évoluer rapidement l’infrastructure pour répondre aux besoins changeants de l’entreprise.

• Flexibilité pour les nouveaux utilisateurs : Facilité d’intégrer de nouveaux utilisateurs ou d’étendre la capacité en fonction des demandes.

Impact financier global (TCO et ROI)

• TCO (coût total de possession) : Comparer le coût total de la solution de virtualisation avec l’infrastructure traditionnelle pour évaluer l’investissement global.

• Délai de récupération : Estimer le temps nécessaire pour que les économies et les bénéfices compensent les coûts initiaux et opérationnels.

• Retour sur investissement global : Quantifier les gains financiers grâce aux économies et à la productivité accrue par rapport aux coûts investis.

Ces paramètres permettent de construire une analyse complète du ROI, en intégrant à la fois les coûts directs et indirects ainsi que les bénéfices tangibles et intangibles.