Comment résoudre une erreur de connexion 503 Server Unavailable sur VMware ESXi ?

Vous devez redémarrer les services de gestion vmware. Heureusement, c'est facile (puisque vous avez un accès SSH) et sans impact sur les machines virtuelles.

En bref, SSH à la trame esx en tant que root puis exécutez l'une des deux commandes suivantes (selon qu'il s'agit de esx/i) :

Pour ESX :

service mgmt-vmware restart

Pour ESXi :

/sbin/services.sh restart

Voir cet article pour tous les détails

J'ai résolu le problème en désinstallant widecap. Erreur de ServiceInstance.RetrieveContent

Cette KB VMware semble correspondre au symptôme que vous avez décrit. Vérifiez que votre DNS est en place et fonctionne du point de vue du serveur ESXi.

Option 2 : Pouvez-vous vérifier que votre serveur vCenter est en place et que le service est lancé ?

Apparemment, l'un des deux filers a connu un événement de basculement, mais n'a pas basculé proprement. Par conséquent, l'hôte ESXi n'a pas pu déclarer ces chemins morts et a connu un afflux de problèmes de bloc au niveau du LUN avec des commandes HBA busy, bus busy et abort dans le vmkernel.log.

Le support VMware a pu nous guider à travers les problèmes après que les clusters de têtes de fichiers SAN aient été restaurés dans un état actif/actif (NetApp). Les erreurs hexagonales "cat /var/log/vmkernel.log | grep sense | less" ont montré de nombreux problèmes au niveau LUN (D:0x2), bus occupé (H:0x2), HBA occupé (D:0x8), commandes d'abandon (H:0x5) à partir de délais d'attente, ce qui indique qu'un filer SAN n'a pas été correctement basculé et se déclare toujours disponible.

Après la restauration du filer SAN pour les chemins/LUNs, nous avons lancé la commande " /sbin/services.sh restart " qui s'est achevée et nous avons été en mesure de vClient dans l'hôte à nouveau, le web et le joindre à nouveau au cluster existant pour effacer les VM " orphane " " sans nom " qui étaient des restes résiduels.

Sur mon appliance vCenter 6.5, le fichier vpxd service core dumps et procudes cette erreur.

Seule solution pour l'instant : bloquer l'accès à l'hôte ESX jusqu'à ce que tous les services vCenter soient démarrés.

Maintenant, une unité Shell Shell/systemd sur vCenter crée des règles de pare-feu/filtre de paquets iptables au démarrage. Une fois que les services vCenter sont démarrés et que la moyenne de charge descend en dessous de 0,5, le Shell supprime les règles iptables. Ce n'est que maintenant que vCenter est capable de "voir" les hôtes ESX et est heureux pendant un certain temps. Si le problème réapparaît, je redémarre vCenter.

Le Shell Shell :

#!/bin/bash
# /usr/local/bin/block-esx-access-on-boot.sh

export ESX_HOSTS="ESX1-IP,ESX2-DNS,ESX3-IP"
export LOAD_THRESHOLD="0.5"

sleep 5

LOAD="$(cut -d' ' -f1 /proc/loadavg)"

echo "Waiting for 1min loadavg ${LOAD} > ${LOAD_THRESHOLD} ..."
while [ "$(echo "${LOAD} > ${LOAD_THRESHOLD}" | bc)" == "0" ] ; do
  echo "Waiting for 1min loadavg ${LOAD} > ${LOAD_THRESHOLD} ..."
  sleep 3
  LOAD="$(cut -d' ' -f1 /proc/loadavg)"
done

echo "Blocking outgoing transfers to ${ESX_HOSTS}"
iptables -A OUTPUT -d ${ESX_HOSTS} -j DROP
iptables -L OUTPUT

while [ "$(echo "${LOAD} < ${LOAD_THRESHOLD}" | bc)" == "0" ] ; do
  echo "Waiting for 1min loadavg ${LOAD} < ${LOAD_THRESHOLD} ..."
  sleep 60
  LOAD="$(cut -d' ' -f1 /proc/loadavg)"
done

echo "Allowing outgoing transfers to ${ESX_HOSTS}"
iptables -D OUTPUT -d ${ESX_HOSTS} -j DROP
iptables -L OUTPUT

L'unité systemd :

# /etc/systemd/system/block-esx-access-on-boot.service

[Unit]
Description=Block ESX Access on Boot
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/block-esx-access-on-boot.sh

[Install]
WantedBy=multi-user.target

https://gist.github.com/quatauta/a1ac390633006996fbc547da9bd01ef9