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.

Une des rares opérations pas vraiment transparente lorsque l’on administre des noeuds Nutanix avec ESXi comme hyperviseur concerne la mise en maintenance.

Comme vous le savez la CVM est liée au stockage local de l’hôte et ne sera pas déplacé par un vMotion pour la mise en maintenance, il faut donc l’eteindre.

Oui mais comment ? Pendant longtemps je pensais à tort qu’un “Shut Down Guest OS” était suffisant, qu’un hook avait été mis en place dans la CVM pour intercepter ce type d’ordre et proceder proprement à l’extinction. (Et en discutant autour de moi, je n’étais pas le seul à penser ça)

Sur les conseils d’un contact Nutan, j’ai ouvert un ticket au support pour en avoir le coeur net et il n’en ai rien, la seule méthode supportée consiste à se connecter à la CVM et executer la commande :

cvm_shutdown -P now

qui permet de réellement prévenir les autres noeuds du cluster que la CVM n’est plus disponible et ce point n’est pas présent via VMware.

Je vous met en lien les références Nutanix :

Shutting Down a Node in a Cluster (vSphere Web Client)

et aussi

Shutting down all nodes in a cluster for maintenance or relocation

 

Ce n’est évidemment pas l’idéal, mais voici une petite procédure pour copier une VDI et continuer de la gérer dans Xendesktop, le tout hebergé sur VMware.

1. Récupérer l’UUID de la machine d’origine :
$OldUUID =(get-vm OldVM).extensiondata.config.uuid

2. Création de l’objet de conf pour la nouvelle machine :

$VM = New-Object -TypeName VMware.Vim.VirtualMachineConfigSpec
$VM.UUID = $OldUUID
 3. Reconfigurer la nouvelle machine
(get-vm NewVM).ExtensionData.ReconfigVM_Task($vm)


4. Supprimer l’ancienne VM

 

cmd > tasklist
cmd > netstat -nabo
cmd > netstat -nabo | findstr PID

cmd > tasklist | findstr 2308

source : https://www3.trustwave.com/support/kb/article.aspx?id=12702