Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Beim Anmelden bei vCenter wird ggf. ein roter Fehlerbanner mit folgender Meldung angezeigt: „Verbindung zu einem oder mehreren vCenter Server-Systemen nicht möglich“.
Gelegentlich treten auch abgewandelte Fehlermeldungen auf:
Dieser Fehler bedeutet in der Regel, dass der vSphere-Client oder eine andere VMware-Verwaltungskomponente keine Kommunikation mit einem oder mehreren registrierten vCenter-Servern herstellen kann.
In den meisten Fällen läuft der betroffene vCenter weiterhin und virtuelle Maschinen funktionieren normal. Administratoren verlieren jedoch den Zugriff auf Inventarverwaltung, Überwachung, Migrationen, Sicherungen und weitere vCenter-basierte Funktionen, bis die Verbindung wiederhergestellt ist.
Die eigentlichen Fehlerursachen variieren je nach genauer Fehlermeldung.
● Verbindung zu einem oder mehreren vCenter Server-Systemen nicht möglich:443/sdk
Diese Variante weist meist auf Verbindungsprobleme am vCenter-SDK-Endpunkt hin.
Mögliche Gründe:
● Verbindung zu einem oder mehreren vCenter Server-Systemen nicht möglich:https://
Diese Meldung deutet oft auf fehlerhafte URLs, Probleme bei der Zertifikatsvalidierung oder Hostnamen-Auflösungsfehler hin.
● Verbindung zu einem oder mehreren vCenter Server-Systemen nicht möglich:https://:443/sdk
Dieser Fehler taucht häufig auf, wenn Hostnamen-Informationen fehlen oder falsch konfiguriert sind, wodurch die generierte Verbindungs-URL ungültig wird.
Im folgenden Abschnitt finden Sie eine schrittweise Anleitung zur Behebung dieses Fehlers.
Befolgen Sie die nachfolgenden Schritte in der angegebenen Reihenfolge. Jeder Schritt setzt voraus, dass der vorherige erfolgreich ausgeführt wurde.
1. Ermitteln Sie die betroffene Anwendung:
Connect-VIServer -Server <FQDN> -Verbose aus. Die ausführliche Fehlermeldung zeigt oft den genauen HTTP-Statuscode an.2. Betrifft der Fehler alle vCenter-Instanzen einer Linked Mode-Gruppe?
Melden Sie sich direkt über den jeweiligen FQDN bei der Benutzeroberfläche jedes vCenter an. Scheitert nur eine Instanz, konzentrieren Sie sich auf deren Dienste und Zertifikate. Treten bei allen Instanzen Probleme auf, prüfen Sie den PSC (vSphere 6.7) oder den integrierten SSO-Dienst (ab Version 7.0).
Führen Sie auf dem Client-Rechner, auf dem der Fehler angezeigt wird, die Befehle ping und telnet aus:
ping vcenter.example.com
telnet vcenter.example.com 443Schlägt ping fehl: Es liegt ein DNS- oder Routing-Problem vor. Beheben Sie zuerst die Namensauflösung.
Schlägt telnet fehl (Timeout oder „Verbindung abgelehnt“):
● Für PowerCLI unter Windows:
Test-NetConnection -ComputerName vcenter.example.com -Port 443Ist die Verbindung erfolgreich, der Fehler aber weiterhin vorhanden, fahren Sie mit Schritt 4 fort.
Hinweis zum Load Balancer: Befindet sich der vCenter hinter einem Load Balancer, überträgt dieser ggf. TCP-Daten über Port 443, leitet den Pfad /sdk aber fehlerhaft weiter. Umgehen Sie vorläufig den Load Balancer und verbinden Sie sich direkt mit der IP oder dem Hostnamen des vCenter.
Das vCenter-Zertifikat enthält dessen FQDN. Löst der Client diesen FQDN auf eine andere IP-Adresse auf, als der vCenter erwartet, schlägt die Zertifikatsprüfung fehl und die SDK-Verbindung wird abgelehnt.
Auf dem Client-Rechner ausführen:
nslookup vcenter.example.com
# Die Ausgabe muss die IP-Adresse des vCenter anzeigenPrüfen Sie nun die umgekehrte DNS-Auflösung aus Sicht des vCenter. Stellen Sie eine SSH-Verbindung zum VCSA her und führen Sie aus:
nslookup <Client-IP>
ls -la /vmfs/volumes
# Das Ergebnis muss den Hostnamen des Clients enthaltenLässt sich die Client-IP nicht korrekt auf den erwarteten Client-Hostnamen auflösen, vertraut der vCenter Lookup-Dienst dem Client nicht und verweigert die Ausgabe eines Anmeldetokens – daraus resultiert der Verbindungsfehler.
Sie können einen Eintrag zur Umgehung der DNS-Auflösung in die Datei /etc/hosts des VCSA einfügen. Diese Methode funktioniert aber nicht, wenn sich die IP-Adresse ändert oder der vCenter seinen eigenen FQDN prüft. Nutzen Sie stattdessen eine korrekte DNS-Konfiguration.
Dies ist die direkteste Diagnosemöglichkeit. Führen Sie den Befehl auf einem beliebigen Rechner aus, der Port 443 des vCenter erreichen kann:
curl -k https://vcenter.example.com:443/sdkDer Parameter -k ignoriert die Zertifikatsprüfung. Dadurch werden keine SSL-Zertifikatsfehler angezeigt, sondern nur HTTP-Antworten oder Verbindungsfehler.
Erhalten Sie eine XML-Antwort beginnend mit <soapenv:Envelope...> mit einem Fehlercode wie InvalidLogin oder MissingHeader, ist das positiv: Der SDK-Endpunkt ist erreichbar und lehnt den Zugriff nur ab, weil keine Anmeldedaten übermittelt wurden.
Mögliche alternative Antworten:
|
Antwort |
Bedeutung |
Nächster Schritt |
|
curl: (7) Verbindung fehlgeschlagen |
Auf Port 443 lauscht kein Dienst |
Dienst ausgefallen – Prüfen Sie vpxd |
|
curl: (52) Leere Antwort |
Dienst stürzte während der Antwort ab |
vpxd neu starten, Logs prüfen |
|
401 Nicht autorisiert |
SDK läuft, erfordert aber eine Anmeldung. Ohne übermittelte Zugangsdaten ist dies normal. |
Client-seitiges Problem mit Authentifizierung oder Zertifikatstrust |
|
403 Verboten |
Einschränkung per IP oder Pfad (selten) |
Reverse-Proxy-Konfiguration des vCenter prüfen |
|
503 Dienst nicht verfügbar |
Dienst gestartet, aber noch nicht betriebsbereit |
5 Minuten warten oder Startlogs prüfen |
|
Verbindung durch Gegenstelle zurückgesetzt |
Nicht übereinstimmende SSL/TLS-Versionen oder Chiffren |
TLS-Versionen und Verschlüsselungsverfahren prüfen |
● Für PowerShell-Nutzer:
Invoke-WebRequest -Uri "https://vcenter.example.com:443/sdk" -SkipCertificateCheck -Method GetErhalten Sie eine gültige XML-Fehlermeldung (auch mit Fehlercode), funktioniert der SDK-Endpunkt fehlerfrei. Das Problem liegt auf Client-Seite: Fehlendes Browser-Zertifikatstrust, fehlerhafte PowerCLI-Anmeldedaten oder fehlender Parameter -SkipCertificateCheck. Treten Verbindungsverweigerungen oder 5xx-Fehler auf, fahren Sie mit der Dienstprüfung fort.
Der SDK-Endpunkt wird hauptsächlich vom Dienst vpxd (vCenter Server) bereitgestellt. Stellen Sie per SSH eine Verbindung zum VCSA her und führen Sie aus:
service-control --status --allAchten Sie auf folgende Dienste:
RUNNING habenIst vpxd gestoppt, starten Sie ihn:
service-control --start vmware-vpxdPrüfen Sie die Logdateien auf Startfehler:
tail -f /var/log/vmware/vpxd/vpxd.log
tail -f /var/log/vmware/rhttpproxy/rhttpproxy.logLässt sich vpxd mit Fehlern wie „Initialisierung fehlgeschlagen“ oder Datenbankproblemen nicht starten, prüfen Sie den Festplattenspeicher:
df -hAchten Sie beim VCSA auf folgende Partitionen:
/storage/db – vCenter-Datenbank/storage/log – Logdateien (einschließlich vpxd-Logs)/ (Root) – falls Logs unter /var gespeichert werdenIst eine Partition zu mehr als 95 % belegt, schaffen Sie Speicherplatz. Löschen Sie alte Log-Bundles (/var/log/vmware/*.log.gz) oder erweitern Sie die Festplatte (siehe VMware KB 2145364).
Für den veralteten Windows-basierten vCenter verwenden Sie die Dienste-Verwaltung oder folgenden Befehl:
net start "VMware vCenter Server"Zertifikate sind nach ausgefallenen Diensten die zweithäufigste Fehlerursache. Entweder vertraut der Client dem vCenter-Zertifikat nicht, oder der vCenter lehnt das Client-Zertifikat ab.
1. Überprüfung des Zertifikatsablaufs auf einem beliebigen Client:
openssl s_client -connect vcenter.example.com:443 -servername vcenter.example.com 2>/dev/null | openssl x509 -noout -datesLiegt das Datum bei notAfter in der Vergangenheit, ist das Zertifikat abgelaufen. Generieren Sie es mit dem Zertifikatsmanager des VCSA neu:
cd /usr/lib/vmware-vmca/bin/
./certificate-manager
Wählen Sie Option 8 (Alle Zertifikate zurücksetzen) oder Option 3 (Maschinen-SSL-Zertifikat ersetzen). Planen Sie ein Wartungsfenster ein – dieser Vorgang startet alle Dienste neu.
2. Überprüfung der FQDN-Übereinstimmung
Lesen Sie die Subject Alternative Names (SAN) des Zertifikats aus:
openssl s_client -connect vcenter.example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"Die SAN-Liste muss genau den FQDN enthalten, über den Sie die Verbindung herstellen. Bei Zugriff per IP oder kurzem Hostnamen schlägt die Validierung fehl. Nutzen Sie stets den im Zertifikat hinterlegten FQDN.
Für PowerCLI-Nutzer: Bei selbst signierten Zertifikaten schlägt Connect-VIServer ohne Einstellung von InvalidCertificateAction stillschweigend fehl. Führen Sie folgenden Befehl aus:
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$falseStellen Sie anschließend die Verbindung erneut her. Dies ist nur eine client-seitige Umgehung, keine dauerhafte Lösung, bestätigt aber, dass der Fehler im Zertifikatstrust begründet liegt.
SAML-Tokens des Security Token Service (STS) werden anhand der Systemuhr validiert. Weichen die Uhren von vCenter und Client um mehr als 5 Minuten (Standardtoleranz) voneinander ab, schlägt die Token-Validierung fehl – dies zeigt sich bei manchen Clients als generischer Verbindungsfehler.
Auf dem VCSA ausführen:
date
timedatectl
systemctl status chronydIst die NTP-Synchronisation fehlerhaft, erzwingen Sie eine manuelle Synchronisation:
chronyc -a 'burst 4/4'
chronyc -a makestepFür Windows-basierten vCenter:
w32tm /query /status
w32tm /resyncZeitunterschiede treten häufig auf, wenn der vCenter während eines Snapshots angehalten wurde oder bei Host-Wartungen mit fehlerhafter VMware Tools-Zeitsynchronisierung.
Betreiben Sie mehrere vCenter-Server in einer Linked Mode-Gruppe (vSphere 7.0 und älter unterstützen Enhanced Linked Mode, vSphere 8.0 nutzt eine gemeinsame SSO-Domäne), erscheint der Fehler „Verbindung zu einem oder mehreren vCenter Server-Systemen nicht möglich“, wenn der SDK-Endpunkt einer beliebigen Mitgliedsinstanz ausfällt.
1. Prüfen Sie die Erreichbarkeit zwischen den vCenter-Instanzen. Testen Sie von jedem vCenter aus den SDK-Endpunkt der anderen Instanz:
# Auf vCenter A, Test von vCenter B
curl -k https://vcenterB.example.com:443/sdkSchlägt der Test von A nach B und von B nach A fehl, liegt das Problem in der Netzwerkverbindung zwischen den vCenter-Instanzen oder deren Diensten.
2. Überprüfung der Registrierung beim Lookup-Dienst
Der Lookup-Dienst verwaltet die Liste aller vCenter-Instanzen der SSO-Domäne. Wurde ein vCenter abgemeldet oder ist der Eintrag veraltet, tritt der Fehler auf. Nutzen Sie den Befehl cmsso-util (funktional auch in vSphere 8.x). Die genaue Syntax entnehmen Sie der VMware KB 2145069.
3. Reparatur von Linked Mode
Ist ein vCenter dauerhaft offline, entfernen Sie ihn mit cmsso-util domain-repurpose -m unregister aus der SSO-Domäne (den vollständigen Befehl finden Sie im zugehörigen KB-Artikel). Fügen Sie ihn nach Behebung der zugrundeliegenden Fehler wieder hinzu. Führen Sie diesen Schritt nur durch, wenn der betroffene vCenter nicht wiederhergestellt wird.
Haben Sie Netzwerk, Dienste, Zertifikate, DNS und Zeitsynchronisation geprüft und funktioniert der SDK-Endpunkt weiterhin nicht:
1. Alle vCenter-Dienste in der korrekten Reihenfolge neu starten
Auf der VCSA-Bash-Shell als root ausführen:
service-control --stop --all
service-control --start vmware-stsd
sleep 30
service-control --start vmware-rhttpproxy
sleep 15
service-control --start vmware-vpxd
service-control --start --all
2. Zugriff auf die Appliance-Shell über VAMI: Ist SSH nicht verfügbar, nutzen Sie die vCenter Server Management-Oberfläche (VAMI) auf Port 5480. Aktivieren Sie unter Fehlerbehebung die „Bash-Shell“. Anschließend führen Sie die obigen Befehle aus.
3. Wiederherstellung aus einer Sicherung: Ist die vpxd-Datenbank beschädigt und der vCenter lässt sich nicht starten, stellen Sie eine Wiederherstellung aus einer Dateiebene-Sicherung des VCSA her (über die native Sicherungs-/Wiederherstellungsfunktion der VAMI) oder aus einem Snapshot, der bei gestopptem vCenter erstellt wurde. Stellen Sie niemals einen Snapshot eines laufenden vCenter wieder her – dies führt zu Datenbankinkonsistenzen.
Nach Behebung des Fehlers implementieren Sie folgende Maßnahmen:
Fehler und Ausfälle treten immer wieder auf. Eine beschädigte vpxd-Datenbank, eine Ransomware-Attacke, die den vCenter-Appliance verschlüsselt, oder ein versehentliches Zurückspielen eines Snapshots können stundenlange Fehlerbehebung überflüssig machen. Aus diesem Grund ist eine dedizierte Sicherungsstrategie für Ihren vCenter Server und dessen virtuelle Maschinen unerlässlich.
Eine robuste Sicherungsstrategie für Ihre vCenter-Umgebung verwandelt einen katastrophalen Ausfall von einem risikobehafteten Snapshot-Wiederherstellungsvorgang in eine routinemäßige Wiederherstellung. Klicken Sie auf den Button unten, um eine 60-tägige kostenlose Testversion von i2Backup zu erhalten:
Dieser Artikel beschreibt die häufigsten Ursachen für den Fehler „Verbindung zu einem oder mehreren vCenter Server-Systemen nicht möglich“: ausgefallene Dienste, abgelaufene Zertifikate, DNS-Übereinstimmungsfehler oder Zeitabweichungen. Befolgen Sie die Schritte von Netzwerkprüfung über den /sdk-Test bis zum Neustart der Dienste, um den Fehler in den meisten Fällen zu beheben.
Zusätzlich ist eine regelmäßige Sicherung Ihrer VMware-VMs unerlässlich. Lässt sich ein Fehler nicht beheben, ist eine saubere Wiederherstellung der schnellste Weg zur Betriebsbereitschaft. i2Backup von Info2soft bietet agentenlose, unveränderbare Sicherungen speziell für vSphere-Umgebungen.
· Unternehmenskunden und Mittelstand weltweit
· Unser Support-Team unterstützt Sie während der gesamten Testphase
· Starten Sie eine 60-tägige Testversion oder sehen Sie sich eine Demo an, um zu erfahren, wie Info2Soft Unternehmensdaten schützt.
