Discos virtuais no vCenter aparecem com 0 GB ou propriedades em branco devido a SSL trust mismatch

Problema

No vSphere Client, um ou mais hard disks de máquinas virtuais apresentam informação incorreta ou incompleta. Sintomas típicos incluem:

• Capacidade do disco apresentada como 0 GB
• Capacidade ou propriedades do disco em branco ou indisponíveis
• Expandir a secção do hard disk em Edit Settings não devolve a informação esperada
• Operações de resize do disco não podem ser executadas de forma fiável através do vCenter
• Os mesmos virtual disks aparecem corretamente quando a VM é aberta diretamente através do ESXi Host Client

Quando o comportamento afeta todas ou muitas VMs no vCenter, mas os ESXi hosts subjacentes apresentam os VMDKs corretamente, trata primeiro o problema como uma falha do management plane do vCenter antes de alterares discos virtuais individuais.

Ambiente / âmbito

Este procedimento aplica-se principalmente a:

• VMware vCenter Server Appliance (VCSA)
• vCenter Server 7.x
• Ambientes vSphere em que a informação dos discos das VMs está incorreta no vCenter, mas correta no ESXi

O workflow de troubleshooting foi validado num ambiente vCenter 7.x em produção. Hostnames, domínios, object identifiers, contagens e outros valores específicos do ambiente apresentados abaixo são exemplos anonimizados.

Comportamento esperado

Numa VM saudável, Edit Settings no vCenter deve apresentar a capacidade configurada e as propriedades de cada virtual disk.

A vista do vCenter e o ESXi Host Client devem apresentar uma configuração de discos consistente.

Comportamento observado

Uma falha típica pode ter este aspeto:

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

O guest operating system pode continuar a detetar os discos normalmente.

Esta distinção é importante: se o ESXi e o guest veem os discos corretamente, não assumas que os próprios VMDKs estão danificados.

Causas prováveis

Verifica pela seguinte ordem:

1. Problema específico da VM relacionado com snapshot ou disk chain
2. Problema de inventory/UI do vCenter que afeta apenas um objeto
3. Falha de comunicação no serviço VMware Storage Policy Based Management (SPBM/PBM)
4. SSL trust mismatch no vCenter Lookup Service
5. Lookup Service registrations desatualizadas ou inconsistentes após manutenção de certificados ou outra alteração de topologia/serviços

A Broadcom documenta um SSL trust mismatch no Lookup Service como causa deste sintoma específico de hard disks no vCenter 7.x.

Workflow de diagnóstico

1. Determinar se o problema é específico de uma VM ou global

Abre Edit Settings em várias VMs.

Liga-te também diretamente ao ESXi Host Client que aloja uma das VMs afetadas e inspeciona os mesmos virtual disks.

Interpretação

Se apenas uma VM estiver afetada, investiga primeiro essa VM, incluindo snapshots e a respetiva virtual disk chain.

Se várias ou todas as VMs estiverem afetadas no vCenter enquanto o ESXi Host Client apresenta corretamente os discos, continua com os diagnósticos do vCenter abaixo.

2. Confirmar a versão do vCenter

Liga por SSH ao VCSA, entra no Bash shell se necessário e executa:

vpxd -v

Exemplo:

VMware VirtualCenter 7.0.x build-XXXXXXXX

A versão é importante porque o comportamento dos serviços, os log paths e os procedimentos de recovery suportados podem variar entre versões do vCenter.

3. Verificar o serviço VMware Storage Policy

Executa:

service-control --status vmware-sps

Um serviço saudável devolve normalmente:

Running:
 vmware-sps

Não termines o troubleshooting apenas porque vmware-sps está em running.

O processo pode estar ativo enquanto os pedidos SPBM/PBM continuam a falhar devido a um problema de SSL trust.

4. Procurar erros SSL de PBM/SPBM no log do vSphere Client

Executa:

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

Indicadores fortes incluem:

PbmServiceUnableToConnectException
InvalidSslCertificateException
Invalid SSL certificate (HTTP 526 status code)

Se estes erros aparecerem repetidamente enquanto a informação dos discos está em falta no vCenter, a evidência aponta fortemente para uma relação de SSL trust quebrada utilizada pelo caminho vCenter Lookup Service / SPBM.

Evidência recolhida

Um caso confirmado apresenta normalmente todos os seguintes elementos:

• Várias VMs mostram 0 GB ou propriedades de disco em falta no vCenter
• Os mesmos VMDKs são apresentados corretamente no ESXi Host Client
• vmware-sps está em running
• O log do vSphere Client contém PbmServiceUnableToConnectException
• O log contém também InvalidSslCertificateException e erros HTTP 526
• Lookup Service Doctor reporta um SSL trust mismatch

Esta combinação diferencia um problema de trust/service registration do vCenter de um problema de guest filesystem ou dimensionamento de VMDK.

5. Executar Lookup Service Doctor em reporting mode

Descarrega o package atual do lsdoctor a partir da KB oficial da Broadcom e copia-o para o VCSA.

Antes de utilizares o package, valida o checksum publicado pela Broadcom para a versão descarregada.

