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

 

Intégration SAN HP 3PAR avec le Storage Replication Adapter pour Site Recovery Manager 6.5

Comme pour l’autre article sur HDS  :

1ere étape : VMware Compatibility Guide, trouver la version de SRM compatible avec votre SRM et votre stockage, voir aussi le site du fabricant lorsque les versions proposées ne sont plus toutes récentes…

2eme étape : Récupérer le SRA depuis my.vmware.com, bien choisir sa version de SRM puis « Drivers & Tools » > « Go to Downloads »

3eme étape : installer le SRA sur vos serveurs SRM : setup > next > next > next …

4eme étape: ajouter le gestionnaire pour votre baie

Selection du SRA de la 3PAR

5eme étape: Ici, il suffit de se connecter à la baie (vérifier les ouvertures firewall le cas échéant) Hitachi puisque nous nous connectons directement à la baie et non pas au travers d’instance de command device.

L’option des préfixes est intéressante, car vous pouvez segmentez les “Remote Copy Groups” visiblent en fonction de leur nom ainsi avec une bonne convention physique/virtuel et vos différents environnements vous ne verrez que les “Remote Copy Groups” correspondant aux VMs protégées par SRM.

6eme étape régler les éventuels problèmes :

 Ci-dessous quelques messages d’erreurs que j’ai rencontré pendant la configuration des baies

 

 

 

 

La commande SRA ‘discoverArrays’ a échoué.

Cause :
A parameter in XML was input from SRM to the SRA, but it could not be found in any parameters.
Confirm if SRM was passed appropriate parameters in XML from own SRM log message.

Ce message correspond à des ouvertures firewall manquantes.

 

Ou bien,

La commande SRA « discoverArrays » a échoué.

Cause:
Error. Exception has occurred: Login failed. Invalid user (ESX_SRA_LO) or password.
If the problem still persists, please contact HPE 3PAR support for assistance.

Mauvais Compte ou mot de passe pour la connection à la baie.

 

Mais encore,

La commande SRA « discoverArrays » a échoué.

Cause:
Server certificate is not accepted yet. Please run  ‘TpdSrm.exe validatecert’ to accept and save the server certificate.
Please run  ‘TpdSrm.exe validatecert’ to accept and save the server certificate.

Commande à passer sur les serveurs SRM pour accepter le certificat : TPDSrm.exe validatecert -sys “ip” -user “toto” -pass “pwd”

Une fois les éventuels problèmes réglés, félicitation vous êtes correctement connectez aux baies :