vCenter virtual disks show 0 GB or blank properties due to SSL trust mismatch

Problem

In the vSphere Client, one or more virtual machine hard disks display incorrect or incomplete information. Typical symptoms include:

• Disk capacity shown as 0 GB
• Capacity or disk properties displayed as blank or unavailable
• Expanding the hard disk section in Edit Settings does not return the expected information
• Disk resize operations cannot be performed reliably through vCenter
• The same virtual disks display correctly when the VM is opened directly through the ESXi Host Client

When the behaviour affects all or many VMs in vCenter, but the underlying ESXi hosts show the VMDKs correctly, treat the issue as a vCenter management-plane problem before modifying individual virtual disks.

Environment / scope

This procedure applies primarily to:

• VMware vCenter Server Appliance (VCSA)
• vCenter Server 7.x
• vSphere environments where VM disk information is incorrect in vCenter but correct on ESXi

The troubleshooting flow was validated in a production vCenter 7.x environment. Hostnames, domains, object identifiers, counts and other environment-specific values shown below are sanitized examples.

Expected behaviour

For a healthy VM, Edit Settings in vCenter should show the configured capacity and properties for every virtual disk.

The vCenter view and the ESXi Host Client should agree on the disk configuration.

Observed behaviour

A typical failure looks like this:

vCenter Server:
Hard disk 1    0 GB / blank properties
Hard disk 2    0 GB / blank properties

ESXi Host Client:
Hard disk 1    200 GB
Hard disk 2    150 GB

The guest operating system may also continue to detect the disks normally.

This distinction is important: if ESXi and the guest both see the disks correctly, do not assume that the VMDKs themselves are damaged.

Likely causes

Check these in order:

1. A VM-specific snapshot or disk-chain issue
2. A vCenter inventory/UI issue affecting a single object
3. VMware Storage Policy Based Management (SPBM/PBM) service communication failure
4. SSL trust mismatch in the vCenter Lookup Service
5. Stale or inconsistent Lookup Service registrations after certificate maintenance or another topology/service change

Broadcom documents an SSL trust mismatch in the Lookup Service as a cause of this exact vCenter hard-disk symptom on vCenter 7.x.

Diagnostic workflow

1. Determine whether the issue is VM-specific or global

Open Edit Settings for several VMs.

Also connect directly to the ESXi Host Client hosting one of the affected VMs and inspect the same virtual disks.

Interpretation

If only one VM is affected, investigate that VM first, including snapshots and its virtual disk chain.

If multiple or all VMs are affected in vCenter while the ESXi Host Client displays the disks correctly, continue with the vCenter diagnostics below.

2. Confirm the vCenter version

SSH to the VCSA, enter the Bash shell if required, and run:

vpxd -v

Example:

VMware VirtualCenter 7.0.x build-XXXXXXXX

Version matters because service behaviour, log paths and supported recovery procedures can differ between vCenter releases.

3. Check the VMware Storage Policy service

Run:

service-control --status vmware-sps

A healthy service normally returns:

Running:
 vmware-sps

Do not stop troubleshooting only because vmware-sps is running.

The process can be running while SPBM/PBM requests still fail because of an SSL trust problem.

4. Search the vSphere Client log for PBM/SPBM SSL errors

Run:

grep -Ei "PbmServiceUnableToConnectException|InvalidSslCertificateException|Invalid SSL certificate|HTTP 526" \
/var/log/vmware/vsphere-ui/logs/vsphere_client_virgo.log | tail -50

Strong indicators include:

PbmServiceUnableToConnectException
InvalidSslCertificateException
Invalid SSL certificate (HTTP 526 status code)

If these errors appear repeatedly while disk information is missing from vCenter, the evidence strongly points to a broken SSL trust relationship used by the vCenter Lookup Service / SPBM path.

Evidence collected

A confirmed case typically has all of the following:

• Multiple VMs show 0 GB or missing disk properties in vCenter
• The same VMDKs display correctly in the ESXi Host Client
• vmware-sps is running
• The vSphere Client log contains PbmServiceUnableToConnectException
• The log also contains InvalidSslCertificateException and HTTP 526 errors
• Lookup Service Doctor reports an SSL trust mismatch

This combination differentiates a vCenter trust/service-registration problem from a guest filesystem or VMDK sizing problem.

5. Run Lookup Service Doctor in reporting mode

Download the current lsdoctor package from the official Broadcom KB and copy it to the VCSA.

Before using the package, verify the checksum published by Broadcom for the downloaded version.

Extract it and run the read-only check:

python lsdoctor.py -l

The -l / --lscheck option checks Lookup Service registrations and does not modify the environment.

A relevant finding looks similar to:

ERROR generateReport:
Default-First-Site\vcsa01.lab.example.com
found SSL Trust Mismatch

Please run the trustfix option on this node.

Root cause

