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. eine rote Fehlermeldung angezeigt: „Es konnte keine Verbindung zu einem oder mehreren vCenter-Server-Systemen hergestellt werden“.
Gelegentlich treten abweichende Fehlermeldungen auf, beispielsweise:
Dieser Fehler bedeutet in der Regel, dass der vSphere-Client oder eine andere VMware-Verwaltungskomponente keine Kommunikation mit einem oder mehreren registrierten vCenter-Servern aufbauen kann.
In den meisten Fällen laufen die betroffenen vCenter-Instanzen und die virtuellen Maschinen uneingeschränkt. Administratoren verlieren jedoch den Zugriff auf Inventarverwaltung, Überwachung, Migrationen, Backups und weitere vCenter-basierte Funktionen, bis die Konnektivität wiederhergestellt ist.
Die zugrundeliegenden Gründe variieren je nach genauer Fehlermeldung.
● Es konnte keine Verbindung zu einem oder mehreren vCenter-Server-Systemen hergestellt werden:443/sdk
Diese Variante deutet zumeist auf Verbindungsprobleme am vCenter-SDK-Endpunkt hin.
Mögliche Auslöser:
● Es konnte keine Verbindung zu einem oder mehreren vCenter-Server-Systemen hergestellt werden:https://
Diese Fehlermeldung weist oft auf fehlerhafte URLs, fehlgeschlagene Zertifikatsvalidierungen oder Probleme bei der Hostnamenauflösung hin.
● Es konnte keine Verbindung zu einem oder mehreren vCenter-Server-Systemen hergestellt werden:https://:443/sdk
Dieser Fehler tritt häufig auf, wenn Hostnameninformationen fehlen oder fehlerhaft konfiguriert sind, wodurch die generierte Verbindungs-URL ungültig wird.
Im Folgenden finden Sie eine Schritt-für-Schritt-Anleitung zur Behebung des Fehlers.
Führen Sie die nachfolgenden Schritte nacheinander durch. Jeder Schritt setzt voraus, dass der vorherige erfolgreich abgeschlossen wurde.
1. Prüfen Sie die Umgebung, in der der Fehler angezeigt wird:
Connect-VIServer -Server <FQDN> -Verbose aus. Die detaillierte Fehlermeldung gibt Aufschluss über den genauen HTTP-Statuscode.2. Betrifft der Fehler alle vCenter-Instanzen einer Linked-Mode-Gruppe?
Melden Sie sich direkt über den vollständigen Hostnamen (FQDN) bei jeder einzelnen vCenter-Oberfläche an. Scheitert nur eine Instanz, konzentrieren Sie sich auf deren Dienste und Zertifikate. Treten bei allen Instanzen Fehler auf, prüfen Sie den PSC (vSphere 6.7) oder den integrierten SSO-Dienst (ab vSphere 7.0).
Führen Sie vom Client-Gerät mit dem Fehler Ping- und Telnet-Befehle aus:
ping vcenter.example.com
telnet vcenter.example.com 443Schlägt der Ping fehl: Es handelt sich um ein DNS- oder Routing-Problem. Beheben Sie zuerst die Namensauflösung.
Schlägt Telnet fehl (Timeout oder „Verbindung verweigert“):
● Für PowerCLI unter Windows:
Test-NetConnection -ComputerName vcenter.example.com -Port 443Ist die Netzwerkverbindung erfolgreich, der Fehler jedoch weiterhin vorhanden, fahren Sie mit Schritt 4 fort.
Hinweis zu Load Balancern: Befindet sich vCenter hinter einem Load Balancer, wird ggf. der TCP-Verkehr auf Port 443 weitergeleitet, der Pfad /sdk jedoch nicht korrekt geroutet. Umgehen Sie vorläufig den Load Balancer und verbinden Sie sich direkt mit der IP oder dem Hostnamen von vCenter.
Das vCenter-Zertifikat enthält den vollständigen Hostnamen (FQDN). Löst der Client diesen FQDN auf eine andere IP-Adresse auf, als von vCenter erwartet, schlägt die Zertifikatsprüfung fehl und die SDK-Verbindung wird abgelehnt.
Auf dem Client-Gerät ausführen:
nslookup vcenter.example.com
# Es muss die IP-Adresse des vCenter-Servers zurückgegeben werdenPrüfen Sie anschließend die umgekehrte DNS-Auflösung aus Sicht von vCenter. Melden Sie sich per SSH an der VCSA an und führen Sie aus:
nslookup <Client-IP>
ls -la /vmfs/volumes
# Das Ergebnis muss den Hostnamen des Clients enthaltenLöst die Client-IP nicht korrekt auf den erwarteten Client-Hostnamen auf, vertraut der vCenter Lookup Service dem Client nicht und verweigert die Zuweisung eines Anmeldetokens – daraus resultiert der Verbindungsfehler.
Sie können einen Eintrag zur Umgehung der DNS-Auflösung in die Datei /etc/hosts der VCSA einfügen. Diese Methode scheitert jedoch bei wechselnden IP-Adressen oder bei der Prüfung des eigenen vCenter-FQDN. Nutzen Sie stattdessen eine korrekte DNS-Konfiguration.
Dies ist die direkteste Diagnosemöglichkeit. Führen Sie den Befehl auf einem beliebigen Gerät aus, das Port 443 von vCenter erreichen kann:
curl -k https://vcenter.example.com:443/sdkDer Parameter -k ignoriert die Zertifikatsprüfung. Dadurch werden keine SSL-Fehler angezeigt, sondern nur HTTP-Antworten oder Verbindungsfehler.
Erhalten Sie eine XML-Antwort beginnend mit <soapenv:Envelope...> und einem Fehlercode wie InvalidLogin oder MissingHeader, ist der SDK-Endpunkt funktionsfähig – die Verbindung wird nur abgelehnt, weil keine Zugangsdaten übermittelt wurden.
Mögliche abweichende Ergebnisse und deren Bedeutung:
|
Antwort |
Bedeutung |
Nächster Schritt |
|
curl: (7) Failed to connect |
Auf Port 443 lauscht kein Dienst |
Dienst ausgefallen – Prüfen Sie vpxd |
|
curl: (52) Empty reply |
Dienst stürzte während der Antwort ab |
vpxd neu starten, Logs prüfen |
|
401 Unauthorized |
SDK läuft, Anmeldung erforderlich. Dieser Status ohne Zugangsdaten ist normal. |
Client-seitiges Problem mit Authentifizierung oder Zertifikatsvertrauensstellung |
|
403 Forbidden |
Einschränkung nach IP oder Pfad (selten) |
Reverse-Proxy-Konfiguration von vCenter prüfen |
|
503 Service Unavailable |
Dienst gestartet, aber noch nicht betriebsbereit |
5 Minuten warten oder Startlogs prüfen |
|
Connection reset by peer |
Nicht übereinstimmende SSL/TLS-Versionen |
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), ist der SDK-Endpunkt intakt. Das Problem liegt auf Client-Seite: Browser-Zertifikatsvertrauensstellung, Verarbeitung von Anmeldedaten durch PowerCLI oder fehlender Parameter -SkipCertificateCheck. Bei Verbindungsverweigerungen oder 5xx-Fehlercodes fahren Sie mit der Dienstprüfung fort.
Der SDK-Endpunkt wird hauptsächlich vom Dienst vpxd (vCenter Server) bereitgestellt. Melden Sie sich per SSH an der VCSA an und führen Sie aus:
service-control --status --allAchten Sie auf folgende Dienste:
RUNNING habenIst vpxd gestoppt, starten Sie den Dienst:
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.logScheitert der Start von vpxd mit Hinweisen wie „Failed to initialize“ oder Datenbankfehlern, prüfen Sie den Speicherplatz:
df -hAchten Sie bei der VCSA auf folgende Partitionen:
Ist 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 Windows-basiertes vCenter (veraltet, aber noch im Einsatz) nutzen Sie die Dienste-Verwaltung oder folgenden Befehl:
net start "VMware vCenter Server"Zertifikate sind nach ausgefallenen Diensten die zweithäufigste Fehlerursache. Das eigentliche Problem besteht darin, dass der Client dem vCenter-Zertifikat nicht vertraut – oder vCenter das Client-Zertifikat ablehnt.
1. Überprüfung des Zertifikatsablaufdatums von 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 neu mit dem Zertifikatsmanager der VCSA:
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 Übereinstimmung des vollständigen Hostnamens (FQDN)
Extrahieren Sie die Subject Alternative Names (SAN) des Zertifikats:
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-Adresse oder kurzem Hostnamen schlägt die Validierung fehl. Nutzen Sie stets den im Zertifikat eingetragenen vollständigen Hostnamen.
Für PowerCLI-Nutzer – Bei selbst signierten Zertifikaten ohne festgelegten InvalidCertificateAction schlägt die Verbindung lautlos fehl. Führen Sie folgenden Befehl aus:
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$falseStellen Sie anschließend die Verbindung wieder her. Dies ist eine client-seitige Umgehungslösung, keine dauerhafte Korrektur – bestätigt aber, dass das Problem an der Zertifikatsvertrauensstellung liegt.
SAML-Token des Security Token Service (STS) werden anhand der Systemuhr validiert. Weichen die Uhren von vCenter und Client um mehr als 5 Minuten (Standardabweichung) voneinander ab, schlägt die Token-Prüfung fehl. Dies wird in manchen Clients als generischer Verbindungsfehler angezeigt.
Auf der VCSA ausführen:
date
timedatectl
systemctl status chronydIst die NTP-Synchronisation gestört, erzwingen Sie eine manuelle Zeitanpassung:
chronyc -a 'burst 4/4'
chronyc -a makestepFür Windows-basiertes vCenter:
w32tm /query /status
w32tm /resyncZeitabweichungen treten häufig auf, wenn vCenter während eines Snapshots angehalten wurde oder nach Host-Wartungsarbeiten mit fehlerhafter VMware-Tools-Zeitsynchronisation.
Nutzen Sie mehrere vCenter-Server in einer Linked-Mode-Gruppe (vSphere 7.0 und älter unterstützen Enhanced Linked Mode, ab vSphere 8.0 wird eine gemeinsame SSO-Domäne verwendet), erscheint der Fehler „Es konnte keine Verbindung zu einem oder mehreren vCenter-Server-Systemen hergestellt werden“, sobald der SDK-Endpunkt einer beliebigen Mitgliedsinstanz ausfällt.
1. Prüfen Sie die Erreichbarkeit zwischen den vCenter-Instanzen. Testen Sie von jeder vCenter-Instanz aus den SDK-Endpunkt der anderen:
# Auf vCenter A, Test von vCenter B
curl -k https://vcenterB.example.com:443/sdkSchlägt der Test von Instanz A und B fehl, liegt das Problem an der netzwerkübergreifenden Kommunikation oder ausgefallenen Diensten.
2. Überprüfung der Lookup Service-Registrierung
Der Lookup Service verwaltet eine Liste aller vCenter-Instanzen innerhalb der SSO-Domäne. Wurde eine vCenter-Instanz abgemeldet oder ist der Eintrag veraltet, tritt der Fehler auf. Nutzen Sie den Befehl cmsso-util (funktionsfähig bis vSphere 8.x). Die genaue Syntax entnehmen Sie der VMware KB 2145069.
3. Reparatur von Linked Mode
Ist eine vCenter-Instanz dauerhaft nicht verfügbar, entfernen Sie sie mit cmsso-util domain-repurpose -m unregister aus der SSO-Domäne (vollständige Befehle in der zugehörigen KB-Artikel). Fügen Sie sie nach Behebung des zugrundeliegenden Problems erneut hinzu. Führen Sie diesen Schritt nur durch, wenn die ausgefallene vCenter-Instanz nicht wiederhergestellt wird.
Haben Sie Netzwerk, Dienste, Zertifikate, DNS und Zeitsynchronisation geprüft und der SDK-Endpunkt funktioniert weiterhin nicht:
1. Alle vCenter-Dienste in korrekter 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 per VAMI: Ist eine SSH-Verbindung nicht möglich, nutzen Sie die vCenter Server Management-Schnittstelle (VAMI) auf Port 5480. Aktivieren Sie unter Fehlerbehebung die „Bash-Shell“ und führen Sie die obigen Befehle aus.
3. Wiederherstellung aus Backup: Ist die vpxd-Datenbank beschädigt und vCenter startet nicht, stellen Sie die VCSA aus einem dateibasierten Backup wieder her (mittels nativer 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 Inkonsistenzen in der Datenbank.
Nach Behebung des Fehlers setzen Sie folgende Maßnahmen um:
Fehler und Ausfälle treten regelmäßig auf. Eine beschädigte vpxd-Datenbank, Ransomware, die die vCSA verschlüsselt, oder ein versehentliches Zurückspielen eines Snapshots können stundenlange Fehlersuche zunichte machen. Deshalb ist eine dedizierte Sicherungsstrategie für vCenter-Server und zugehörige virtuelle Maschinen unerlässlich.
Die i2Backup von Info2soft ist eine speziell entwickelte Sicherungs- und Wiederherstellungslösung für VMware-vSphere-Umgebungen. Im Gegensatz zu generischen dateibasierten Sicherungen schützt i2Backup die gesamte vCenter Server Appliance (VCSA) und zugehörige Datenbanken mit unternehmensrelevanten Funktionen.
Eine robuste Sicherungsstrategie für Ihre vCenter-Umgebung wandelt katastrophale Ausfälle von riskanten Snapshot-Wiederherstellungen in routinemäßige Wiederherstellungsvorgänge um. Klicken Sie auf den nachfolgenden Button, um eine 60-tägige kostenlose Testversion von i2Backup zu erhalten:
Dieser Artikel erläutert die häufigsten Auslöser des Fehlers „Es konnte keine Verbindung zu einem oder mehreren vCenter-Server-Systemen hergestellt werden“: ausgefallene Dienste, abgelaufene Zertifikate, DNS-Übereinstimmungsfehler oder Zeitabweichungen. Führen Sie die Schritte von Netzwerkprüfung über /sdk-Tests bis zum Neustart von Diensten durch – in den meisten Fällen lässt sich der Fehler damit beheben.
Zusätzlich ist eine regelmäßige Sicherung Ihrer VMware-VMs unerlässlich. Bei irreparablen Systemschäden ist eine saubere Wiederherstellung der schnellste Weg zur Betriebsbereitschaft. Die Info2soft i2Backup bietet agentenlose, manipulationssichere 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.
