Skip to main content
Sign Out

Welcome to Dell

My Account
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Create and access a list of your products
Sign In Create an Account Premier Sign In Partner Program Sign In
Contact Us

Your Dell.com Carts

Dell EMC VxRail: Der ESXi-Host zeigt in vCenter „not responding“ oder „disconnected“ an (von KundInnen korrigierbar).

Summary: In diesem Artikel wird beschrieben, was bei Hosts zu prüfen oder zu tun ist, die von vCenter nicht verwaltet werden können, wenn dies aber erwartet wird. In vCenter werden diese Hosts im Navigator mit (disconnected) oder (not responding) neben dem Hostnamen angezeigt. Die Schritte in diesem Artikel können auch im Zusammenhang mit anderen Problemen mit der Reaktionsgeschwindigkeit des Hosts Anwendung finden, selbst wenn der Host nicht unbedingt von vCenter getrennt zu sein scheint. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

Ein Host wurde zuvor in einem Cluster in vCenter angezeigt, wird aber als getrennt oder nicht reagierend markiert. Management und Monitoring des Hosts sind im vCenter-Webclient nicht mehr verfügbar. Alle VMs, die auf diesem Host ausgeführt wurden, wurden entweder auf verfügbare Hosts (HA) verschoben oder werden auch als nicht verfügbar oder getrennt angezeigt.

Ein Host wird im vCenter-Webclient als „disconnected“ oder „not responding“ angezeigt. Der Host kann weiterhin als „running“ angezeigt werden und virtuelle Maschinen (VMs) werden möglicherweise noch darauf ausgeführt. Der Host kann jedoch nicht über vCenter verwaltet werden und reagiert möglicherweise auch auf andere Weise nicht ordnungsgemäß. Die auf dem Host ausgeführten VMs können nicht mithilfe von vMotion auf andere Hosts im Cluster migriert werden.

Cause

Diese Situation ist auf bestimmte Services auf dem Host zurückzuführen, die nicht ordnungsgemäß ausgeführt werden. Obwohl es andere Gründe geben kann (siehe Abschnitt „Hinweise“ unten für Links zu zusätzlichen Artikeln), können nicht reagierende Hostservices daraus resultieren, dass der Host nicht mehr genügend verfügbare Ressourcen hat (in der Regel fehlt Arbeitsspeicher). Ein ESXi-Host fährt ressourcenintensive Services wie hostd herunter, anstatt den Speicher zu verwenden, der den ausgeführten VMs zugewiesen ist, falls erforderlich.

Das vCenter kann aufgrund fehlender Services und allgemeiner Schwierigkeiten mit einem verzögert reagierenden Host, der nicht genügend verfügbare Ressourcen hat, um ordnungsgemäß zu funktionieren, nicht mit dem Host kommunizieren. Im Ergebnis reagiert ein Host nicht auf vCenter und arbeitet langsam oder ist anderweitig schwer zu erreichen oder zu managen. In diesen Fällen ist der Storage des Hosts im VSAN-Datenspeicher immer noch voll funktionsfähig und seine VMs werden in der Regel für einen bestimmten Zeitraum ordnungsgemäß ausgeführt. Der Neustart des Hosts, um Arbeitsspeicher zurückzugewinnen, der nach der Verwendung nicht ordnungsgemäß vom Host zurückgewonnen wurde (ein Speicherverlust), ist häufig die einzige Möglichkeit, die Verwaltbarkeit des Hosts wiederherzustellen und ihn wieder mit vCenter zu verbinden.

Weitere Informationen finden Sie unter Detaillierte Beschreibung im Feld „Hinweise“.

Resolution

NutzerInnen:
Wenn der Host nach dem Ausführen der unten aufgeführten Schritte zur Fehlerbehebung immer noch keine ordnungsgemäße Verbindung zum vCenter herstellt oder Sie Fragen haben oder Unterstützung benötigen, wenden Sie sich an den technischen Support von Dell EMC oder an Ihre autorisierten ServicemitarbeiterInnen, um eine Serviceanfrage zu eröffnen.

