Depuis la migration de l’infrastructure VMware en 6.5, nous avions un comportement différent de la 5.5 avec un prompt des credentials utilisateurs en powercli, malgré l’utilisation d’un compte disposant des droits et n’ayant aucun souci pour se connecter au WebClient.

Le premier message d’erreur est un classique : “Could not determine user name and/or password for server”. Puis, avec un argument verbose on obtient : “Connect using SSPI was unsuccessful”.

Plusieurs cas similaires sont référencés sur le forum VMware mais aucune des solutions proposées ne réglaient notre cas. La meilleure solution consistait en un workaround décrit par LucD. Need assistance with creating and then using stored credentials.

Par contre, le post d’aaronwsmith sur le sujet logon sessions in powercli for vsphere appliance 6.5 m’a bien aiguillé.

Dans une configuration avec PSC Externe, même l’appliance VCSA doit être jointe au domaine et comme il l’indique, l’option n’est pas forcement disponible depuis le WebClient.

Pour ma part, les comptes ordinateurs étaient bien présent dans notre AD, mais en exécutant la commande “/opt/likewise/bin/domainjoin-cli query”  le retour ne faisait pas apparaitre le chemin complet avec l’OU qui était censée héberger le compte machine.

Impossible de joindre la machine au domaine. Le compte ordinateur est encore présent dans l’AD et, j’obtiens une erreur LW_ERROR_LDAP_INSUFFICIENT_ACCESS (code 0x00009d8b]

Impossible également de supprimer le compte ordinateur avec la commande “/opt/likewise/bin/domainjoin-cli leave“, malgré le succès de l’opération.

Il faut donc supprimer directement le compte ordinateur depuis l’AD, attendre quelques instants que la réplication se propage, puis exécuter la ligne de commande pour l’ajouter.

/opt/likewise/bin/domainjoin-cli join domain.com Domain_Administrator Password

Voici la syntaxe que j’utilise pour ajouter directement dans la bonne OU :

/opt/likewise/bin/domainjoin-cli join –ou “CHEMIN/OU”domain.com” “CompteAutorisé@domain.com” “Password‘”

Si tout se passe bien, vous devriez avoir un succès, et le compte ordinateur devrait être visible dans l’OU de destination.

Sur nos infrastructures, il faut bien attendre 30 secondes pour que la commande fonctionne.

Ci-dessous le “avant/ après”. L’authentification est de nouveau transparente.

A la suite d’une mise à jour de l’infra 6.5 vers 6.5 u1, impossible de me reconnecter au vCenter, le client web indique :

503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http20NamedPipeServiceSpecE:0x00007f4b700dc900] _serverNamespace = / action = Allow _pipeName =/var/run/vmware/vpxd-webserver-pipe)

Ce message est assez générique et indique que des services ne sont pas disponibles, j’ai donc suivi la kb vmware 2121043 concernant le problème : “503 service unavailable” error when connecting to vSphere Web Client

Dans mon cas, ce n’était pas le service vSphere Client mais le vpxd qui ne démarrait pas, donc je décide de chercher un peu dans les logs de ce service :

 more /var/log/vmware/vpxd/vpxd.log | grep error 

Je constate qu’il fait beaucoup de tentatives, mais qu’il n’arrive pas à se connecter.

info vpxd[7FD876796800] [Originator@6876 sub=AuthzStorageProvider] [AuthzStorageProvider::CreateAuthzMgr] Retry for this error: attempt count 17
error vpxd[7FD876796800] [Originator@6876 sub=httpUtil] [HttpUtil::ExecuteRequest] Error in sending request - Connection refused
error vpxd[7FD876796800] [Originator@6876 sub=ServerAccess] Remote login failed: N3Vim5Fault9HttpFault9ExceptionE(vim.fault.HttpFault)
error vpxd[7FD876796800] [Originator@6876 sub=AuthzStorageProvider] [AuthzStorageProvider::CreateAuthzMgr] Failed to connect to IS: <N5Vmomi5Fault17HostCommunication9ExceptionE(vmodl.fault.HostCommunication)

