Problème avec View 3.1.1.

[jprottiers]

Bonjour à tous,

Nouveau sur ce forum, je viens d'abord par nécessité Mais j'espère pouvoir rendre l'appareil d'ici quelques temps!

Nous avons effectué un POC avec View 3.1.1 et celui-ci s'est plutôt bien déroulé. Nous en sommes à présent dans la phase de déploiement et, malheur!, un problème plutôt génant et récurrent (mais pas permanent, bien sûr) se produit: (non-persistent pool)

- L'utilisateur se connecte via le View Client ou le client VDM du V10L de Wyse au serveur view (en fait, il se connecte à une appliance qui fait du load balancing entre 2 brokers).
- Le Single-Sign-On se fait correctement au niveau de la VM (XP Pro SP3) mais, parfois, l'utilisateur reste bloqué au logon screen (celui-ci semble figé). Après plusieurs minutes, le logon screen disparait enfin mais l'utilisateur se retrouve avec le bel écran bleu (je parle du fond d'écran, pas du BSOD) de Windows et plus rien ne se passe.

L'identification n'ayant pas été jusqu'au bout, nous ne pouvons pas voir sur quel VM l'utilisateur essayait de se connecter dans le View Administrator. Néanmoins, nous avons pu repérer une fois ou l'autre les VM incriminées et nous avons donc pu tenter de nous logger sur celles-ci via l'Infrastructure Client. Que se passe-t-il dans ce cas là?

- Si l'on s'identifie suffisement vite, on reçoit le message d'erreur suivant de la part de Windows (dans la session VM): l'opération demandée ne peut pas se terminer car la connexion Terminal traite une opération de connexion.

- Si l'on tente de s'identifier à nouveau après une ou deux minutes: l'écran devient noir, après quelques minutes il devient bleu (le fond d'écran de Windows, me semble-t-il) et ensuite la VM ne répond plus. Elle ne répond plus au point que, après un certain temps, si vous tentez de migrer celle-ci vers un autre ESX, vous obtenez un warning car "the guest operating system has no hearbeat"!

Les autres VM qui tournent sur le même host ESX ne sont pas affectées. Les VM "serveurs" ne sont pas affectées et ne l'ont jamais été.

Nous ne trouvons pas de littérature sur ce sujet; serions-nous les seuls à avoir ce problème? :-/

Quoi qu'il en soit, toute idée, piste ou autre information venant de personnes telles que vous seraient les bienvenues!

Merci d'avance!

Jean-Philippe.

Notre configuration:

7 hosts ESX 3.5.0,176894
2 serveurs View 3.1.1
1 load balancer pour les 2 serveurs View

Les VMWare Tools et l'agent View sont bien installés dans toutes les VM.

Le client View est aussi en 3.1.1 sur nos PC, les thin clients Wyse V10L tournent avec le dernier firmware/WTOS 6.4.0_18.

[emonjoin]

As tu ouvert un incident au support ?

Sinon :
Essaye dans un premier temps de couper le loadbalancer si c'est possible.
Les VM XP ont elles étaient installées from scratch ou migrées ?
Regarde les logs View dans les VM et le connexion broker

Vue que tu utilise des V10L tu es donc un connexion direct et non pas en mode tunnel ce qui normalement t'assure les meilleurs performances.
Autrement j'ai pas eu vent de problème identique ailleurs.

L'identification n'ayant pas été jusqu'au bout, nous ne pouvons pas voir sur quel VM l'utilisateur essayait de se connecter dans le View Administrator. Néanmoins, nous avons pu repérer une fois ou l'autre les VM incriminées et nous avons donc pu tenter de nous logger sur celles-ci via l'Infrastructure Client. Que se passe-t-il dans ce cas là?

Rien à part que la sessions RDP est coupé au profit du logon local

[Olivier]

As-tu ouvert un SR chez VMware au moins ????
Que disent tes logs ?

[jprottiers]

Bonsoir,

Olivier et emonjoin, merci pour ces premières réponses J'ai bien entendu ouvert un SR chez VMWare mais le "sympathique" irlandais qui m'assiste semble quelque peu paresseux... C'est pourquoi j'explore la piste de ce forum comme moyen de recherche additionnel

Les VM XP sont "from scratch" et j'ai aussi réalisé un pool basé sur un Windows XP Pro SP3 "vierge" (si ce n'est que toutes les mises à jour sont installées) + VMWare Tools + View Agent, bien entendu. Le but étant d'avoir le système le plus basique possible afin d'effectuer le debugging.

Au niveau des logs, lorsque l'on génère ceux-ci, il y en a beaucoup et de plusieurs types. Le ou lesquels me conseillez-vous de regarder avec attention? Le log VDM n'indique pas grand chose. Dans un cas d'utilisation normal (= quand tout se passe bien), on peut voir 2 lignes relatives au logon, et ensuite d'autres lignes relatives, entre autres, au vdm framework. Lorsque le phénomène se produit, le log VDM n'indique que les deux lignes relatives au logon, rien ne semble se passer ensuite.

En effet, le V10L se connecte de manière directe aux VMs, le broker ne faisant à peu de choses prêt que fournir au client l'IP à laquelle il doit se connecter. Je n'ai pas non plus trouvé d'autres personnes indiquant avoir vécu ou entendu parler d'un tel problème.