Erste Prüfungen: 
  1. Überprüfen Sie, ob VMs, von denen bekannt ist, dass sie sich auf dem Host befinden (diese werden wahrscheinlich auch als getrennt in vCenter angezeigt), weiterhin ausgeführt werden.
  2. Versuchen Sie, einen vSphere-Webclient für den Host: https://<Management-IP des Hosts> zu öffnen, eine PuTTY-Sitzung zu starten oder eine direkt verbundene Benutzeroberfläche aufzurufen (DCUI – eine Konsole über IDRAC auf der Dell Plattform oder BMC auf Quanta öffnen). Wenn über PuTTY oder vSphere keine Verbindung zu einem Host, der online ist (VMs werden ausgeführt), hergestellt werden kann oder eine hohe Verzögerung in der DCUI auftritt (oder nicht einmal eine Verbindung möglich ist) und keine Services neu gestartet oder andere Befehle über die Befehlszeile ausgeführt werden können, weist das auf fehlende verfügbare Hostressource hin, wie in der detaillierten Beschreibung dargelegt.
  3. Drücken Sie in der DCUI Alt + F11, um festzustellen, ob der Hostmonitor ein Problem wie hostd service stopped anzeigt.
  4. Überprüfen Sie, ob Sie den Host anpingen können. Andernfalls reagiert er möglicherweise nicht auf den Diagnosebildschirm (PSOD), ist ausgeschaltet (schalten Sie ihn nach Möglichkeit wieder ein) oder es liegt ein Netzwerkproblem vor.
  5. Wenn der getrennte Host kein Problem mit Services zu haben scheint (Pings sind in Ordnung, Webclient-Verbindung zum Host funktioniert, DCUI arbeitet gut usw.), können Sie versuchen, mit der rechten Maustaste auf den Host im Navigator von vCenter unter „Hosts and Clusters“ zu klicken und die Optionen für die Verbindung mit dem Host auszuwählen.
Wenn Sie Befehle auf dem Host ausführen können:
  1. Überprüfen Sie den Status von hostd und vpxa: /etc/init.d/hostd status && /etc/init.d/vpxa status
  2. Versuchen Sie, hostd und vpxa neu zu starten: /etc/init.d/hostd restart && /etc/init.d/vpxa restart
  3. Wenn die Befehle funktioniert haben, aber der Host immer noch nicht verbunden ist, versuchen Sie, alle Managementservices neu zu starten:
  • Suchen Sie nach LACP (Starten Sie nicht alle Services neu, wenn LACP verwendet wird, da dies andere Probleme verursachen kann): # localcli network vswitch dvs vmware lacp config get   
  • Wenn kein LACP vorhanden ist, starten Sie alle Managementservices auf dem Host mit einem der folgenden Befehle neu:
    • Unter vSphere 6.5 und höher: # services.sh restart and tail -f /var/log/jumpstart-stdout.log   
Das Protokoll wird nicht beendet, wenn alle Services neu gestartet werden. Verwenden Sie Strg + C, sobald es fertig ist (nach ca. 5 bis 10 Minuten).
  • Führen Sie bei vSphere-Versionen vor 6.5 (VxRail-Code vor 4.5.x) Folgendes aus: services.sh restart
  1. Überprüfen Sie, ob der Host wieder verbunden ist, nachdem alle Services neu gestartet wurden.
Wenn die Schritte 3 und 4 funktionieren, sollte der Host automatisch die Verbindung zum vCenter wiederherstellen. Möglicherweise müssen Sie die vCenter-Webseite aktualisieren oder den Host manuell erneut verbinden. Sie sollten den Host in den Wartungsmodus versetzen (Zugriff sicherstellen) und alle laufenden VMs migrieren. Führen Sie vor dem Neustart die folgenden Schritte aus, um die Protokolle abzurufen, die erforderlich sind, wenn eine weitere Analyse der Ursache gewünscht wird:
  1. Erstellen Sie ein hostd-Speicherabbild aus dem Arbeitsspeicher, indem Sie den folgenden Befehl auf dem Host ausführen: vmkbacktrace -n hostd -c -w
  2. Überprüfen Sie mit der Ausgabe dieses Befehls, ob er vorhanden ist: ls -alrth /var/core/hostd*
Die Ausgabe sieht wie folgt aus: rwx------    1 root     root       32.8M Aug 15 05:10 /var/core/hostd-worker-zdump.001
  1. Stellen Sie mit WinSCP, Filezilla usw. eine Verbindung zum Host her und laden Sie die Datei herunter.
  2. Starten Sie den Host neu, stellen Sie sicher, dass er eine Verbindung zum vCenter herstellt und ordnungsgemäß funktioniert, und schalten Sie die VMs ein oder migrieren Sie die VMs wie gewünscht zurück zum Host. 