Extrai-o e executa a verificação read-only:

python lsdoctor.py -l

A opção -l / --lscheck verifica Lookup Service registrations e não modifica o ambiente.

Uma descoberta relevante pode ser semelhante a:

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

Please run the trustfix option on this node.

Causa raiz

A causa raiz confirmada é um SSL trust mismatch nas vCenter Lookup Service registrations.

O valor SSL trust registado não corresponde ao MACHINE_SSL_CERT atual apresentado pelo node. Isto pode acontecer após substituição de certificados ou outra manutenção que deixe Lookup Service registrations inconsistentes.

O mismatch impede que partes do caminho VMware storage profile/SPBM funcionem corretamente, o que pode resultar em detalhes de discos apresentados como 0 GB ou em branco no vSphere Client, mesmo quando o ESXi host continua com a configuração correta dos VMDKs.

Resolução

Operação de alto impacto: lsdoctor --trustfix altera Lookup Service registrations. Segue os requisitos de snapshot/backup da Broadcom antes de o executar.

1. Preparar rollback protection

Antes de fazer alterações com lsdoctor, segue os requisitos do fabricante para todo o SSO domain.

Num vCenter standalone, cria um backup suportado ou powered-off snapshot antes da reparação.

Em ambientes com vários nodes vCenter/PSC no mesmo SSO domain ou Enhanced Linked Mode, todos os nodes relevantes devem ser protegidos de forma consistente. A Broadcom exige que os nodes sejam desligados em conjunto antes de criar coordinated offline snapshots, de forma a evitar inconsistências de replicação da base de dados SSO durante rollback.

Não trates um snapshot online normal de um único node como proteção equivalente para um SSO domain multi-node.

2. Reparar as trust registrations

A partir da pasta que contém lsdoctor.py, executa:

python lsdoctor.py -t

O script pede confirmação de que existem backups/snapshots adequados e depois solicita as credenciais do SSO administrator.

Utiliza a conta SSO administrator do ambiente, por exemplo:

administrator@vsphere.local

Uma reparação bem-sucedida pode apresentar:

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

O número de mismatches depende do ambiente e não constitui, por si só, uma medida de severidade.

3. Reiniciar os serviços do vCenter

Depois de trustfix terminar com sucesso, reinicia os serviços do vCenter:

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

A forma combinada também é válida:

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

Impacto operacional

Este restart torna temporariamente indisponível o vCenter management plane.

As VMs em execução nos ESXi hosts não são desligadas ao reiniciar os serviços do vCenter, mas operações dependentes da gestão ou automação do vCenter podem ficar indisponíveis até os serviços regressarem.

Dá tempo suficiente para todos os serviços dependentes arrancarem.

Validação

1. Confirmar que SPBM está em running

service-control --status vmware-sps

Esperado:

Running:
 vmware-sps

Se o serviço permanecer em StartPending, aguarda que os serviços dependentes do vCenter terminem o arranque antes de o considerares em falha.

2. Voltar a executar Lookup Service Doctor

python lsdoctor.py -l

O SSL trust mismatch anterior já não deve ser reportado.

3. Verificar o vSphere Client

Volta a iniciar sessão no vCenter e abre:

Virtual Machine
  -> Edit Settings
  -> Hard disk

Confirma:

• As capacidades dos discos são apresentadas
• A informação Virtual Device Node está disponível
• As propriedades dos discos deixaram de aparecer em branco
• Os controlos de disk resize funcionam normalmente onde forem permitidos

4. Confirmar que não estão a ser gerados novos erros HTTP 526

Executa:

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

As entradas históricas permanecem no log. O importante é confirmar que o problema já não gera novos erros depois da reposição dos serviços.

Rollback / recovery

Se a reparação provocar um problema inesperado de serviços ou SSO, pára e segue o procedimento de rollback adequado ao método de proteção utilizado antes da alteração.

Num SSO domain multi-node, não reverta apenas um node de um conjunto coordenado de snapshots. A Broadcom alerta que um rollback inconsistente pode criar problemas de replicação nas bases de dados PSC/SSO.

Se existirem soluções VMware externas registadas contra o node afetado, valida-as após trustfix. Dependendo do ambiente, algumas integrações podem precisar de novo registration.

Prevenção / boas práticas

• Mantém um file-based VCSA backup atual
• Documenta os procedimentos de certificate replacement
• Valida a saúde do Lookup Service após alterações de certificados
• Testa várias VMs antes de assumir que um problema de disco é isolado
• Compara vCenter com o ESXi Host Client direto antes de alterares um VMDK
• Trata HTTP 526 juntamente com InvalidSslCertificateException como forte indicador de problema de trust
• Mantém disponível a versão de lsdoctor atualmente suportada pela Broadcom
• Executa sempre lsdoctor.py -l antes de escolher uma repair action
• Não executes --trustfix sem rollback protection

Sequência rápida de diagnóstico

# 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

Se a evidência confirmar um SSL trust mismatch, prepara rollback protection e segue o procedimento trustfix suportado pelo fabricante.

Artigos relacionados

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

Fontes

Consulta as referências oficiais da Broadcom indicadas nos metadados do artigo.