Ce soir, j'ai vérifié la version des différents logiciels (View Server, View Agent, View Composer) et ils sont bien tous relatifs à View 3.1.1. Ce qu'on me propose chez VMWare, c'est de supprimer l'agent d'une des VM et de faire des connexions RDP directes vers celle-ci afin de voir si je peux reproduire le problème. Je vais essayer, même si je trouve ça un peu léger.

D'autre part, j'ai updaté un des hosts ESX avec les dernières mises à jour (et isolé celui-ci du DRS afin qu'aucune VM ne s'y retrouve), je créerai ce week-end un pool qui tournera spécifiquement sur ce host, afin d'utiliser les derniers VMWare tools (les mises à jour ESX de juillet/août introduisent, semble-t-il, une nouvelle version de ces tools).

J'ai aussi vérifié en SSH (free -m) la RAM et la SWAP de l'ESX où une VM (de View, bien entendu) avait "planté" et tout semble normal de ce côté-là.

Voilà pour les compléments d'information...

Merci d'avance pour vos idées et commentaires... J'avoue que, tout doucement, je commence à manquer d'idées... :-/

Bon week-end!

Jean-Philippe.

[emonjoin]

Ton problème tu le rencontre aussi bien avec le client View 3.1.1 que sur les Wyse ?

[jprottiers]

Oui, c'est pareil avec le View Client 3.1.1!

[Olivier]

Si tu te connectes directement vi vCenter sur la VM à priori plantée ça donne quoi ?

[jprottiers]

Tu veux dire via l'infrastructure client (en gros, en remote console donc)?

Si oui:

Néanmoins, nous avons pu repérer une fois ou l'autre les VM incriminées et nous avons donc pu tenter de nous logger sur celles-ci via l'Infrastructure Client. Que se passe-t-il dans ce cas là?

- Si l'on s'identifie suffisement vite, on reçoit le message d'erreur suivant de la part de Windows (dans la session VM): l'opération demandée ne peut pas se terminer car la connexion Terminal traite une opération de connexion.

- Si l'on tente de s'identifier à nouveau après une ou deux minutes: l'écran devient noir, après quelques minutes il devient bleu (le fond d'écran de Windows, me semble-t-il) et ensuite la VM ne répond plus. Elle ne répond plus au point que, après un certain temps, si vous tentez de migrer celle-ci vers un autre ESX, vous obtenez un warning car "the guest operating system has no hearbeat"!

[emonjoin]

Sinon essaye toujours d'upgrader en 3.1.2 pour voir ce que ca donne, au moins les agents et si possible le client puis tu pourras toujours passer le connection broker (avantage, tu l'aura même en français). Pour le Wyse il y a une version .20 qui existe et qui visiblement corrige des problèmes avec View.

Mais vus que tu passe en direct je doute d'un problème dus à View ou alors c'est les agents.

[jprottiers]

Je retourne au bureau demain pour faire quelques tests supplémentaires, je vous tiens au courant

PS: tu es sûr que l'on peut installer le dernier agent View même si le broker n'est pas lui aussi mis à jour?

[emonjoin]

oui sans problème

[Julien]

Je confirme ma prod. fonctionne dans cette configuration sur quelques machines

[Olivier]

Je suis dans le même cas que Julien.

[jprottiers]

Voilà, je viens d'effectuer des tests supplémentaires avec:

- Un host ESX mis à jour avec les dernières updates.
- Toutes les VM de mon pool de test ont été migrées sur ce host et dispose des derniers VMWare Tools et du dernier View Agent 3.1.2 (comme vous me l'avez proposé).
- En plus de cela, nous avons vérifié que les services qui devraient être disablés (comme recommandé dans plusieurs notes VMWare) l'étaient bien. Entre autres, nous avons désactivé le service des thèmes, le service d'indexing, ainsi que désactivé les options appropriées dans les paramètres de gestion de l'énergie. La restauration système a aussi été désactivée.

Dans ces conditions, nous n'avons plus eu le phénomène que je vous avais décrit. Une victoire? Oui et non car un nouveau problème est venu frappé à notre porte Après un certain temps, les connexions deviennent parfois impossibles à partir du V10L ("Connection Failed") mais aussi à partir du View Client; et là le message est plus explicite, en gros le message dit qu'il n'y a plus de desktop disponible car ils sont tous occupés. Cependant, le View Administrator montre bien que la plupart des desktops sont disponibles (statut "ready"), de plus une connexion RDP directe fonctionne. En clair, il semblerait que le View Server "pense" qu'elles sont occupées alors qu'elles ne le sont pas. Nous avons pu reproduire ce même phénomène à plusieurs reprises, y compris avec le View Agent 3.1.1.

Auriez-vous une idée?

Merci d'avance

Jean-Philippe.

[jprottiers]

Petit complément d'info:

Parfois, on se retrouve sur un desktop (et donc une VM) et Windows nous dit qu'il y a déjà un utilisateur connecté. C'est assez étrange puisque View n'aurait pas du nous attribuer cette VM. Ce problème pourrait peut-être lié à l'autre phénomène où il n'y a "plus de desktop disponibles" que je viens de vous expliquer dans mon précédent post.

Voilà voilà... Bonne soirée à tous, et merci pour vos suggestions!