Wenn der Host eingeschaltet und pingbar ist, Sie jedoch keine SSH-Verbindung herstellen können:
  • Versuchen Sie, eine Verbindung zum Host über IDRAC (BMC auf Quanta) oder einen KVM herzustellen, um Befehle über eine Konsolenshell auszuführen. Wenn dies funktioniert, eine Verbindung über PuTTY (oder eine andere SSH-Verbindung) aber nicht möglich ist, versuchen Sie, die Konnektivität wiederherzustellen, indem Sie die oben genannten Schritte ausführen.
  • Geben Sie Speicherplatz frei, indem Sie einige der VMs des Hosts herunterfahren. Dies kann manchmal ausreichen, um die oben genannten Schritte zu ermöglichen, ohne jede VM auf dem Host ausschalten zu müssen. Wenn Sie es mit dieser Methode versuchen, können HA-Funktionen (hohe Verfügbarkeit) verbundene Hosts im Cluster automatisch wieder online schalten.
  • Um den Speicherstatus zu überprüfen, führen Sie esxtop auf dem Host aus und drücken Sie dann m, um die Arbeitsspeichernutzung zu überprüfen.
  • Weitere Informationen zum manuellen Registrieren von VMs auf anderen Hosts finden Sie im VMware-Artikel https://kb.vmware.com/s/article/1006160. Auf diese Weise können Sie die Zeit minimieren, die VMs vor oder während eines Neustarts heruntergefahren werden.
Schritte zum Neustart eines getrennten Hosts, um die Konnektivität zu vCenter wiederherzustellen:
  1. Überprüfen Sie, welche VMs auf dem Host über vCenter ausgeführt werden. Diese Informationen sind alt, da der Host nicht mit vCenter verbunden ist, aber Sie können in der Regel VMs, die sich auf dem Host befinden, ermitteln, indem Sie nachsehen, welche auf der Registerkarte „Related Objects > Virtual Machines/VMs“ des Clusters auch als getrennt angezeigt werden.
  2. Stellen Sie eine Remoteverbindung oder eine SSH-Verbindung direkt zu den virtuellen Maschinen her und fahren Sie sie herunter.
Sie können es zuerst mit den am wenigsten wichtigen versuchen, um zu sehen, ob Sie Services und die Verbindung wiederherstellen können. Bei Bedarf können Sie VMs auf einem anderen Host registrieren und hochfahren (wenn Sie dazu aufgefordert werden, wählen Sie „I moved it“ aus), nachdem Sie sie auf dem getrennten Host heruntergefahren haben.
  • Windows: Verwenden Sie RDP oder eine andere Zugriffssoftware, um die VM aufzurufen und herunterzufahren.
  • RecoverPoint-VMs: Melden Sie sich über PuTTY als boxmgmt an und befolgen Sie die Weisungen zum Herunterfahren.
  • Secure Remote Services: Stellen Sie eine PuTTY-Verbindung unter Verwendung von admin her und führen Sie den Befehl poweroff oder shutdown now aus.
  • Linux: Mit dem Befehl shutdown now wird er heruntergefahren, wobei shutdown -r now der Befehl für einen Neustart ist.
Alternative Methode zum Herunterfahren der VM, wenn Sie über die PuTTY- oder DCUI-Shell-Verbindung zum Host auf eine Befehlszeile und nicht direkt auf die VMs zugreifen können: Siehe Wissensdatenbank-Artikel https://kb.vmware.com/kb/1014165.
  • Befehl, um festzustellen, ob eine VM auf einem Node ausgeführt wird, und um die World ID abzurufen: # localcli vm process list.
  • Befehl zum Herunterfahren einer VM: # localcli vm process kill -t soft -w <worldID>.
Die Verwendung von soft wie oben führt zum saubersten Herunterfahren. Wenn das nicht funktioniert, verwenden Sie stattdessen hard, um das System sofort herunterzufahren. Die Option force sollte als letzter Ausweg verwendet werden.
  1. Stellen Sie in vCenter sicher, dass der Rest des Clusters fehlerfrei ist und keine VSAN-Neusynchronisation oder eine andere Situation vorliegt, die verhindert, dass Sie den Host vorübergehend für einen Neustart sicher aus dem VSAN entfernen können, selbst wenn der Host nicht sofort wieder hochgefahren wird.
  2. Versetzen Sie den Host nach Möglichkeit in den Wartungsmodus. Verwenden Sie den vSphere-Webclient, falls verfügbar. Wenn dies nicht der Fall ist, öffnen Sie die Shell über die DCUI mit Alt + F1, melden Sie sich als „root“ an und verwenden Sie die Befehlszeile, um zu versuchen, den Host in den Wartungsmodus zu versetzen. Stellen Sie sicher, dass alle VMs auf dem Host heruntergefahren sind, und versetzen Sie den Host dann mithilfe einer der folgenden Optionen über die Befehlszeile in den Wartungsmodus:
  • Zugriff sicherstellen: esxcli system maintenanceMode set --enable true -m ensureObjectAccessibility.
  • Keine Datenmigration: esxcli system maintenanceMode set --enable true -m noAction.
  • Vollständige Datenmigration: esxcli system maintenanceMode set --enable true -m evacuateAllData.