Avec ces messages, je tombe rapidement sur une autre KB: VCenter Server fails to start with “Remote login failed:N3Vim5Fault9HttpFault9ExceptionE(vim.fault.HttpFault)”, After vCenter Server is restored from backup or snapshot (2149010) Il est bien question de perte de mot de passe du compte machine, mais dans un contexte de restauration ou retour arrière sur snapshot.

La résolution consiste à redonner le mot de passe Administrator en shell pour réinitialiser le passe du compte machine, ce qui n’est pas très lourd donc je tente l’opération même si elle ne correspond pas exactement à ma situation.

vcenter-restore -u administrator -p administrator@vsphere.local password
root@localhost [ /var/log/vmware/vpxd ]# service-control --status --all
Running:
applmgmt lwsmd vmafdd vmonapi vmware-cm vmware-content-library vmware-eam vmware-perfcharts vmware-rhttpproxy vmware-sca vmware-sps vmware-statsmonitor vmware-updatemgr vmware-vapi-endpoint vmware-vmon vmware-vpostgres vmware-vpx d vmware-vpxd-svcs vmware-vsan-health vmware-vsm vsphere-client vsphere-ui
Stopped:
vmcam vmware-imagebuilder vmware-mbcs vmware-netdumper vmware-rbd-watchdog vmware-vcha

Et voilà, le vxpd de nouveau sur les rails, je n’ai pas encore exactement compris comment le mot de passe n’avait pas pu être transmis, peut-être la modification du compte sur le PSC à eu lieu pendant la mise à jour.

Le vCenter Appliance est vraiment une très bonne idée de la part de VMware, qui demande par contre un petit temps d’adaptation pour la résolution des problèmes après toutes ces années passées sur un vCenter Windows.

Nous avons eu besoin d’un nouveau rôle pour nos ROBO afin de leur permettre d’éteindre les ESXi sur site.

J’ai créé un rôle personnalisé Shutdown host pour cette opération avec les privilèges suivants :

Global > Log event

Host > Configuration > Maintenance

Pourquoi faire un post la dessus me direz-vous ? tout simplement parce-qu’en fonçant tête baissé dans les permissions, j’étais plus tenté de configurer :

“Host > Configuration maintenance + power” mais ce n’est pas la bonne configuration.

Un admin de la platforme VMware m’a remonté un problème de connexion au vCenter, je n’arrivais pas à reproduire le problème mais une rapide recherche sur internet la KB VMware : “vSphere Client will time out before authentication to ESXi is complete (2072539)” nous donnait une explication :

Dans notre cas, c’est le nombre trop important de groupe dont l’utilisateur est membre mais le timeout est personnalisable depuis la clé de registre :

HKCU\Software\VMware\VMware Infrastructure Client\Preferences\CLIENT_CMD_TIMEOUT

 Alors que je me faisais une joie d’avoir un client vSphere “supporté” en HTML5, quelle ne fut pas ma surprise à la connexion sur le VCSA (vCenter Server Appliance) fraîchement upgradé:

Oui, vous avez bien vu, il y a toujours 2 clients, un avec Flash et l’autre en HTML5 mais avec des fonctionnalités partielles.

Je ne m’attendais pas à ça, mais VMware a simplement pris le fling du client HTML5 et collé un tampon supporté dessus !

Pour rappel, les flings sont des outils mis à disposition en mode laboratoire expérimental, ils ne devraient pas être utilisés en production au dire même de VMware, mais c’est une source d’outils très pratiques et communément utilisés par beaucoup d’Admin. Vous pouvez explorer cette caisse à outils ici : Labs VMware Flings

Du coup, j’ai fait quelques recherches sur les différences entre les deux clients, la liste est un peu longue, elle se trouve ici : vSphere 6.5 HTML 5 functionnality support.

Des mises à jour régulières sont promises et elles seront poussées d’abord sur le fling qui lui reste bien sr non supporté…

 

A noter la convention de nommage, le “vSphere Web Client” correspond au client Flash et le “vSphere Client” le HTML5.

 

Lien vers le fling du client html5 à réserver pour vos labs : vsphere-html5-web-client.