Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Es gibt keinen universellen Einheitsbefehl, da dieser davon abhängt, welchen Dienst Sie neu starten müssen. Hier eine praktische Übersicht:
| Dienst | Aufgabe | Befehl zum Neustarten |
|---|---|---|
| hostd | Verwaltet lokale Virtuelle Maschinen und Host-Vorgänge | /etc/init.d/hostd restart |
| vpxa | Steuert die Kommunikation mit vCenter | /etc/init.d/vpxa restart |
| fdm | Führt Funktionen von vSphere HA aus | /etc/init.d/vmware-fdm restart |
Wenn Sie sich nicht sicher sind, welchen Dienst Sie neu starten müssen oder der Host allgemein nicht erreichbar ist, können Sie alle Verwaltungsagenten auf einmal neu starten:
services.sh restart
Sie wissen nicht, welche Methode zu Ihrem Fall passt? Im nächsten Abschnitt erfahren Sie, wie Sie Ihr Symptom der passenden Lösung zuordnen.
Ausfälle von Verwaltungsagenten treten ohne sichtbare Vorwarnung auf. Ihre virtuellen Maschinen laufen weiter, aber der Host ist nicht mehr verwaltbar und überwachbar – die Ausgaben von vCenter können nicht vertraut werden. Folgende Anzeichen sprechen für einen Neustart der Agenten:
hostd hin, keine Netzwerkstörung.vpxa sendet vermutlich keine Heartbeat-Signale mehr an vCenter.hostd zu viel Arbeitsspeicher belegt oder in einer Endlosschleife steckt.
Bevor Sie Befehle ausführen, prüfen Sie zwei Minuten lang Ihre Umgebung. Der Neustart selbst ist sicher, aber Zeitpunkt und Vorgehensweise sind wichtig.
Nein. Ein Neustart von hostd und vpxa betrifft nur die Verwaltungsebene. Ihre virtuellen Maschinen laufen unabhängig von dieser Ebene weiter. Sie bleiben eingeschaltet, ihr Netzwerkverkehr wird nicht unterbrochen.
Dennoch können alle laufenden Verwaltungsvorgänge wie Snapshots, Einschaltvorgänge oder Konfigurationsänderungen fehlschlagen oder hängen bleiben, bis die Agenten wieder erreichbar sind. Warten Sie, bis alle aktiven Aufgaben abgeschlossen sind, bevor Sie fortfahren.
Vor der Ausführung beliebiger Befehle zu prüfende Punkte
services.sh restart. Dieser Befehl startet alle Dienste neu und unterbricht vorübergehend Netzwerkverbindungen. Starten Sie stattdessen hostd, vpxa und fdm einzeln neu. Führen Sie folgenden Befehl aus, um zu prüfen, ob NSX installiert ist:esxcli software vib list --rebooting-image | grep esx-*
Wenn in der Ausgabe vsip-esx oder esx-vxlan angezeigt werden, ist NSX auf dem Host installiert.
services.sh restart. Starten Sie Dienste nur einzeln neu.Dies ist die gängigste Vorgehensweise. Sie ermöglicht die genaue Steuerung der neu zu startenden Dienste und liefert sofortige Rückmeldungen.
Schritt 1: SSH auf dem ESXi-Host aktivieren
Falls SSH noch nicht läuft, aktivieren Sie es über den vSphere Host Client unter Host > Verwalten > Dienste > TSM-SSH > Starten. Alternativ aktivieren Sie SSH über die DCUI unter Problembehandlungsoptionen.
Schritt 2: Per SSH verbinden
Verwenden Sie PuTTY (Windows) oder das System-Terminal (macOS/Linux) und melden Sie sich als root an.
Schritt 3: hostd neu starten
/etc/init.d/hostd restart
Schritt 4: vpxa neu starten
/etc/init.d/vpxa restart hostd und danach vpxa. Der vpxa-Agent benötigt einen erreichbaren hostd-Dienst, um sich korrekt bei vCenter neu zu registrieren.Schritt 5: Überprüfen, ob beide Dienste laufen
/etc/init.d/hostd status
/etc/init.d/vpxa status
Beide Befehle sollten die Ausgabe hostd is running und vpxa is running liefern. Sollte einer der Dienste als stopped angezeigt werden, warten Sie 30 Sekunden und führen Sie die Statusprüfung erneut aus – die Dienste benötigen ggf. einen Moment zur vollständigen Initialisierung.
Schritt 6: Verwaltungsnetzschnittstelle neu starten (falls der Host weiterhin nicht erreichbar ist)
Wenn beide Dienste als laufend bestätigt werden, der Host aber in vCenter weiterhin nicht antwortet, starten Sie die Verwaltungs-VMkernel-Schnittstelle neu. Dadurch wird die Verwaltungsverbindung kurz unterbrochen, der VM-Datenverkehr bleibt unbeeinflusst.
esxcli network ip interface set -e false -i vmk0 ; esxcli network ip interface set -e true -i vmk0 vmk0 durch Ihre tatsächliche Verwaltungs-VMkernel-Schnittstelle, falls diese abweicht. Mit esxcli network ip interface list können Sie alle Schnittstellen auflisten.Die Direct Console User Interface (DCUI) ist das gelb-graue Textmenü, das auf einem physischen Monitor angezeigt wird, der mit Ihrem Server verbunden ist. Verwenden Sie diese Methode, wenn SSH deaktiviert ist oder das Netzwerk zu instabil für eine Remotesitzung ist.
Wann DCUI statt SSH verwenden
Die DCUI läuft direkt auf der Host-Konsole und ist nicht auf Netzwerkverbindungen angewiesen. Wenn Sie keine SSH-Sitzung öffnen oder der Host Client nicht laden können, ist dies die zuverlässigste Ausweichlösung.
Schritt-für-Schritt-Anleitung: Neustart von Agenten über die DCUI
services.sh restart aus, wodurch alle Dienste gleichzeitig neu gestartet werden. Wenn auf diesem Host NSX oder LACP konfiguriert ist, verwenden Sie stattdessen Methode 1 und starten Sie hostd und vpxa einzeln neu.Wenn Sie noch direkt auf den vSphere Host Client zugreifen können, der Host aber in vCenter als „Getrennt“ markiert ist, können Sie die Agenten über den Browser neu starten – ohne Befehlszeile.
Wann diese Methode geeignet ist
Diese Vorgehensweise funktioniert nur, wenn der Host Client geladen werden kann. Sollte dies nicht der Fall sein, liegt das Problem bei hostd selbst – wechseln Sie zu Methode 1 oder Methode 2.
Schritt-für-Schritt: Neustart über Host > Verwalten > Dienste
Wenn ein Neustart der Agenten die Verbindung nicht wiederherstellt, liegt das Problem vermutlich tiefer als ein blockierter Dienst. Wechseln Sie an dieser Stelle von der Anwendung von Lösungen zur Suche nach der Ursache.
ESXi speichert Verwaltungs-Protokolle unter /var/log/. Wenn die Agenten nicht starten oder direkt nach dem Neustart abstürzen, prüfen Sie zuerst diese zwei Dateien:
Verwenden Sie per SSH den Befehl tail, um aktuelle Einträge anzuzeigen, ohne die gesamte Protokolldatei öffnen zu müssen:
Letzte 50 Zeilen von hostd.log anzeigen:
tail -n 50 /var/log/hostd.log
Fehler in vpxa.log suchen:
grep -i "error" /var/log/vpxa.log
Achten Sie auf Zeichenfolgen wie Connection refused, Failed to discover oder Resource temporarily unavailable. Treten dauernde E/A-Fehler auf, warten die Agenten ggf. auf ein nicht mehr antwortendes Speicherarray – prüfen Sie, ob Datenspeicher den Status All Paths Down (APD) oder Permanent Device Loss (PDL) aufweisen.
vCenter erkennt nicht automatisch, dass die Agenten wieder erreichbar sind. Wenn der Host nach einem bestätigten Neustart weiterhin als „Getrennt“ oder „Nicht antwortend“ angezeigt wird, lösen Sie eine manuelle Wiederverbindung aus:
Wenn die Neustartbefehle endlos hängen bleiben oder der Fehler Device or resource busy zurückgegeben wird, befindet sich ein Prozess in einem nicht unterbrechbaren Zustand – meist verursacht durch einen Speicher- oder Kernel-Fehler, den die Verwaltungsebene nicht selbst beheben kann.
Wenn services.sh restart nicht innerhalb von 10 Minuten abgeschlossen wird oder die Protokolle Kernel-Fehler anzeigen, die auf einen instabilen Host hindeuten, planen Sie einen vollständigen Neustart. Da die Verwaltungsagenten ausgefallen sind, müssen Sie den Neustart wahrscheinlich über die Hardware-Verwaltungsschnittstelle Ihres Servers ausführen (iDRAC, iLO oder IPMI).
Ein Neustart der Verwaltungsagenten löst das unmittelbare Problem. Er schützt Sie aber nicht vor Problemen während des Zeitraums, in dem der Host nicht verwaltbar ist: hängende Snapshots, fehlgeschlagene Sicherungsaufträge oder virtuelle Maschinen, die ohne gültigen Wiederherstellungspunkt nicht wiederhergestellt werden können.
Manuelle Eingriffe funktionieren einmal. Eine zuverlässige Sicherungsstrategie funktioniert dauerhaft.
i2Backup ist eine Unternehmenssicherungs-Lösung. Sie schützt VMware-VMs, ohne Agenten auf Host oder Gastsystem installieren zu müssen – mithilfe nativer VMware-APIs für skalierbare Sicherungen ohne Auswirkungen auf Produktiv-Workloads.
Ausfälle von Verwaltungsagenten lassen sich selten vorhersagen. Mit einer aktuellen, sauberen VM-Sicherung dauert die Wiederherstellung bei einem Fehler nur wenige Minuten, statt stundenlanger Fehleranalyse.
F1: Hat der Neustart von hostd Auswirkungen auf laufende virtuelle Maschinen?
Nein. Verwaltungsagenten wie hostd und vpxa arbeiten unabhängig von der Ebene, auf der Ihre virtuellen Maschinen ausgeführt werden. Die VMs laufen weiter, verarbeiten Daten und behalten ihre Netzwerkverbindungen während des gesamten Neustarts aufrecht. Einzige vorübergehend nicht verfügbare Komponente ist die Verwaltungsoberfläche selbst.
F2: Wie überprüfe ich, ob die Agenten erfolgreich neu gestartet wurden?
Führen Sie den Statusprüf-Befehl per SSH aus:
/etc/init.d/hostd status
/etc/init.d/vpxa status
Beide Befehle sollten den Status „running“ ausgeben. Prüfen Sie zudem, ob der Host in der vCenter-Bestandsliste wieder den Status Verbunden erhält – dies bestätigt, dass vpxa die Kommunikation mit vCenter erfolgreich wiederhergestellt hat.
F3: Worin besteht der Unterschied zwischen hostd und vpxa?
hostd verwaltet direkt die lokalen Ressourcen des Hosts und alle Vorgänge an virtuellen Maschinen. vpxa ist der Kommunikationsagent für vCenter – er empfängt Anweisungen vom vCenter Server und leitet sie zur Ausführung an hostd weiter. Wenn hostd der Motor ist, ist vpxa das Relais.
F4: Kann ich Verwaltungsagenten ohne SSH-Zugriff neu starten?
Ja. Verwenden Sie die DCUI über eine physische Konsole oder ein Remote-Hardware-Verwaltungstool wie iDRAC oder iLO. Wenn der vSphere Host Client noch erreichbar ist, können Sie Dienste auch direkt unter Host > Verwalten > Dienste neu starten.
F5: Muss ich nach einer Netzwerkkonfigurationsänderung die Verwaltungsagenten neu starten?
In der Regel nicht. Wenn Sie aber Änderungen an einem vSphere Verteilten Switch vorgenommen haben und der Host in vCenter weiterhin als „Nicht synchronisiert“ angezeigt wird, erzwingt ein Neustart der Agenten eine Aktualisierung der Konfiguration und eine erneute Synchronisierung des Host-Zustands mit der vCenter-Datenbank.
Ein Ausfall von Verwaltungsagenten wirkt schlimmer, als er ist. In den meisten Fällen laufen Ihre virtuellen Maschinen weiterhin, das Problem beschränkt sich auf die Verwaltungsebene – ein gezielter Dienstneustart genügt, um Übersicht und Steuerung wiederherzustellen.
Die drei in dieser Anleitung vorgestellten Methoden bieten eine Lösung für jedes Szenario: SSH für präzise Steuerung, DCUI bei instabilem Netzwerk und der Host Client, wenn nur die vCenter-Verbindung gestört ist. Sollte keine dieser Vorgehensweisen funktionieren, weisen die Protokolldateien auf die eigentliche Ursache hin – sei es ein Speicherproblem, nicht übereinstimmende Zugangsdaten oder ein Fehler, der einen vollständigen Host-Neustart erfordert.
Ein Dienstneustart kann keine Daten wiederherstellen. Wenn ein Agentenausfall eine fehlgeschlagene Sicherung oder einen hängenden Snapshot verursacht, benötigen Sie einen gültigen Wiederherstellungspunkt als Ausweg. Richten Sie vor dem nächsten Ausfall agentenlose VM-Sicherungen mit i2Backup von Info2soft ein – nicht erst danach. Das ist die einfachste Möglichkeit, jederzeit eine Wiederherstellung durchführen zu können.