Überprüfen Sie erneut, ob Sie vor dem Neustart eine Konsole aufrufen können, da dies Ihre letzte Chance zum Abruf von Protokollen wäre, die nach dem Start gelöscht werden.
  1. Starten Sie den Host entweder über iDRAC- oder BMC-Steuerelemente oder über die Befehlszeile mithilfe von reboot.
  2. Sobald der Host aktiv ist, sollte er wieder in vCenter vorhanden sein. Versuchen Sie, ihn manuell mit dem Cluster zu verbinden, falls dies nicht der Fall ist. Wenn er immer noch nicht eingebunden wird, können Sie auch das vCenter neu starten. Starten Sie bei vCenter-Appliances, bei denen der PSC nicht integriert ist, zuerst den PSC und dann die VCSA neu.
  3. Erfassen Sie ein vCenter-Support-Bundle (einschließlich der Hostprotokolle) und bereiten Sie einen Zeitplan für zugehörige Ereignisse vor, wenn eine Analyse der Ursache angefordert wird. Weitere Informationen zum Erfassen von Protokollen in einer VxRail-Umgebung finden Sie im KB-Artikel https://support.emc.com/kb/333684. Wenn ein Service-Request beim VxRail-Support eröffnet wird, werden auch Hardwareprotokolle vom Host und ein VxRail Manager-Protokollpaket benötigt.

Additional Information

Detaillierte Beschreibung (erläutert, warum ein Neustart des Hosts in der Regel erforderlich ist):

In der Regel liegt auf einem Host, der von vCenter getrennt wurde, eine nicht verfügbarer (oder vom Host gestoppter) Hostservice vor. Dieser Service ist erforderlich, um den Host durch vCenter verwaltbar zu machen. Er ist speicherintensiv, sodass er ausgeschaltet wird, wenn der Host von mangelndem verfügbarem Speicher betroffen ist. Einige andere Services agieren ähnlich. Der Neustart von Services (bestimmter oder aller Managementservices) auf einem getrennten Host sollten es dem Host ermöglichen, erneut eine Verbindung zum vCenter herzustellen. Der Grund, warum der Service nicht ausgeführt wird, ist jedoch häufig der, dass dem Host nicht genügend Ressourcen (CPU, Arbeitsspeicher) zur Verfügung stehen. Wenn die Ursache ein Hostd-Speicherverlust ist, wird ein Neustart erforderlich, damit der Host ordnungsgemäß ausgeführt wird.

Speicherverlust passiert, wenn Systemspeicher verwendet wird und anschließend nicht ordnungsgemäß zurückgewonnen werden kann. Der hostd-Service ist häufig, aber nicht immer Teil der Ursache. ESXi stoppt diesen Service, um zu verhindern, dass er nicht mehr reagiert. Hostmanagementservices (nicht nur hostd) reagieren möglicherweise nicht mehr und können aufgrund fehlender verfügbarer Ressourcen nicht neu gestartet werden. Sobald hostd (auch vpxa und einige andere) nicht mehr ausgeführt wird, ist ein Host nicht mehr mit dem vCenter verbunden. Manchmal ist es möglich, die Services neu zu starten und den Host wieder mit vCenter zu verbinden, insbesondere wenn zunächst genügend Ressourcen freigegeben werden können.