The confirmed root cause is an SSL trust mismatch in vCenter Lookup Service registrations.

The registered SSL trust value does not match the current MACHINE_SSL_CERT presented by the node. This can occur after certificate replacement or other maintenance that leaves Lookup Service registrations inconsistent.

The mismatch prevents parts of the VMware storage profile/SPBM path from operating correctly, which can result in disk details appearing as 0 GB or blank in the vSphere Client even though the ESXi host still has the correct VMDK configuration.

Resolution

High-impact operation: lsdoctor --trustfix changes Lookup Service registrations. Follow Broadcom's snapshot/backup requirements before running it.

1. Prepare rollback protection

Before making changes with lsdoctor, follow the vendor requirement for the complete SSO domain.

For a standalone vCenter, create a supported backup or powered-off snapshot before the repair.

For environments with multiple vCenter/PSC nodes in the same SSO domain or Enhanced Linked Mode, all relevant nodes must be protected consistently. Broadcom requires the nodes to be powered down together before taking coordinated offline snapshots to avoid SSO database replication inconsistencies during rollback.

Do not treat a normal online snapshot of a single node as equivalent protection for a multi-node SSO domain.

2. Repair the trust registrations

From the directory containing lsdoctor.py, run:

python lsdoctor.py -t

The script requests confirmation that suitable backups/snapshots exist and then prompts for the SSO administrator credentials.

Use the SSO administrator account for the environment, for example:

administrator@vsphere.local

A successful repair may report:

We found <N> mismatch(s) and fixed them.
Please restart services on all PSCs and VCs when you're done.

The number of mismatches is environment-specific and is not itself a measure of severity.

3. Restart vCenter services

After trustfix completes successfully, restart the vCenter services:

service-control --stop --all
service-control --start --all

The combined form is also valid:

service-control --stop --all && service-control --start --all

Operational impact

This restart temporarily makes the vCenter management plane unavailable.

Running VMs on the ESXi hosts are not powered off by restarting vCenter services, but operations that depend on vCenter management or automation may be unavailable until the services return.

Allow sufficient time for all dependent services to start.

Validation

1. Confirm SPBM is running

service-control --status vmware-sps

Expected:

Running:
 vmware-sps

If the service remains in StartPending, wait for dependent vCenter services to finish starting before treating it as failed.

2. Re-run Lookup Service Doctor

python lsdoctor.py -l

The previous SSL trust mismatch should no longer be reported.

3. Verify the vSphere Client

Sign back in to vCenter and open:

Virtual Machine
  -> Edit Settings
  -> Hard disk

Confirm that:

• Disk capacities are displayed
• Virtual Device Node information is available
• Disk properties are no longer blank
• Disk resize controls behave normally where otherwise permitted

4. Confirm that new HTTP 526 errors are no longer being generated

Run:

grep -Ei "PbmServiceUnableToConnectException|InvalidSslCertificateException|Invalid SSL certificate|HTTP 526" \
/var/log/vmware/vsphere-ui/logs/vsphere_client_virgo.log | tail -20

Historical entries will remain in the log. The important check is that the problem is no longer generating new errors after service restoration.

Rollback / recovery

If the repair causes an unexpected service or SSO problem, stop and follow the rollback procedure appropriate to the protection method used before the change.

For a multi-node SSO domain, do not revert only one node from a coordinated snapshot set. Broadcom warns that inconsistent rollback can create replication problems in the PSC/SSO databases.

If external VMware solutions were registered against the affected node, verify them after trustfix. Depending on the environment, some integrations may need to be re-registered.

Prevention / best practice

• Keep a current file-based VCSA backup
• Document certificate replacement procedures
• Validate Lookup Service health after certificate changes
• Test several VMs before assuming a disk issue is isolated
• Compare vCenter with the direct ESXi Host Client before changing a VMDK
• Treat HTTP 526 plus InvalidSslCertificateException as a strong indicator of a trust problem
• Keep the current Broadcom-supported lsdoctor version available for diagnostics
• Always run lsdoctor.py -l before selecting a repair action
• Do not run --trustfix without rollback protection

Quick diagnostic sequence

# Version
vpxd -v

# SPBM service state
service-control --status vmware-sps

# Relevant vSphere Client errors
grep -Ei "PbmServiceUnableToConnectException|InvalidSslCertificateException|Invalid SSL certificate|HTTP 526" \
/var/log/vmware/vsphere-ui/logs/vsphere_client_virgo.log | tail -50

# Read-only Lookup Service check
python lsdoctor.py -l

If the evidence confirms an SSL trust mismatch, prepare rollback protection and then follow the vendor-supported trustfix procedure.

Related articles

• VMware virtual disk sizing and guest partition mapping — planned
• vCenter certificate and Lookup Service health checks — planned

Sources

See the authoritative Broadcom references in the article metadata.