This website use cookies to help you have a superior and more admissible browsing experience on the website.
Loading...
By:
When you log into vCenter, you may see a red error banner: “Could not connect or one or more vCenter Server systems”.
Sometimes, You may see variations such as:
The error usually means the vSphere Client or another VMware management component cannot establish communication with one or more registered vCenter Servers.
In most cases, the affected vCenter is online and running VMs continue operating normally, but administrators may lose access to inventory management, monitoring, migrations, backups, and other vCenter-based functions until connectivity is restored.
The root causes of the error can be different according to the messages.
● could not connect to one or more vcenter server systems:443/sdk
This variation usually points to connectivity problems involving the vCenter SDK endpoint.
Potential causes include:
● could not connect to one or more vcenter server systems:https://
This version often indicates malformed URLs, certificate validation failures, or hostname resolution problems.
● could not connect to one or more vcenter server systems:https://:443/sdk
This error frequently appears when hostname information is missing or improperly configured, causing the generated connection URL to become invalid.
Next, you can refer to the following section, we will help you fix this error step by step
You can follow the steps below to fix the error. Follow the steps below in order. Each step assumes the previous one succeeded.
1. See where the error appears:
2. Does the error affect all vCenters in a Linked Mode group?
Connect to each vCenter’s UI directly using its FQDN. If only one fails, focus on that host’s services and certificates. If all fail, check the PSC (vSphere 6.7) or the embedded SSO service (7.0+).
Run ping and telnet commands from the client machine that shows the error:
ping vcenter.example.com
telnet vcenter.example.com 443If ping fails: DNS or routing problem. Fix name resolution first.
If telnet fails (timeout or “Connection refused”):
● For PowerCLI on Windows:
Test-NetConnection -ComputerName vcenter.example.com -Port 443If the connection succeeds but the rror pwersists, move the Step 4.
Load balancer warning: If vCenter is behind a load balancer, the LB may pass TCP on 443 but fail to route /sdk correctly. Temporarily bypass the LB – connect directly to vCenter’s IP or hostname.
vCenter’s certificate includes its FQDN. If your client resolves that FQDN to a different IP than vCenter expects, the certificate check fails and the SDK connection is rejected.
On the client:
nslookup vcenter.example.com
# Should return the vCenter’s IPNow check reverse DNS from the vCenter’s perspective. SSH into VCSA and run:
nslookup <client_IP>ls -la /vmfs/volumes
# The result should include the client’s hostnameIf the client’s IP address does not correctly resolve back to the client’s expected hostname, vCenter’s Lookup Service will not trust the client and will refuse to give it a login token – causing the connection error.”
Add an entry to the `/etc/hosts` file in VCSA to bypass DNS resolution. However, this method will fail when the IP address changes or when vCenter verifies its own FQDN. Please use genuine DNS resolution.
This is the most direct diagnostic. Run from any machine that can reach port 443 on vCenter:
curl -k https://vcenter.example.com:443/sdkThe -k flag ignores certificate validation. That means you won’t see SSL certificate errors – you’ll see only HTTP responses or connection failures.
You get an XML response starting with <soapenv:Envelope…> and containing a fault code like InvalidLogin or MissingHeader. That’s good news – the SDK endpoint is alive and rejecting only because you didn’t provide credentials.
What you might see instead:
|
Response |
Meaning |
Next step |
|
curl: (7) Failed to connect |
Nothing listening on 443 |
Service dead – check vpxd |
|
curl: (52) Empty reply |
Service crashed mid-response |
Restart vpxd, check logs |
|
401 Unauthorized |
SDK is up but requires login. This is normal when no credentials are sent. |
Your client has an authentication or certificate trust issue (client-side). |
|
403 Forbidden |
IP or path restriction (rare) |
Check vCenter’s reverse proxy config |
|
503 Service Unavailable |
Service started but not ready |
Wait 5 minutes or check startup logs |
|
Connection reset by peer |
SSL/TLS mismatch |
Check TLS versions and ciphers |
● For PowerShell users:
Invoke-WebRequest -Uri "https://vcenter.example.com:443/sdk" -SkipCertificateCheck -Method GetIf you get a valid XML fault (even with a fault code), your SDK endpoint is healthy. The problem is client-side: browser certificate trust, PowerCLI credential handling, or a missing -SkipCertificateCheck flag. If you get any connection refusal or 5xx error, proceed to service checks.
The SDK endpoint is hosted primarily by the vpxd service (vCenter Server). On VCSA, SSH in and run:
service-control --status –allLook for:
If vpxd is stopped, start it:
service-control --start vmware-vpxdCheck its logs for startup failures:
tail -f /var/log/vmware/vpxd/vpxd.log
tail -f /var/log/vmware/rhttpproxy/rhttpproxy.logIf vpxd fails to start with “Failed to initialize” or database errors, check disk space:
df -hOn VCSA, watch these partitions:
If any partition is above 95% full, free up space. Delete old log bundles (/var/log/vmware/*.log.gz) or expand the disk (see VMware KB 2145364).
For Windows vCenter (deprecated but still in use), use the Services MMC or:
net start "VMware vCenter Server"Certificates are the second most common cause after simple service failures. The real issue can be that the client does not trust vCenter’s certificate – or vCenter rejects the client certificate.
1. Check certificate expiry from any client:
openssl s_client -connect vcenter.example.com:443 -servername vcenter.example.com 2>/dev/null | openssl x509 -noout -datesIf notAfter is in the past, your certificate is expired. Regenerate using VCSA’s certificate-manager:
cd /usr/lib/vmware-vmca/bin/
./certificate-manager
Select Option 8 (Reset all certificates) or Option 3 (Replace Machine SSL certificate). Plan a maintenance window – this will restart services.
2. Check FQDN match
Extract the certificate’s Subject Alternative Names (SANs):
openssl s_client -connect vcenter.example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"The SAN list must include the exact FQDN you are using to connect. If you connect via IP address or a short hostname, validation fails. Always use the FQDN as it appears in the certificate.
For PowerCLI users – If you run Connect-VIServer with a self-signed certificate and haven’t set InvalidCertificateAction, the connection fails silently. Run:
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$falseThen reconnect. This is a client-side bypass – not a fix, but it confirms the issue is certificate trust.
SAML tokens from the Security Token Service (STS) are validated against the system clock. If vCenter’s clock and the client’s clock differ by more than 5 minutes (default skew), token validation fails. That surfaces as a generic connection error in some clients.
On VCSA:
date
timedatectl
systemctl status chronydIf NTP is not syncing, force a manual step:
chronyc -a 'burst 4/4'
chronyc -a makestepFor Windows vCenter:
w32tm /query /status
w32tm /resyncTime discrepancies often occur after vCenter is paused during snapshots or after host maintenance if VMware Tools time synchronization is misconfigured.
If you have multiple vCenter servers in a Linked Mode group (vSphere 7.0 and earlier supported Enhanced Linked Mode; vSphere 8.0 uses a common SSO domain), the “could not connect to one or more vCenter Server Systems ” error appears when any member vCenter’s SDK endpoint fails.
1. Verify reachability between vCenters. From each vCenter, test the other’s SDK endpoint:
# On vCenter A, test vCenter B
curl -k https://vcenterB.example.com:443/sdkIf the test fails from A and B, the issue is cross-vCenter networking or services.
2. Check Lookup Service registration
The Lookup Service maintains a list of all vCenters in the SSO domain. If a vCenter is deregistered or its entry is stale, you’ll get the error. Use the cmsso-util command (still functional in vSphere 8.x). For exact syntax, refer to VMware KB 2145069.
3. Repair Linked Mode
If one vCenter is permanently offline, remove it from the SSO domain using cmsso-util domain-repurpose -m unregister (see KB article for full command). Then re-add it after fixing the underlying issue. Do this only if the offline vCenter is not coming back.
If you’ve verified network, services, certificates, DNS, and time, and the SDK endpoint still fails:
1. Restart all vCenter services in order
From VCSA bash (as root):
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. Boot VCSA into appliance shell via VAMI: If you cannot SSH, use the vCenter Server Management Interface (VAMI) on port 5480. Under Troubleshooting, enable “Bash shell.” Then run the commands above.
3. restore from backup: If the vpxd database is corrupted and vCenter fails to start, restore from a file-level backup of the VCSA (using VAMI’s native backup/restore) or from a snapshot taken while vCenter was shut down. Never restore a snapshot of a running vCenter – it will cause database inconsistencies.
Once the error is resolved, put these measures in place:
Errors and failures happen from time to time. A corrupted vpxd database, a ransomware attack that encrypts your vCenter appliance, or an accidental snapshot rollback can render hours of troubleshooting irrelevant. That’s why a dedicated backup strategy for your vCenter Server and its underlying VMs is essential.
Info2soft’s i2Backup provides a purpose-built backup and recovery solution for VMware vSphere environments. Unlike generic file-level backups, i2Backup is designed to protect the entire vCenter Server Appliance (VCSA) and its associated databases with enterprise-grade features.
Implementing a robust backup strategy for your vCenter environment transforms a catastrophic failure from a “restore from snapshot” risk into a routine recovery operation. You can click the button below to get a 60-day free trial of i2Backup:
This article walks through the common causes behind “could not connect to one or more vCenter server systems” – dead services, certificate expiry, DNS mismatches, or time skew. Follow the steps from network checks to /sdk testing to service restarts, and you’ll resolve it in most cases.
In addition, it is necessary to back up your VMware VMs regularly. When things go beyond repair, a clean restore is your fastest path to recovery. Info2soft i2Backup offers agentless, immutable backups designed for vSphere environments.