Durch den Neustart des Hosts werden diese Verbindungsprobleme automatisch behoben, da nicht zurückgewonnener Speicher wieder verfügbar wird und alle Dienste während des Startvorgangs neu gestartet werden. Selbst wenn ein Host erneut verbunden werden kann, indem hostd, vpxa usw. ausgeführt werden, ist es am besten, die ausgeführten VMs vom Host zu migrieren (Sie können jetzt, da der Host mit vCenter verbunden ist), ihn in den Wartungsmodus versetzen und neu starten, um sicherzustellen, dass alle gesperrten Ressourcen wieder verfügbar werden. Dadurch wird vermieden, dass der Host kurzfristig in den nicht reagierenden Zustand zurückkehrt. Darüber hinaus ist es wichtig, immer die aktuellsten ESXi-Patches und -Upgrades anzuwenden, da diese die zugrunde liegenden Ursachen von Speicherverlusten und anderen Problemen beheben, die dazu führen können, dass Services nicht mehr reagieren (oder anderweitig getrennte Hosts verursachen).
     
Die Verifizierungs- und Fehlerbehebungsschritte im Abschnitt „Lösung“ können befolgt werden, um zu versuchen, diese Situationen bestmöglich zu lösen. Während der Prozess zuerst versucht, die Auswirkungen zu reduzieren, ist in den meisten Fällen ein Neustart des Hosts erforderlich. Dies ist oft unbequem oder zu diesem Zeitpunkt keine Option für KundInnen. Ein Host kann oft eine Weile gut ausgeführt werden, selbst wenn er von vCenter getrennt ist, und der Einsatz von VMs auf dem Host und VSAN der Laufwerke des Hosts wird oft fortgesetzt. Es ist am besten, den Host so schnell wie möglich neu zu starten. Wenn jedoch ein Wartungszeitfenster oder ein Abwarten bis zum Ende der Produktionszeiten erforderlich ist, ist das in Ordnung. Ein Host ohne Arbeitsspeicher wird wahrscheinlich irgendwann abstürzen und das Neustarten von VMs funktioniert wahrscheinlich nicht. Wenn keine Probleme an anderer Stelle im Cluster vorliegen, sollte die Fehlertoleranz (HA, VSAN-Schutz, Möglichkeit zum Starten von VMs auf anderen Hosts usw.) weiterhin bestehen.
 
Obwohl das Neustarten des Hosts die wichtigste Möglichkeit ist, nicht reagierende/getrennte Hosts wieder zu verbinden, sind die Protokolle, die zur Analyse der Ursache dieser Probleme erforderlich sind, nach dem Neustart wahrscheinlich nicht verfügbar. Wenn Sie den Host dazu bringen können, ausreichend zu reagieren, um die erforderlichen Protokolle zu erzeugen und zu erfassen, ist es wahrscheinlicher, dass jede weitere Analyse eine zugrunde liegende Ursache identifizieren kann. Wenn diese Protokolle nicht erfasst werden können, weil der Host nicht reagiert hat oder ein Neustart bereits durchgeführt wurde oder für eine schnellere Lösung gewählt wurde (es dauert eine Weile, bis der Host die Protokolle erzeugt hat, was sich häufig nicht lohnt), gibt es immer noch einige Protokolle, die helfen können, eine Ursache einzugrenzen oder die besten Empfehlungen für die Zukunft zu ermitteln. Sie sollten mindestens das vCenter-Protokoll-Bundle mit dem Protokoll des fehlerhaften Hosts und einem funktionsfähigen Host zum Vergleich erfassen. 

Andere Artikel im Zusammenhang mit nicht reagierenden/getrennten Hosts (in vCenter):
  • Manchmal kann der Smart Agent dazu führen, dass ein Host in vCenter nicht reagiert. Siehe VMware-Artikel https://kb.vmware.com/kb/2145106 und KB-Artikel https://support.emc.com/kb/502016.  
  • ESXi ist nicht verfügbar und kann im Zusammenhang mit Problemen zwischen Plug-ins und PTAgent auf Dell Hosts stehen. Siehe KB-Artikel https://support.emc.com/kb/504039.  

Affected Products

VxRail Appliance Family

Products

Pivotal Ready Architecture, VxRail 460 and 470 Nodes, VxRail Appliance Family, VxRail Appliance Series, VxRail G410, VxRail G Series Nodes, VxRail E Series Nodes, VxRail E460, VxRail E560, VxRail E560F, VxRail G560, VxRail G560F, VxRail Gen2 Hardware , VxRail P Series Nodes, VxRail P470, VxRail P570, VxRail P570F, VxRail S Series Nodes, VxRail S470, VxRail S570, VxRail Software, VxRail V Series Nodes, VxRail V470, VxRail V570, VxRail V570F ...
Article Properties
Article Number: 000167824
Article Type: Solution
Last Modified: 19 Jan 2024
Version:  7
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.